| Time |
Nick |
Message |
| 00:24 |
|
sbrylander joined #evergreen |
| 00:42 |
|
sarabee joined #evergreen |
| 03:45 |
|
sbrylander joined #evergreen |
| 04:59 |
|
sarabee joined #evergreen |
| 05:18 |
|
dreuther joined #evergreen |
| 05:21 |
|
chatley joined #evergreen |
| 06:35 |
|
Callender joined #evergreen |
| 06:38 |
|
wsmoak joined #evergreen |
| 06:38 |
|
wsmoak joined #evergreen |
| 06:47 |
|
mnsri joined #evergreen |
| 07:05 |
|
chatley_ joined #evergreen |
| 07:05 |
|
dreuther joined #evergreen |
| 08:00 |
|
rjackson-isl joined #evergreen |
| 08:06 |
|
kmlussier joined #evergreen |
| 08:09 |
kmlussier |
Oh well. Parts had nearly 4 hours of positive karma. My job here is done. :) |
| 08:09 |
kmlussier |
Good morning #evergreen! |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:14 |
|
phasefx joined #evergreen |
| 08:14 |
|
Callender_ joined #evergreen |
| 08:16 |
|
eeevil joined #evergreen |
| 08:18 |
|
mtate joined #evergreen |
| 08:19 |
|
graced joined #evergreen |
| 08:24 |
|
collum joined #evergreen |
| 08:25 |
|
TaraC joined #evergreen |
| 08:31 |
* csharp |
reads yesterday's scrollback |
| 08:32 |
|
mdriscoll1 joined #evergreen |
| 08:36 |
* kmlussier |
wonders if there is something better than TwitterFeed to automatically post new items from the Planet Evergreen RSS feed to the Evergreen Twitter account. |
| 08:36 |
kmlussier |
It's supposed to check the feed every half hour, but it still hasn't sent out yesterday's afternoon post regarding OPW |
| 08:37 |
|
Shae joined #evergreen |
| 08:37 |
|
mrpeters joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:44 |
csharp |
berick++ # RM |
| 08:44 |
csharp |
kcls++ # sharing berick |
| 08:45 |
csharp |
+1 to easier installation |
| 08:45 |
csharp |
opw++ |
| 08:45 |
csharp |
okay, I think that catches me up |
| 08:46 |
kmlussier |
csharp: Heh, it's fun watching you catch up |
| 08:46 |
csharp |
:-D |
| 08:46 |
|
ericar joined #evergreen |
| 08:46 |
* csharp |
drove down to the soutwest tip of Georgia and back yesterday, so was utterly out of pocket |
| 08:57 |
|
RoganH joined #evergreen |
| 09:01 |
* wsmoak |
also thought that bit was interesting |
| 09:02 |
wsmoak |
getting a dev environment running is a pretty big barrier to contribution… |
| 09:02 |
csharp |
yeah |
| 09:03 |
csharp |
btw, I'm one who would volunteer to help new devs get things up and running, for the record |
| 09:03 |
wsmoak |
I don’t even know how much it would cost (or how it works) but what about some sort of image that runs on Amazon or Google’s things? |
| 09:04 |
wsmoak |
I’d be willing to pay for the server time (vs. running my own server here, which is probably what it would take…) |
| 09:04 |
csharp |
you could definitely run a test server in the cloud, sure |
| 09:04 |
wsmoak |
but I need my very own instance to break and then press a button and re-make |
| 09:05 |
RoganH |
There are a couple of tools floating around for making VMs that you could do development on. |
| 09:05 |
csharp |
you would need maybe 8 - 16 GB of storage, minimum 4 GB RAM, and 2 - 4 processor cords |
| 09:05 |
csharp |
s/cords/cores/ |
| 09:05 |
mrpeters |
VM's and snapshots are the easy reset button :P |
| 09:05 |
RoganH |
csharp: I thought you were going to break out into 80s power cords there for a minute. :) |
| 09:06 |
RoganH |
berick's scripts pop to mind which I've used |
| 09:06 |
RoganH |
tsbere also has a method that I've heard good things about though I haven't tried it myself. I know kmlussier uses it for building VMs for bug testing. |
| 09:06 |
Stompro |
I really liked the Evergreen VM that used to be available.. but I realize that it takes a bit of work to keep it up to date. |
| 09:07 |
wsmoak |
it needs to not be a separate thing that only new devs ever use … or it won’t get maintained |
| 09:07 |
mrpeters |
yeah the vm thing never worked well |
| 09:07 |
csharp |
RoganH: you mean like this? https://www.youtube.com/watch?feature=player_detailpage&v=zpOULjyy-n8#t=90 |
| 09:07 |
RoganH |
it's too awkward to have a single community one for development, different needs run into each other too much |
| 09:07 |
wsmoak |
or fix the underlying problem — installation/deployment should not be that hard |
| 09:07 |
mrpeters |
i think the intent though is that they want new dev's to be capable of installing Evergreen themselves from the readme |
| 09:08 |
RoganH |
csharp++ |
| 09:08 |
mrpeters |
wsmoak: what do you find most difficult about installation? |
| 09:08 |
RoganH |
My wiki-fu is failing me but kmlussier linked both tools on the wiki somewhere. |
| 09:11 |
wsmoak |
mrpeters: really??? http://evergreen-ils.org/documentation/install/README_2_7.html :) |
| 09:11 |
Stompro |
RoganH: http://wiki.evergreen-ils.org/doku.php?id=server_installation:semi_automated |
| 09:12 |
RoganH |
Stompro++ |
| 09:12 |
mrpeters |
wsmoak: how is that different from installing anything else from source code though? |
| 09:12 |
|
maryj joined #evergreen |
| 09:12 |
wsmoak |
basically, I do not want to be a sysadmin. I *can* do those things, I have done, but it’s not what I want to spend my time on these days. |
| 09:12 |
RoganH |
Installing Evergreen really isn't that hard, it's just very time consuming and methodical, hence the tools to speed it up. |
| 09:12 |
RoganH |
Note that these are for doing bug testing and development, not building a production environment. |
| 09:12 |
mrpeters |
i'll give you time consuming for sure |
| 09:13 |
mrpeters |
but, to fix bugs, you should be capable of installing OpenSRF/Evergreen |
| 09:13 |
RoganH |
I agree. |
| 09:13 |
mrpeters |
how are you going to fix something you break if you aren't able to do a scratch install, you know? |
| 09:13 |
Stompro |
I hate editing the xml files... the fact that sometimes it's <password> and sometimes its <passwd>. And dealing with all the ejabberd accounts. |
| 09:14 |
mrpeters |
for me, personally, the solution to the time consuming bit is using VMWare (though Virtualbox would work fine too) and using snapshots |
| 09:14 |
RoganH |
I was trying to point out tools that can help with blasting and rebuilding a test build of Evergreen, not saying that they void the need to have the underlying skills. |
| 09:14 |
wsmoak |
:::shrug::: I don’t really want to fix bugs. I want to play with it and write against the api and see how it all works and *then* maybe get more involved. |
| 09:15 |
mrpeters |
no, I agree with you RoganH. Once you can perform the install once, no need to repeat it over and over again (though, it does become like muscle memory to install Evergreen eventually haha) |
| 09:15 |
RoganH |
using Virtual Box snapshots can work most of the time as well though I'd argue sometimes it's good to just be able to do a quick new build from git |
| 09:16 |
mrpeters |
RoganH: true, only benefit to an "over the top" install from git is you don't have to screw with the config files |
| 09:16 |
mrpeters |
really, if OpenSRF didn't change, i think all you'd need to do is run autoreconf -i and then make and make install |
| 09:17 |
csharp |
wsmoak: if that's what you want, then build a stock 12.04 Ubuntu VM and install from GPLS's deb packages: http://archive.georgialibraries.org/ |
| 09:17 |
csharp |
that would certainly work on a cloud server |
| 09:17 |
wsmoak |
csharp: thanks, will keep that in mind |
| 09:18 |
Stompro |
csharp: I added info about the archinve.georgialibraires.org to the semi_automated page, it seems like if someone is looking for ways to automate the build, that should be included. |
| 09:18 |
csharp |
Stompro++ # thanks |
| 09:18 |
mrpeters |
csharp: maybe we should look into daily deb builds of master in another repo |
| 09:18 |
mrpeters |
could become a bit of a monster daily, but maybe a weekly or monthly build |
| 09:18 |
csharp |
not to re-hash recent discussions, but I'm puzzled as to why more new users *wouldn't* want to use our debs |
| 09:19 |
RoganH |
csharp: I'll have to try out your packages, that looks convenient |
| 09:19 |
wsmoak |
what I’m used to is something like: download .tar.gz, unpack, and run bin/start.sh |
| 09:19 |
csharp |
they're about as close to stock as you can get |
| 09:19 |
wsmoak |
(because I’m on OSX) |
| 09:19 |
mrpeters |
would keep us on our toes and lessen the changes we have to make when we build new versions of the debs because we're following master more closely |
| 09:20 |
wsmoak |
embed a “lite’ database of some kind that it can use internally, and Just Work. |
| 09:20 |
csharp |
wsmoak: well, if you can run VirtualBox on your Mac and build an ubuntu server guest, just follow the instructions at the archive.georgialibraries.org site and you'll be up and running within minutes |
| 09:21 |
wsmoak |
… but that leans a lot on Java’s built-in stuff I know, with the ability to swap out data sources easily |
| 09:21 |
RoganH |
If you're running OSX virtual box is your friend. |
| 09:21 |
mrpeters |
heck yeah it is |
| 09:21 |
csharp |
wsmoak: we do have a test dataset (not automatically installed by the .deb package, fwiw) |
| 09:21 |
RoganH |
You can pay for VMWare (I used to) but Virtual Box has gotten so good in the last few years. |
| 09:22 |
mrpeters |
when i was at ISL my "master" server for submitting new patches, development, etc. was just a virtualbox VM on their OS X server |
| 09:22 |
mrpeters |
csharp: we could make the test data load SO easy. There is a flag now for eg_db_config to load all of that |
| 09:22 |
mrpeters |
i discovered it monday |
| 09:23 |
mrpeters |
--load_all_test or something |
| 09:23 |
mrpeters |
we could add that to our debs pretty easily i think |
| 09:23 |
csharp |
yep |
| 09:24 |
mrpeters |
maybe have it set up so you can do an apt-get install evergreen-ils and apt-get install evergreen-ils-populateddb |
| 09:24 |
csharp |
I wonder if it should be a separate deb, though |
| 09:24 |
mrpeters |
^^ great minds :) |
| 09:24 |
csharp |
right |
| 09:25 |
mrpeters |
but i am 100% in agreement with whoever yesterday was saying that you should at least do the install once or twice. If you can't, you'll struggle to fix things as you are developing code. |
| 09:28 |
wsmoak |
I agree … but it shouldn’t have to be the *first* thing you have to do as you begin to get involved |
| 09:29 |
wsmoak |
but it depends on the kind of contributors you are trying to attract, too |
| 09:29 |
RoganH |
Part of the history of the Evergreen community is that the vast majority of the developers have been sysadmins too so the two have been interlinked. |
| 09:32 |
kmlussier |
RoganH: I posted links to berick's install script and tsbere's VM builder on the OPW page in the "Learning About Evergreen" section. http://wiki.evergreen-ils.org/doku.php?id=opw |
| 09:33 |
RoganH |
kmlussier: that's why I couldn't find it, I was looking at the bug squashing stuff. baka no rogan |
| 09:36 |
jeff |
bshum, gmcharlt, other web folk: passing along some feedback from jcoyne in #code4lib regarding the downloads page (paraphrasing): it would be nice to have the git:// url of the repository near the gitweb link. as it stands now, the git:// repo url needs to either be guessed/inferred or you need to click another link from the gitweb branch display |
| 09:37 |
|
jwoodard joined #evergreen |
| 09:37 |
|
yboston joined #evergreen |
| 09:37 |
mrpeters |
jeff: the clone URL you mean? |
| 09:38 |
jeff |
right -- the url to the repo / remote as opposed to the url to the gitweb display. git://git.evergreen-ils.org/Evergreen.git |
| 09:38 |
mrpeters |
yeah, good point. its on http://git.evergreen-ils.org/?p=Evergreen.git;a=summary right at the top, but probably wouldnt hurt to add to whichever static page he means on evergreen-ils.org |
| 09:39 |
mrpeters |
did he mention exactly which page he meant by the "downloads" page? |
| 09:39 |
mrpeters |
i guess /egdownloads does have the git repo links |
| 09:39 |
mrpeters |
but, i dont know that you can "clone" just one tag, can you? |
| 09:40 |
mrpeters |
i think thats what we link to now |
| 09:40 |
bshum |
There are ways to do it, I'm sure. |
| 09:40 |
mrpeters |
maybe we could change that to "Git Tag | Git Clone URL" |
| 09:40 |
bshum |
Indeed. |
| 09:41 |
mrpeters |
http://git.evergreen-ils.org/?p=Evergreen.git;a=shortlog;h=refs/heads/rel_2_7 | git://git.evergreen-ils.org/Evergreen.git |
| 09:41 |
bshum |
What I might suggest is another row (gah) for that then |
| 09:41 |
bshum |
I *like* the gitweb view of all the commits |
| 09:41 |
mrpeters |
me too |
| 09:41 |
kmlussier |
me three |
| 09:41 |
mrpeters |
what about a footnote in smaller print below that that gives the clone url in plain text |
| 09:41 |
mrpeters |
because a "link" won't do you much good if what you need to do is git clone git://git.evergreen-ils.org/Evergreen.git |
| 09:42 |
* kmlussier |
wonders how this might fit into the new downloads page graced and I are supposed to be working on. |
| 09:42 |
bshum |
Well I could see a git link being handy if one had a tool installed on their system to follow those links |
| 09:42 |
jeff |
right. either specify the url elsewhere on the page and specify the git branch, or specify the git url and the branch next to each other for each release, or just have a link on the downloads page to a "git details" page... many many options. |
| 09:42 |
bshum |
No? |
| 09:42 |
mrpeters |
true, i think Windows may have some tools that would handle git:// protocols, not sure on Linux |
| 09:42 |
* graced |
feels guilty for not getting to that with kmlussier |
| 09:42 |
jeff |
mrpeters: all of this suggestion is link as text to copy, not a clickable link. |
| 09:44 |
mrpeters |
jeff++ |
| 09:44 |
mrpeters |
let me mock something up real quick |
| 09:46 |
jboyer-isl |
The reason a link might be better than plaintext, even without a git:// url handler, is that many (all?) browsers have a right-click "Copy URL" or link, etc. that's one less thing to do (selecting only the text of the url). |
| 09:46 |
bshum |
Maybe what we should do is to add a new section |
| 09:46 |
bshum |
"How to clone Evergreen" or whatnot |
| 09:47 |
bshum |
And put the link in there |
| 09:47 |
bshum |
Along with links to the dev:git page |
| 09:47 |
jboyer-isl |
It doesn't have to be called out very much, most people will want the downloads. The people who care about the clone url will recognize it. |
| 09:47 |
bshum |
And change the name of the row to "Git Summary" or something instead of Repository |
| 09:47 |
bshum |
The more I read, the more I think the git URL will be the same |
| 09:48 |
bshum |
But we have to specify something like how to check out a specific branch? |
| 09:48 |
bshum |
Since it'll clone the same repo, but you can choose which branch to view a particular series. |
| 09:48 |
mrpeters |
http://i.imgur.com/kK3bWLP.jpg --- my idea |
| 09:48 |
bshum |
Or maybe I'm missing something in my reading so far for git urls |
| 09:49 |
mrpeters |
oooh here we go |
| 09:49 |
mrpeters |
git clone -b mybranch --single-branch git://sub.domain.com/repo.git |
| 09:49 |
jeff |
jboyer-isl: there's also the style that many sites use where you click the text and it's all hilighted or copied to your clipboard or there's a small button to copy to your clipboard, etc. github, bitbucket, etc. |
| 09:49 |
kmlussier |
I think it would be better to link to the existing git page for instructions rather than providing instruction on the downloads page. |
| 09:49 |
mrpeters |
that is also not a bad idea |
| 09:49 |
bshum |
mrpeters: aha |
| 09:50 |
mrpeters |
i guess if you know what "Git" is though, you probably will understand what to do with the clone URL |
| 09:50 |
mrpeters |
(is that still considered a URL?) |
| 09:51 |
jeff |
kmlussier: yep, i'm leaning toward that as well. perhaps a hybrid approach of having the git clone url on the downloads page with a "more git info" link that takes you to an existing or new page regarding how we use git (evergreen-specific things you should know, etc) |
| 10:00 |
jboyer-isl |
mrpeters, Probably a URI if you want to be picky, I can never remember the difference |
| 10:00 |
mrpeters |
heh yeah |
| 10:03 |
Stompro |
Does anyone have a "New Patron Welcome Email" notice that they use? We currently try to email a new customer right away, so that if their email is bad the staff have a chance to fix it while the customer might still be in the building. I just need to figure out if that is possible with action triggers. |
| 10:04 |
mrpeters |
so, if gpls were to host a deb of the current "stable" release with and without test data would the community advertise that as a "quick start" or would that still meet resistance because it doesn't account for installing the software, and could **potentially** cause someone to accidentally upgrade the package when they didn't intend to |
| 10:06 |
Stompro |
mrpeters: I'm pretty new, but I would support that and I would help add it to the community install docs. |
| 10:06 |
kmlussier |
berick++ |
| 10:07 |
Stompro |
mrpeters: would it be Ubuntu only or could Wheezy and Jessie users make use of it? |
| 10:07 |
kmlussier |
Stompro: I looked into it once, but didn't get very far. That's not to say it isn't doable. I just don't have a good handle on action triggers. |
| 10:08 |
kmlussier |
I think it's a fabulous idea! |
| 10:08 |
mrpeters |
we would have to build seperate debs for those, i think |
| 10:08 |
mrpeters |
debian has some slightly different install steps |
| 10:08 |
bshum |
mrpeters: I think that's an interesting offer. Though I'm always curious to see the deb building process you guys have come up with in action. |
| 10:08 |
mrpeters |
I could make a demo video |
| 10:09 |
mrpeters |
i just hate hearing my own voice narrate it....and today is NOT the day to do that....60 degrees to 22 degrees in 12 hours did not help my throat |
| 10:11 |
mrpeters |
there is a little work done (Andy Witter usually handles it) to build any new debs for things that would normally get installed from source (spidermonkey, etc.) but if those don't change much from version to version, its really just grab the tarball and put it in a certain location and then run a script |
| 10:11 |
mrpeters |
you can pick "cluster" or "single server" |
| 10:11 |
mrpeters |
for the repo, its single server |
| 10:12 |
mrpeters |
only half of that I don't have a lot of knowledge on yet is the actual apt archive |
| 10:12 |
mrpeters |
not sure where Andy sticks the built debs up to update the repo |
| 10:13 |
mrpeters |
i just tell him hey, i built the 2.7.1a debs can you update the repo and link him my deb |
| 10:14 |
mrpeters |
one thing that would be cool, and im not sure if it could be done, is to have ALL of the old debs still there too, so you could do say, apt-get install evergreen-ils-2.0.4 and get the 2.0.4 build installed |
| 10:14 |
mrpeters |
wouldn't see many reasons to do that, other than nostalgia or testing "did this act differently before?" but could be handy |
| 10:17 |
bshum |
With deb files, wouldn't the version be part of the package name though? |
| 10:17 |
bshum |
Usually |
| 10:18 |
mrpeters |
yeah, i think traditionally it is |
| 10:18 |
mrpeters |
since we just keep only the latest deb on the server, its just generic evergreen-ils |
| 10:18 |
mrpeters |
and archive.georgialibraries.org lets you know which version |
| 10:37 |
mrpeters |
Stompro: im sorry, i started answering your question about a new patron email and forgot to finish :P |
| 10:37 |
mrpeters |
I think it would be possible. I'm not sure if there is a reactor available yet for "New Patron Created" (I could be wrong though) but I think you could pull this off |
| 10:38 |
mrpeters |
i had an A/T event that ran when a patron's account expired in 30 days (the bad side effect was it only ran once) so if a patron expired a second time, no email! |
| 10:38 |
mrpeters |
but that would be ok in this case |
| 10:38 |
mrpeters |
wondering if we might adapt that to what you need |
| 10:43 |
Stompro |
Yes, that could work, just set to our normal expiration date, -3 Years with no repeat_delay set. I wonder if there is anything that can target email address changes also? |
| 10:43 |
mrpeters |
oh, did i misread? i thought you only wanted to email a customer when they were newly registered |
| 10:46 |
Stompro |
Nope, Just thinking the process through. Right now I just look for new accounts and send one email, but ideally I would want to send a new email if it turns out that the initial email is invalid. It might make sense to send a confirmation email any time an email gets changed. |
| 10:47 |
mrpeters |
ah, i see |
| 10:47 |
mrpeters |
but you would benefit from an A/T event definition that sends an email when a new actor.usr is created (provided they have an email address in the registration) |
| 10:48 |
mrpeters |
I think most of the infrastructure is there for something like that, only thing im not sure about is the reactor for a new row in actor.usr |
| 10:49 |
Stompro |
Yes, we would use that. And I bet some locations would also like to send postal mail to new customers also, to confirm new mailing addresses and to send out welcome packets. We have toyed with that idea. So it would probably be useful in general. |
| 10:49 |
mrpeters |
Yeah, i think that is an excellent justification to file a wishlist bug |
| 10:50 |
mrpeters |
you have several clear uses for it that i think lots of libraries would be interested in |
| 10:50 |
|
akilsdonk joined #evergreen |
| 10:51 |
Stompro |
mrpeters++ thanks for the ideas. |
| 10:52 |
Stompro |
I'll submit a wishlist bug. |
| 10:52 |
|
mllewellyn joined #evergreen |
| 10:52 |
mrpeters |
awesome. i think that could be a really cool feature. |
| 10:56 |
|
jboyer-isl joined #evergreen |
| 10:56 |
|
rjackson-isl joined #evergreen |
| 10:56 |
|
nhilton joined #evergreen |
| 10:57 |
|
rjackson_isl joined #evergreen |
| 10:59 |
* phasefx_ |
tweaked the wheezy installer link on the semi_automated page to point to a README |
| 11:17 |
|
sarabee joined #evergreen |
| 11:22 |
|
jboyer-isl joined #evergreen |
| 11:23 |
|
rjackson-isl joined #evergreen |
| 11:44 |
Stompro |
mrpeters: Bug 1392396 - Should i be using the blueprint feature for something like this in the future? |
| 11:44 |
pinesol_green |
Launchpad bug 1392396 in Evergreen "Wishlist: Action Trigger for new user creation" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1392396 |
| 11:45 |
mrpeters |
hmm not sure, i haven't used it before |
| 11:45 |
mrpeters |
loooks good though |
| 11:47 |
kmlussier |
Stompro: The community very rarely uses the blueprint feature. I think it would be just as good to outline what you propose right on the LP bug. |
| 11:49 |
|
sandbergja joined #evergreen |
| 11:55 |
* dbs |
concurs with kmlussier++ |
| 11:59 |
csharp |
@dunno add Sorry, we can't do that because, you know, SOFTWARE. |
| 11:59 |
pinesol_green |
csharp: The operation succeeded. Dunno #34 added. |
| 12:00 |
kmlussier |
csharp++ |
| 12:02 |
bshum |
kmlussier++ # good advice on transcendent bibs vs. $9 CONS asset.uri's |
| 12:02 |
|
Callender_ joined #evergreen |
| 12:25 |
jboyer-isl |
kmlussier, bshum, where might this advice be found? I'd like to have a look-see. |
| 12:26 |
kmlussier |
jboyer-isl: In a private message exchange? :) |
| 12:26 |
jboyer-isl |
(though now it's time to head AFK and to the DC. :-( / :-D ) |
| 12:26 |
kmlussier |
I was just suggesting that bshum change some bibs with a transcendent big source to use located URI's at the top of the org tree. |
| 12:26 |
bshum |
I was just musing on how transcendent bibs don't show up as links in the search results. And she suggested using $9 CONS to make them visible consortially and bypass that. |
| 12:27 |
jboyer-isl |
Oh, ok. I thought it was more about visibility differences. OK. |
| 12:27 |
kmlussier |
But the other benefit of the located URI approach is that they won't show up in copy location limited searches, which can sometimes be weird. |
| 12:27 |
|
ericar joined #evergreen |
| 12:27 |
jboyer-isl |
That was one of my concerns when we were loading more trancendent records. |
| 12:27 |
* jboyer-isl |
vanishes. |
| 12:28 |
kmlussier |
For example, if somebody limits a search to children's copy locations and finds a copy of the karma sutra from Project Gutenberg. |
| 12:36 |
tsbere |
Making transcendent records not show up with copy location searches would be easy, BTW. <_< |
| 12:37 |
* tsbere |
isn't sure if it is a good idea or not, though |
| 12:37 |
kmlussier |
Adding a subfield 9 at the top of the org tree is also easy. :) |
| 12:37 |
tsbere |
kmlussier: Unless you have the option to scope URIs like Copies turned on. Then things become harder. |
| 12:39 |
kmlussier |
How so? I always found the scoping for located URI's to work fairly well for consortium-wide resources. The "scope URIs like copies" helped with resources owned by ou's lower down in the org tree. |
| 12:40 |
tsbere |
kmlussier: If you turn the URIs like copies option on then "top of the org tree" URIs only show up when searching from the top of the org tree. Limit yourself to anything lower and as far as I know they would stop showing up. |
| 12:40 |
kmlussier |
No, that's wrong |
| 12:43 |
tsbere |
kmlussier: I would argue then that the setting is horribly mis-named, then, because it isn't acting like a copy. |
| 12:44 |
* kmlussier |
notes that all of the examples in the docs at http://docs.evergreen-ils.org/2.7/_cataloging_electronic_resources_8201_8212_8201_finding_them_in_catalog_searches.html#_adding_a_located_uri_to_the_record were working as described back in the summer. |
| 12:44 |
jeff |
are they no longer working as described? |
| 12:44 |
kmlussier |
tsbere: If the subfield 9 is set to the consortium without the setting enabled, then it will show up in searches all the way down the org tree. But if it's set at a system or branch level, it only travels down, not up. |
| 12:45 |
kmlussier |
jeff: I believe they are. I haven't tested it since then. |
| 12:45 |
kmlussier |
tsbere: If you enable the setting, then the resource shows up both up and down the org tree. So if it's owned by a system and you search the consortium, it still shows up. Like copies do. |
| 12:45 |
tsbere |
kmlussier: As far as I know, copies only travel "up", not "down", so if the setting makes them travel *both* ways then URIs aren't acting as copies. |
| 12:46 |
tsbere |
kmlussier: Which would make the setting's name horribly wrong. :P |
| 12:46 |
kmlussier |
tsbere: If your search is scoped to the consortium, you don't see copies owned by a branch? |
| 12:47 |
tsbere |
kmlussier: If my search is scoped to a sublibrary I don't see copies owned by the main library it is under, but the main library search would include the sublibrary. The same two searched without the "uris as copies" setting active would show the main library URIs when searching the sublibrary but not the sublibrary URIs when searching the main library. |
| 12:48 |
tsbere |
If the uris as copies option is turned on and doing what you say then they are not acting as copies as they are scoping *both* ways and copies only scope *one* way. |
| 12:50 |
kmlussier |
tsbere: You're right. But what you said above is that if the consortium were located in subfield 9, it wouldn't show up in searches that are limited further down the org tree. But they do, regardless of the state of that setting. |
| 12:50 |
tsbere |
kmlussier: And on that front, the label for the setting is "When enabled, Located URIs will provide visiblity behavior identical to copies." < Scoping *both* directions is *not* identical to copies. As such, I would call that a bug. |
| 12:51 |
kmlussier |
I think a big difference is that, except in cases like the sub-library example, ou's higher up the org tree do not own copies, whereas they do for electronic resources. |
| 12:51 |
tsbere |
kmlussier: Whether or not we *want* located URIs to scope both directions (with option or otherwise) is a different issue. As it stands, there is currently no way to make them act identically to copies, despite the option saying that is what it does. :p |
| 12:52 |
jeff |
i find myself curious how a copy behaves when you DO associate it with a circ_lib of the top-of-tree :-) |
| 12:52 |
kmlussier |
jeff: The same question just occurred to me. :) |
| 12:52 |
tsbere |
jeff: I seem to recall it only shows up when scoped to the top of the tree. |
| 12:52 |
* tsbere |
has done stuff like that before |
| 12:54 |
kmlussier |
I guess the specific name of the settings was used to show how enabling it differs from default behavior. The default behavior is what makes the electronic resource show up in searches higher up the org tree. Enabling the settings is what allows it to travel down, as copies do. |
| 12:56 |
tsbere |
kmlussier: My (current) point being that the name and description *don't match what it does* - Copies by default travel "up" the tree, URIs by default travel "down" the tree, that option tells URIs to travel "up AND down" the tree. That is not acting like copies. That is acting like a combination of copies and URIs at the same time. |
| 12:58 |
* tsbere |
is assuming that kmlussier's assertion about things is true, BTW, and has not tested or dug the actual code up at this point |
| 13:00 |
dbwells |
I agree with tsbere that the setting doesn't really do what it claims. Anyone interested in all the various cans of worms should check out ldw's bug #1353643. I suspect the fallout from that will clarify the original setting as well. |
| 13:00 |
pinesol_green |
Launchpad bug 1353643 in Evergreen "URI $9 displayes too many links in TPAC" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1353643 |
| 13:05 |
* eeevil |
is running to a doctor's appointment (already late) but the setting is to make URIs act like copies /in that/ they scope "down". it doesn't remove the "up" scoping, though. electronic resource limiting is about modeling access rights, where the uri owner (and it's subordinates) should have access |
| 13:06 |
eeevil |
so, maybe the description for the setting should be "make uris act more like copies, but not exactly, because they're different things" |
| 13:06 |
* tsbere |
wishes we could decide which way is up and which way is down when talking about this |
| 13:07 |
kmlussier |
+1 to eeevil's suggested wording. |
| 13:07 |
|
nhilton joined #evergreen |
| 13:07 |
tsbere |
Perhaps something like "When enabled, Located URIs will provide visiblity behavior similar to copies in addition to their normal visibility behavior." |
| 13:11 |
kmlussier |
The thought that occurred to me while writing the documentation re-occurs to me now. The name of that setting is unusually long. Makes for awkward wording in the docs. |
| 13:11 |
* kmlussier |
doesn't have a suggestion for better wording. |
| 13:13 |
|
Callender_ joined #evergreen |
| 13:15 |
|
nhilton_ joined #evergreen |
| 13:19 |
|
nhilton joined #evergreen |
| 13:20 |
|
ericar joined #evergreen |
| 13:21 |
tsbere |
kmlussier: The name is unusually long? |
| 13:22 |
|
ericar_ joined #evergreen |
| 13:22 |
tsbere |
kmlussier: The name is one of the shorter ones. The label isn't unusually long either, all things considered. |
| 13:23 |
tsbere |
opac.browse.holdings_visibility_test_limit is the longest name (42 chars) and opac.use_autosuggest has the longest label (212 chars) |
| 13:25 |
|
jihpringle joined #evergreen |
| 13:25 |
kmlussier |
tsbere: Label. You have to remember, I tend to speak like an end user. Sorry for the confusion. |
| 13:28 |
|
mdriscoll1 left #evergreen |
| 13:30 |
|
mdriscoll joined #evergreen |
| 13:32 |
|
hbrennan joined #evergreen |
| 13:35 |
|
wsmoak left #evergreen |
| 13:37 |
|
kakes joined #evergreen |
| 13:40 |
pinesol_green |
[evergreen|Fredric T Parks] LP#1246839: marc_stream_importer.pl no longer crashes with vs 0.23 of File::Temp - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a10f881> |
| 13:50 |
|
Christineb joined #evergreen |
| 13:50 |
|
remingtron2 joined #evergreen |
| 13:54 |
|
susie joined #evergreen |
| 13:55 |
kmlussier |
Heads up. Evergreen for Academics meeting starts here in 5 minutes. |
| 13:56 |
pinesol_green |
[evergreen|Kathy Lussier] Add KPAC configuration info to the community docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=93c850b> |
| 13:56 |
pinesol_green |
[evergreen|Josh Stompro] LP#1116387 - adding kpac setup notes. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c1b9fa3> |
| 13:56 |
pinesol_green |
[evergreen|Josh Stompro] LP#1083639 - Added command to copy fonts into the KPAC2 / Alternate monster skin dir - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4da8069> |
| 13:56 |
pinesol_green |
[evergreen|Galen Charlton] LP#1083639: use "cp -r" instead of "cp -R" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=95b4cd6> |
| 13:56 |
|
tspindler joined #evergreen |
| 13:57 |
kmlussier |
Wow - that's an old one |
| 14:00 |
kmlussier |
#startmeeting 2014-11-13 - Evergreen for Academics meeting |
| 14:00 |
pinesol_green |
Meeting started Thu Nov 13 14:00:20 2014 US/Eastern. The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:00 |
pinesol_green |
The meeting name has been set to '2014_11_13___evergreen_for_academics_meeting' |
| 14:00 |
kmlussier |
#info Meeting agenda is available at http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen_for_academics:2014-11-13 |
| 14:00 |
kmlussier |
#topic Introductions |
| 14:01 |
kmlussier |
Please introduce yourselves with the #info command. |
| 14:01 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 14:01 |
mdriscoll |
#info mdriscoll is Martha Driscoll, NOBLE |
| 14:01 |
kakes |
#info kakes is Kelly Drake, FLO |
| 14:01 |
tspindler |
#info tspindler is Tim Spindler, C/W MARS |
| 14:02 |
yboston |
#info yboston - Yamil suarez, Berklee College of Music |
| 14:02 |
Christineb |
#info Christineb is Christine Burns BC Libraries Cooperative |
| 14:03 |
kmlussier |
Rather than going through the past action items, which are very similar to the new business items, I think we can dive into each subgroup area to see where we're at. |
| 14:04 |
kmlussier |
#topic Academic PAC flavor |
| 14:04 |
kmlussier |
yboston: Can I hand over the updating to you on this one? |
| 14:04 |
yboston |
sure |
| 14:04 |
yboston |
I don't hvae an update for the PAC flovor group, except... |
| 14:05 |
yboston |
that I put together a wiki page from the main Evergreen for academics page |
| 14:05 |
yboston |
http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen_for_academics:pac_academic_flavor |
| 14:05 |
yboston |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen_for_academics:pac_academic_flavor |
| 14:06 |
yboston |
going forward I can send out an email to solicit comments on how this group wants to proceed |
| 14:06 |
yboston |
any comments so far? |
| 14:06 |
yboston |
kmlussier: feel free to make an action item for me |
| 14:07 |
kakes |
looks good, I'm surprised DanB hasn't commented |
| 14:07 |
kmlussier |
I think one thing we need to do is look at the suggestions that have already been made and figure out which ones are truly academic issues and which ones should be LP bugs/feature requests for the overall catalog. |
| 14:07 |
yboston |
makes sense |
| 14:08 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1246371: Allow BibCommon::title_is_empty to accept a bre id or bre object. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=984b402> |
| 14:08 |
|
Callender_ joined #evergreen |
| 14:08 |
yboston |
would you like me to pull that data together? maybe you can send the follow up email for the group? |
| 14:08 |
yboston |
or viceversa? |
| 14:08 |
kmlussier |
In my mind, the one that might play into academic flavor is perhaps a view with more fields displaying. Everything else seems to be general catalog issues. |
| 14:09 |
kmlussier |
yboston: No, we can start with your email soliciting general comments. |
| 14:09 |
yboston |
OK, |
| 14:10 |
kmlussier |
#action yboston to send email to list on how to proceed with academic flavor ideas. |
| 14:10 |
kmlussier |
Does anybody else want to add anything on the academic flavor topic? Or throw out some ideas now on what we should be doing here? |
| 14:11 |
kmlussier |
#topic Batch Patron Functions |
| 14:11 |
kmlussier |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen_for_academics:batch_patron_functions |
| 14:11 |
kmlussier |
I know mdriscoll has done a bit of work on this. |
| 14:11 |
|
akilsdonk_ joined #evergreen |
| 14:11 |
mdriscoll |
Yes, those are my notes based on lots of patron loads |
| 14:12 |
mdriscoll |
I tried to include all the issues I run into when loading files |
| 14:13 |
mdriscoll |
I would also like to see batch patron update and delete functionality. |
| 14:13 |
yboston |
mdriscoll++ |
| 14:13 |
|
jck_ joined #evergreen |
| 14:13 |
mdriscoll |
I know the database has patron buckets but no front-end to use them |
| 14:13 |
tspindler |
batch update and delete would be great |
| 14:13 |
kmlussier |
So those look like they could potentially be two different projects. |
| 14:13 |
mdriscoll |
They would probably be two different interfaces, so two different projects makes sense |
| 14:14 |
kmlussier |
mdriscoll: I'm thinking batch loading of patron records may run into similar issues as batch loading records. Maybe I'll look at some of the issues we've run across there to see if any may be things we should be thinking about for these requirements. |
| 14:15 |
mdriscoll |
Sounds good. |
| 14:15 |
|
DonB joined #evergreen |
| 14:16 |
kmlussier |
Does anyone have any specific comments or suggestions for these projects right now? |
| 14:16 |
kmlussier |
If not, I think this would also be a good one to share via the list for feedback. But they look really good to me. |
| 14:16 |
pinesol_green |
[evergreen|Josh Stompro] LP#1384932: document the zips.txt ZIP code database feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=66544eb> |
| 14:16 |
kmlussier |
mdriscoll++ |
| 14:16 |
tspindler |
on the patron load, i think having good reporting on matches etc. would be good |
| 14:17 |
mdriscoll |
tspindler: agreed. I'm thinking of the vandelay interface where you can view every match. |
| 14:17 |
tspindler |
mdriscoll has a lot down though |
| 14:17 |
|
mrpeters joined #evergreen |
| 14:18 |
mdriscoll |
kmlussier: should I send a message to the general list looking for feedback? |
| 14:18 |
kmlussier |
It might also be good to identify a minimum number of records you expect the loading interface to handle. |
| 14:18 |
tspindler |
kmlussier++ |
| 14:18 |
* kmlussier |
doesn't know what this number should be, but she knows this is a big issue with bib record loading. |
| 14:19 |
mdriscoll |
Good idea. |
| 14:19 |
kmlussier |
mdriscoll: Yes, I'll put you down for an action item. |
| 14:19 |
mdriscoll |
I load 1000 records at a time but do see a hit on the db |
| 14:19 |
tspindler |
in our network it is probably 5000 |
| 14:19 |
tspindler |
we have community colleges that have that many |
| 14:19 |
mdriscoll |
That's why I put "don't impact running system" in the specs |
| 14:20 |
mdriscoll |
Nobody cares if the load slows down, but users care if the db slows down. It should not timeout either. |
| 14:20 |
kmlussier |
#action mdriscoll to send message to Evergreen list to get feedback on requirements for batch patron load and for batch batch patron updates/deletes through patron buckets |
| 14:20 |
tspindler |
mdriscoll++ |
| 14:20 |
kmlussier |
Thanks Martha! They look good. :) |
| 14:21 |
kmlussier |
Anything else on patron batches? |
| 14:21 |
kmlussier |
#topic Authorities |
| 14:22 |
kmlussier |
We have a link at http://evergreen-ils.org/dokuwiki/doku.php?id=authorities, but I think that's the pre-existing authorities page, right? |
| 14:22 |
tspindler |
First, I'm going to have to step down since I will have change in responsibilities starting January 1 |
| 14:22 |
kmlussier |
tspindler: Congrats, by the way! :) |
| 14:22 |
mdriscoll |
tspindler: congrats! |
| 14:22 |
yboston |
what is the new position? |
| 14:22 |
tspindler |
I start as executive director |
| 14:22 |
yboston |
Cool |
| 14:22 |
|
Stompro joined #evergreen |
| 14:23 |
tspindler |
I looked at yboston page closely and he has a lot of detail on there |
| 14:23 |
kmlussier |
tspindler++ |
| 14:23 |
tspindler |
i think it is a good start |
| 14:23 |
tspindler |
btw, jkranich will continue to participate here with the academics for us |
| 14:23 |
kmlussier |
I just want to note that there is some work being done on overlaying authorities via Vandelay. |
| 14:24 |
kmlussier |
Or, I should say, it looks like there is work being done. |
| 14:24 |
kakes |
yboston: it's a great start, very good list |
| 14:24 |
yboston |
BTW, I have been working with EG authorities for a while and could lead the group, but oly if someoe else takes over the LC group |
| 14:24 |
yboston |
*only |
| 14:24 |
kmlussier |
bug 1171984 |
| 14:24 |
pinesol_green |
Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 4, heat: 18) [Wishlist,Triaged] https://launchpad.net/bugs/1171984 - Assigned to Liam Whalen (whalen-ld) |
| 14:24 |
kakes |
kmlussier: who do you think is working on the overlay? |
| 14:25 |
kmlussier |
Are there still issues for the LC Call number group once dbwells's code is tested and merged? |
| 14:25 |
Stompro |
gmcharlt: Thanks for reviewing and committing the KPAC setup docs. gmcharlt++ |
| 14:25 |
kmlussier |
Sorry, that's the next agenda item. I withdraw the question. |
| 14:25 |
dbs |
#info dbs = Dan Scott, Laurentian University (with coffee in hand, finally) |
| 14:25 |
kmlussier |
kakes: It looks like berick has been working on it. |
| 14:25 |
kmlussier |
dbs: Welcome! I'm glad you have coffee. :) |
| 14:26 |
kmlussier |
MassLNC has also been talking to ESI to get some tweaking done for the browse authority work. |
| 14:27 |
kmlussier |
Other than yboston, is there anyone else who is willing to take over the authorities group? If not, is there somebody who can take over the LC Call Number group (if needed) so that yboston can focus on authorities? |
| 14:29 |
kmlussier |
yboston: Which area do you prefer to work on? |
| 14:29 |
yboston |
I think my co-workers would prefer I focus on authoritites |
| 14:29 |
yboston |
so we can move me to authorities for now, and look for a new volunteer for LC callnumbers later on |
| 14:30 |
kmlussier |
OK, then, I'm inclined to say you should lead that group and we'll deal with the other group in a minute. |
| 14:30 |
DonB |
#info DonB = Don Butterworth, Asbury Seminary. Was on the phone with YBP (Yankee Book Peddler). Evergreen EDI does *not* work with YBP. Another Academic issue for us. |
| 14:30 |
yboston |
I sitll have a smalll report for call numbers today |
| 14:30 |
kmlussier |
#action yboston to take charge of the authorities group. |
| 14:30 |
kmlussier |
I think authorities is a big area to tackle. |
| 14:30 |
DonB |
What would be involved in leading LC callnumber. I might be able to take that on. |
| 14:31 |
tspindler |
i think yboston has some of the biggest issues on the wiki page |
| 14:31 |
kmlussier |
Hold on a second. Anything else on authorities? |
| 14:31 |
kmlussier |
#topic Call Number Sorting |
| 14:32 |
kmlussier |
yboston: Can you start us with an update? |
| 14:32 |
yboston |
yes |
| 14:32 |
yboston |
I finally put in a bug for issues searching LC calnumbers in OPAC numeric searches; bug 1389403 |
| 14:32 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:32 |
yboston |
I then added a link inside the bug to some test code that Dan Wells wrote to address the issue. I saw that Kathy tried testing that code during the EG bug squashing day. |
| 14:32 |
yboston |
I still need to query the community to see what other LC call number issues need to be addressed |
| 14:33 |
kmlussier |
I still owe a response to dbwells regarding what we're seeing in the logs. |
| 14:33 |
yboston |
and I made a basic wiki page for this group too |
| 14:33 |
kmlussier |
I think I sent out a query to the Evergreen community. |
| 14:33 |
yboston |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen_for_academics:improved_lc_call_number |
| 14:33 |
yboston |
kmlussier: yes, you sent out an email, and I might have beent he only one that replied at the time? |
| 14:33 |
kmlussier |
#link http://georgialibraries.markmail.org/thread/wwdb2nrn4g4sunbb |
| 14:34 |
kmlussier |
I didn't get any other responses. Are there other issues you all have seen with LC Call number other than what was identified in the bug yboston just posted? |
| 14:35 |
kmlussier |
Because if that code fixes all of the LC issues that are out there, I don't think this sub-group is needed. |
| 14:36 |
kmlussier |
Sorry. There is also the issue with spine label printing that DonB identified in bug 1352542. |
| 14:36 |
pinesol_green |
Launchpad bug 1352542 in Evergreen "Printing: LC Call number formatting (2.5.2)" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1352542 |
| 14:37 |
dbs |
dbwells: are we normalizing the incoming call number label? /me isn't seeing that immediately in supercat |
| 14:38 |
remingtron |
dbwells is in a meeting at the moment |
| 14:38 |
yboston |
since we have one definite open bug, and one bug that has a fix awaiting more testing, we can keep the group open for now |
| 14:38 |
kmlussier |
DonB: Since you semi-volunteered up above, is this something you want to work through. At this time, I'm thinking it's primarily about identifying specific issues that are still out there. |
| 14:39 |
yboston |
I am sure there are other bugs I could report if I talk to the cataloger here, though she is on maternity leave right now |
| 14:39 |
* dbs |
sees that that's what the patch from dbwells is trying to do; seems reasonable |
| 14:40 |
DonB |
I'm willing to try to identify LC Call number issues and report back to the group, if that would be helpful |
| 14:40 |
kmlussier |
DonB: Yes, that would be very helpful. Thanks! |
| 14:40 |
kmlussier |
:) |
| 14:40 |
yboston |
DonB: that would help, also if you can add info tot he wiki page too |
| 14:40 |
kmlussier |
#action DonB to identify remaining LC Call Number issues and report back to the group. |
| 14:41 |
yboston |
I can help train you on using the wiki |
| 14:41 |
kmlussier |
Anything else on LC call numbers? |
| 14:41 |
DonB |
Willing to try. Thanks for being willing to teach the new guy |
| 14:42 |
yboston |
shoudl we set an action for you to give feedbacl to Dan? Don't think it is neccesary, just wondering |
| 14:42 |
kmlussier |
DonB: We like new people, so we're always willing to help the new guy. :) |
| 14:42 |
pinesol_green |
[evergreen|alzr] LP#1207529: Make sure $PATH includes /openils/bin when configuring - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=85f3866> |
| 14:42 |
pinesol_green |
[evergreen|alzr] LP#1207529: Add /openils assumption note - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e38ec30> |
| 14:42 |
yboston |
you being Kathy |
| 14:42 |
yboston |
we were all new like you once |
| 14:43 |
kmlussier |
#action kmlussier to post testing feedback for dbwells on bug 1389403 |
| 14:43 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:43 |
kmlussier |
Got it. |
| 14:43 |
kmlussier |
Those are all the sub-groups then. |
| 14:43 |
kmlussier |
Is there anything else anybody wants to bring up? |
| 14:44 |
DonB |
Does anybody else care about EDI working with YBP |
| 14:44 |
DonB |
? |
| 14:44 |
DonB |
It is a major player with academic vendors |
| 14:45 |
tspindler |
DonB: we have academics that use them but do not use EG acquisitions |
| 14:45 |
DonB |
And it frustrates me that the parent company Baker and Taylor has a working EDI with Evergreen |
| 14:45 |
DonB |
but not YBP |
| 14:45 |
tspindler |
YBP does noting with EDI? |
| 14:45 |
DonB |
It worked well with our legacy system |
| 14:45 |
kmlussier |
Is it just the invoicing/enriched EDI, or is it the ordering too? |
| 14:45 |
DonB |
Ordering |
| 14:46 |
dbs |
Is YBP specifically academic? /me really doesn't know |
| 14:46 |
DonB |
They are starting to lose my business because of all the hoops they make me jump through |
| 14:46 |
DonB |
Sorry. Maybe I'm just venting |
| 14:46 |
tspindler |
dbs: not sure but in my experience, i have only known academics to use them |
| 14:47 |
gmcharlt |
ditto |
| 14:47 |
kmlussier |
I think there are probably a number of vendors that EDI still doesn't support, but, with each of them, some development needs to be done to get Evergreen talking to them. |
| 14:48 |
kmlussier |
But it doesn't sound like there are many people in the channel right now who use them heavily and use EDI. Maybe it's a good question for the lsit. |
| 14:48 |
kmlussier |
s/lsit/list |
| 14:48 |
tspindler |
i was just talking to one of our staff, he worked for YPB and he said they were working to get set up with evergreen at the time about 3 years ago |
| 14:48 |
kmlussier |
If there are a few sites interested in it, it might be a good opportunity to pool funds to get the development done. |
| 14:49 |
DonB |
We need more academic libraries so we can get a mass critical enough to interest vendors like YBP and Harrassowitz |
| 14:50 |
kmlussier |
DonB: But is the problem that YBP is unwilling to work with Evergreen or that nobody on the Evergreen side of things has tried to get it to work with YBP? |
| 14:50 |
DonB |
kmlussier: We have tried to get it to work without success |
| 14:50 |
jihpringle |
we don't use YBP but I know we had to do some tweaking of the PO JEDI action trigger and the EDI fetcher/pusher to get Evergreen to work with the major Canadian public library vendors |
| 14:51 |
tspindler |
DonB: have you got it working with others? |
| 14:51 |
DonB |
kmlussier: It works with Baker & Taylor |
| 14:52 |
kmlussier |
I think a good start might be to query the list to see which other sites out there need EDI working with YBP. And then maybe you can, as a mass, try to get YBP to work with Evergreen. |
| 14:53 |
* mdriscoll |
runs off to another meeting |
| 14:53 |
kmlussier |
DonB: Does that sound like a good approach? |
| 14:53 |
DonB |
Might make for a good survey question. |
| 14:53 |
kmlussier |
Thanks for joining us mdriscoll! |
| 14:53 |
DonB |
What vendors do you use? and Who uses EDI? |
| 14:54 |
jihpringle |
we'd be interested in the results of that survey |
| 14:54 |
kmlussier |
I know a lot of our libraries use B&T, Ingram, Midwest Tape. tspindler may know of more. |
| 14:55 |
kmlussier |
What exactly would be the goal of the survey then? To see what vendors we want to see working with EDI? |
| 14:56 |
kmlussier |
If so, is anyone willing to create this survey? |
| 14:56 |
DonB |
Just to see how many libraries use EDI |
| 14:56 |
DonB |
and |
| 14:56 |
DonB |
How many would like to use EDI |
| 14:56 |
DonB |
and |
| 14:56 |
DonB |
Who would they like to use if they could |
| 14:57 |
jihpringle |
the end result would also be a list of known vendors that work with Evergreen's EDI |
| 14:57 |
kmlussier |
I think the survey is fine. But I think we're not stepping outside of the purely academic realm. Because all types of libraries use EDI. |
| 14:57 |
DonB |
Then perhaps we could use the results to get some vendors working on making the connections work with Evergreen |
| 14:58 |
DonB |
You're right Kathy |
| 14:58 |
kmlussier |
We're closely approaching the one-hour mark. Does anyone want to take this as an action item? |
| 14:58 |
DonB |
Maybe we could put this on the back burner as another academic library topic to address at a later date? |
| 14:58 |
tspindler |
kmlussier: we have librairies currently using only B&T, Ingram and Midwest Tape. We have not tried others. |
| 14:59 |
kmlussier |
Sure, that works for me. |
| 14:59 |
tspindler |
at lest with EDI. We have some tracking manual orders |
| 14:59 |
kmlussier |
Anything else before I wind things up? |
| 14:59 |
kmlussier |
Our next meeting is scheduled for 2 p.m. EST on December 11. |
| 15:00 |
kmlussier |
#info Our next meeting is scheduled for 2 p.m. EST on December 11. |
| 15:00 |
kmlussier |
#info Add an EDI survey as a future to-do item. |
| 15:00 |
kmlussier |
#endmeeting |
| 15:00 |
pinesol_green |
Meeting ended Thu Nov 13 15:00:27 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:00 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-11-13-14.00.html |
| 15:00 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-11-13-14.00.txt |
| 15:00 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-11-13-14.00.log.html |
| 15:00 |
jihpringle |
DonB: have you made any changes to the PO JEDI action trigger? |
| 15:00 |
yboston |
kmlussier++ |
| 15:01 |
DonB |
Not that I know of |
| 15:01 |
DonB |
I'm just a lowly cataloger |
| 15:01 |
kmlussier |
jihpringle: Do you think somebody from SITKA could share with DonB the steps you all had to take to get EDI working with a new vendor? |
| 15:02 |
jihpringle |
YBP doesn't come set up in the PO JEDI action trigger like B&T does |
| 15:02 |
DonB |
That would be great! |
| 15:02 |
jihpringle |
kmlussier: I'll ask ldw, I'm not entirely sure what he had to do, but I know there was quite a bit involved to get it working |
| 15:04 |
DonB |
Our IT folks are extremely busy right now with bringing up an Enterprise system. So the only way I can get there attention is with a Code Blue emergency |
| 15:04 |
DonB |
Or if I can give them very specific instructions. |
| 15:04 |
|
tspindler left #evergreen |
| 15:05 |
DonB |
Instructions from a SITKA person might be enough to get some action |
| 15:05 |
jihpringle |
DonB: I'll see what I can get for you |
| 15:06 |
DonB |
Thanks. If it doesn't work out, it's no problem. |
| 15:07 |
DonB |
Time to catalog some Spanish books. Bye all |
| 15:21 |
|
kmlussier left #evergreen |
| 15:47 |
|
hbrennan joined #evergreen |
| 15:56 |
dbs |
hey jihpringle -- does SITKA by any chance run EDI with Coutts? We would like that :) |
| 15:57 |
jihpringle |
dbs: no, right now we run EDI with Ingrams, United Library Services and Library Bound |
| 16:01 |
dbs |
jihpringle: cool, thanks -- that's a pretty impressive set |
| 16:06 |
|
jwoodard joined #evergreen |
| 16:33 |
|
mdriscoll left #evergreen |
| 17:05 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
|
mmorgan left #evergreen |
| 17:20 |
|
buzzy joined #evergreen |
| 18:01 |
|
kmlussier joined #evergreen |
| 18:15 |
|
kmlussier left #evergreen |
| 21:31 |
|
kmlussier joined #evergreen |
