| Time |
Nick |
Message |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:58 |
|
Callender joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 08:21 |
|
Dyrcona joined #evergreen |
| 08:27 |
|
dteston joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:34 |
Dyrcona |
So, with the release of 2.12.1, shouldn't working/user/blake/tags/rel_2_12_1 be copied to tags/rel_2_12_1? |
| 08:49 |
|
bos20k joined #evergreen |
| 08:49 |
Dyrcona |
I forgot about setting the pager to none when running the upgrade script.... |
| 08:49 |
Dyrcona |
So my time call will be irrelevant. |
| 08:49 |
Dyrcona |
invalid, whatever. |
| 08:56 |
gmcharlt |
Dyrcona: yes, it should be pushed |
| 08:56 |
gmcharlt |
I'll do it now |
| 09:00 |
Dyrcona |
OK. |
| 09:06 |
dbwells |
gmcharlt: I am about to push the 2.12.1 upgrade to master/rel_2_12, FYI |
| 09:06 |
gmcharlt |
dbwells: whoops, I think I just beat you to it |
| 09:07 |
dbwells |
gmcharlt: doh! That's okay :) |
| 09:07 |
gmcharlt |
one question for dbwells and bshum: should we cherry-pick the PO and POT updates from the tag branch into rel_2_12, or reserve that for 2.12.2? |
| 09:07 |
dbwells |
Just stuff I told Bmagic I would take care of. |
| 09:08 |
pinesol_green |
[evergreen|Galen Charlton] forward-port 2.12.0-2.12.1 database update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d636e5> |
| 09:09 |
|
collum joined #evergreen |
| 09:15 |
dbwells |
As long as Bmagic is handling the 2.12 builds, cherry-pick back to rel_2_12 seems like the easiest workflow to me, and I don't think it will make a difference. |
| 09:35 |
dbwells |
bshum: before we add the new pot files back to rel_2_12, I have a burning question I've always wondered about. |
| 09:36 |
bshum |
dbwells: gmcharlt: Yeah, I'd like to double check the contents before we merge it. |
| 09:36 |
bshum |
Just to make sure we didn't have any oddities |
| 09:37 |
bshum |
It looks okay from a glance |
| 09:37 |
dbwells |
bshum: Our standard practice is to exclude from the new pot commit "non-trivial changes". Is that solely to make the new pot commit cleaner, or does, for example, updating the "POT-Creation-Date" have some other undesirable side-effect on the LP side? |
| 09:38 |
bshum |
dbwells: My understanding is that it was a practice adopted to avoid seeing unnecessary churn in the git history for the files |
| 09:38 |
bshum |
To my knowledge it should have no impact to LP side of things |
| 09:39 |
|
Callender joined #evergreen |
| 09:39 |
dbwells |
So, perhaps nice to think about, but nothing to fret about. |
| 09:40 |
bshum |
That's my opinion. |
| 09:40 |
dbwells |
Sounds good to me. |
| 09:41 |
bshum |
gmcharlt: Eyeballing the POT and PO changes, nothing looks alarming to me from Bmagic's branch. Looks like building it on 14.04 with the older translate toolkit was a safe call |
| 09:42 |
Dyrcona |
Yeah, my understanding is the same as bshum on the pot exclusion. |
| 09:42 |
Bmagic |
yeah, I looked through it, looked ok |
| 09:42 |
bshum |
Bmagic++ |
| 09:42 |
dbwells |
I'm not sure the git history of an autogenerated file is ever going to be particularly useful :) |
| 09:47 |
dbwells |
bshum: Are you going to to ahead and push the pot/po bits to rel_2_12? If not, I can take care of it whenever you're done looking them over. |
| 09:50 |
|
rlefaive joined #evergreen |
| 09:54 |
bshum |
dbwells: Feel free to push away |
| 09:59 |
dbwells |
bshum: will do, thanks |
| 10:06 |
|
jvwoolf joined #evergreen |
| 10:15 |
dbwells |
bshum: So, I noticed in this po push the final deletion of string like "Example Branch 2". It seems like we would still want those translated for anyone trying out Evergreen. Perhaps we should add Open-ILS/tests/datasets/sql/libraries.sql to the translation process? |
| 10:16 |
bshum |
dbwells: I noticed that too for other things I was testing |
| 10:16 |
bshum |
dbwells: And yeah, adding the sample dataset as a translation option sounds like a good idea |
| 10:17 |
bshum |
But building that out will require a little more thought I think |
| 10:17 |
bshum |
Probably similar to how we do db.seed-data-values.sql now I guess. |
| 10:18 |
gmcharlt |
maybe? sample data (as opposed to test case data) strikes me as something where we don't necessarily want _mechanical_ localization |
| 10:18 |
gmcharlt |
or, rather, where such a thing would be less ideal than getting somebody from the relevant locale to put together realistic data |
| 10:19 |
gmcharlt |
anyway, here's an easy-peasy webstaff pullrequest for someobdy to test and merge: bug 1685232 |
| 10:19 |
pinesol_green |
Launchpad bug 1685232 in Evergreen "webstaff: pcrud.apply() does not work" [Medium,New] https://launchpad.net/bugs/1685232 |
| 10:19 |
gmcharlt |
also pointing out that pcrud.apply(), when it works, can be quite handy |
| 10:21 |
berick |
gmcharlt: hm, i thought I fixed that already. |
| 10:21 |
* berick |
scratches head |
| 10:21 |
gmcharlt |
berick: heh. I think miker or I also fixed that already in a much larger feature branch |
| 10:21 |
gmcharlt |
which is why I decided to make a micro bug so that WE CAN ALL STOP FIXING THE SAME BUG!!! ;) |
| 10:21 |
berick |
i bet it's lingering in one of my pullrequests |
| 10:21 |
berick |
exactly |
| 10:22 |
miker |
berick: yeah, I seem to remember you doing that, but launchpad search is so terrible... |
| 10:23 |
gmcharlt |
berick: also, I'm thinking of writing a fancier version of apply() that would do things like deflesh has_a linked objects and dive into hash_many arrays |
| 10:23 |
berick |
miker: yeah, and this is going to (*ahem*) bug me. i must find it! |
| 10:23 |
berick |
in the meantime, I'll look at the bug |
| 10:24 |
berick |
gmcharlt: cool |
| 10:24 |
gmcharlt |
that way, one could use a fully flesh results of a pcrud search, possibly passed to and from a "typedHash" (and I need a better name for that), set isnew() etc., and have it jsut do the Right Thing |
| 10:27 |
|
rlefaive joined #evergreen |
| 10:34 |
|
rlefaive joined #evergreen |
| 10:39 |
Dyrcona |
rhamby++ # I was going to point out the low traffic on the catalogers' list and about the development discussion. |
| 10:39 |
* Dyrcona |
sometimes thinks the catalogers' list is redundant. :) |
| 10:39 |
rhamby |
Dyrcona: yeah, I actually had to check to see if I was still subscribed since I didn't remember any regular traffic |
| 10:40 |
Dyrcona |
I should probably subscribe to the documentation list. |
| 10:41 |
|
rlefaive joined #evergreen |
| 10:42 |
pinesol_green |
[evergreen|Galen Charlton] LP#1685232: fix egCore.pcrud.apply() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8817b75> |
| 10:46 |
csharp |
ALL THE DEVS FIX ALL THE BUGS! |
| 10:47 |
Dyrcona |
heh. |
| 10:47 |
Dyrcona |
I was thinking: SQUASH ALL THE SILOS! |
| 10:47 |
Dyrcona |
berick++ That was fast. |
| 10:48 |
berick |
if we had one mail list for then entire EG community, it would still be a slow list |
| 10:48 |
Dyrcona |
It would. |
| 10:48 |
berick |
my point being, of course, that more lists seems odd to me |
| 10:48 |
* csharp |
, scarred from the "admin" email list discussions of c. 2011-12, hides in a bunker until all email list discussions are done |
| 10:49 |
bshum |
We, few, we happy few... |
| 10:49 |
dbs |
my stance concerning new mailing lists as expressed during the "admin" days stands |
| 10:49 |
Dyrcona |
Well, the circulation list discussion got me to question why does the catalogers' list exist. |
| 10:50 |
dbs |
evil idea: make the url for the new list be an alias for an existing list |
| 10:51 |
* berick |
chuckles |
| 10:51 |
dbs |
mozilla is moving all of their mailing lists to Discourse; it seems like a decent platform tbh |
| 10:51 |
|
Christineb joined #evergreen |
| 10:52 |
Dyrcona |
The sysadmin list is still mentioned here: https://evergreen-ils.org/communicate/mailing-lists/ |
| 10:52 |
bshum |
Maybe we should change the name when we migrate general to the lists server (general is still hosted on GPLS lists, right?) and we just called it "evergreen" and make it one list for everything then :D |
| 10:52 |
dbs |
Dyrcona: probably so the archives can be found? |
| 10:52 |
bshum |
Well, okay maybe not evergreen. |
| 10:52 |
bshum |
But uh, "discussion" haha |
| 10:53 |
Dyrcona |
dbs: Sounds legit. :) |
| 10:53 |
Dyrcona |
I should read the fine print. :) |
| 10:54 |
csharp |
we should just move to Slack! |
| 10:54 |
* csharp |
ducks |
| 10:55 |
dbs |
gitter, heh |
| 10:55 |
Dyrcona |
IRC for all discussion. :) |
| 10:55 |
Dyrcona |
heh. Since we're already installing ejabberd.... :) |
| 10:55 |
* csharp |
weeps for the glory days of #code4lib's IRC channel |
| 10:56 |
* berick |
too |
| 10:56 |
* dbs |
too |
| 11:04 |
miker |
Dyrcona: re bug 1684984, it looks like ingest.disable_metabib_field_entry was made obsolete with the flags for skipping specific uses of metabib.field_entry stuff; facet, browse, search. It was likely the early version of ingest.skip_search_indexing |
| 11:04 |
pinesol_green |
Launchpad bug 1684984 in Evergreen "Internal Flag ingest.disable_metabib_field_entry not used" [Undecided,New] https://launchpad.net/bugs/1684984 |
| 11:05 |
Dyrcona |
miker: That was my thought immediately after filing the bug. So, should the flag be removed from the table? |
| 11:06 |
miker |
+1 I think. I'd say "set the three if you want that". one flag could be slightly cheaper, but it's just asking for confusion |
| 11:06 |
Dyrcona |
I'll update the bug and prepare a branch. |
| 11:12 |
* csharp |
decides to leave Ubuntu desktop in the dust, moves back to Fedora, prolly for good :-/ |
| 11:12 |
Dyrcona |
hmm... |
| 11:12 |
berick |
csharp: do tell |
| 11:12 |
* Dyrcona |
is considering switching to something else, also. Since 16.04, Ubuntu has been in decline. |
| 11:12 |
Dyrcona |
@blame systemd |
| 11:12 |
pinesol_green |
Dyrcona: systemd stole Dyrcona's ice cream! |
| 11:12 |
Dyrcona |
:) |
| 11:13 |
csharp |
berick: oh, I'm... what Dyrcona said - they're dropping Unity, etc. and more or less throwing in the towel |
| 11:13 |
Dyrcona |
But, my hmm was about targeting bugs on launchpad. |
| 11:13 |
berick |
i've been quite happy w/ xubuntu |
| 11:13 |
Dyrcona |
Unity 8 stinks-- UI by Crayola. |
| 11:14 |
Dyrcona |
Unity not *8 is OK. |
| 11:14 |
berick |
xfce++ # what gnome users really want |
| 11:14 |
Dyrcona |
BlackBox, baby! |
| 11:14 |
Dyrcona |
:) |
| 11:14 |
Dyrcona |
@karma stinks |
| 11:14 |
pinesol_green |
Dyrcona: Karma for "stinks" has been increased 0 times and decreased 1 time for a total karma of -1. |
| 11:14 |
berick |
yeah, blackbox / fluxbox is great |
| 11:15 |
csharp |
I'm on Ubuntu GNOME 17.04 and it's fine, but if I'm living in GNOME, Fedora is better |
| 11:15 |
csharp |
but I'm open to other DEs too |
| 11:15 |
Dyrcona |
BlackBox is not a DE, it's a WM. |
| 11:15 |
* csharp |
always had a hard time remembering the difference :-) |
| 11:15 |
Dyrcona |
Just to clarify things. |
| 11:16 |
* miker |
considers going back to E |
| 11:16 |
gmcharlt |
regarding the lists discussions... while I share the general lack of optimism that a new one would get used, I also think that it's the sort of thing that is better to either let die after disuse (or succeed!) rather than have a bunch of devs squash each time |
| 11:16 |
Dyrcona |
I never used E much, but tried it for a bit. |
| 11:17 |
berick |
gmcharlt: agreed. |
| 11:18 |
* Dyrcona |
sort of agrees. But disagrees strongly if acq. ui discussion is going to happen in a silo. |
| 11:18 |
Dyrcona |
It should happen in a different silo. :) |
| 11:18 |
berick |
heh |
| 11:19 |
mmorgan |
gmcharlt++ |
| 11:19 |
berick |
if it's discussion that otherwise would not have happened, then by all means, add a list. |
| 11:19 |
* mmorgan |
feels like there must be a lot of questions out there that aren't getting asked. |
| 11:20 |
Dyrcona |
Why? Because there is not a specific list for them? |
| 11:20 |
Dyrcona |
Now, I like the idea of one list for everything even more. :) |
| 11:20 |
jeff |
Dyrcona: can you explain the "disagrees strongly if acq. ui discussion is going to happen in a silo. / It should happen in a different silo." comment above -- or just let me know if I missed the joke? :-) |
| 11:21 |
Dyrcona |
jeff: I think the discussion of acq. ui development should happen on the development list and not an acq. list. |
| 11:21 |
jeff |
aha |
| 11:22 |
mmorgan |
Dyrcona: Because folks that have questions about using the system on a daily basis might not feel comfortable joining and posting to a list where questions like "I'm installing evergreen and..." come up |
| 11:23 |
Dyrcona |
Well, the general list is for any question. |
| 11:24 |
Dyrcona |
I thought the idea was that installation questions should go to the development list, but we can't control what lists people send to. |
| 11:24 |
berick |
do we just need a staff list? |
| 11:26 |
jeff |
i don't think so. |
| 11:26 |
dbs |
csharp++ # welcome back to Fedora |
| 11:26 |
csharp |
seems like the factors involved on the "pro new list" side are 1) not wanting to ask something in the "wrong" place 2) not wanting to "junk up" a general list with topic-specific discussions and 3) librarians naturally like neat categories for things |
| 11:26 |
jeff |
i think we can create an acq and a circ list and see where they go from there. |
| 11:27 |
dbs |
kind of what we did with sysadmin |
| 11:27 |
jeff |
and maybe it'll turn out the same way that sysadmin did, and maybe not. |
| 11:27 |
* Dyrcona |
has seen this movie before, and I was on the other side of the discussion the last time. |
| 11:28 |
dbs |
as I was walking back from the meeting I was in, I was reflecting that people communicating primarily via IRC are not necessarily in the same circle in the Venn diagram of communications as those who prefer mailing lists |
| 11:28 |
csharp |
dbs: thanks - I've been running F25 on my laptop since the fall with no problems - using Fedora with nvidia drivers is frustrating (rpmfusion lag, can't use Wayland), so my desktop stations have been happier on Ubuntu |
| 11:28 |
mmorgan |
Seems like a good time to try what jeff suggests since two interest groups at the conference both saw a need. |
| 11:29 |
dbs |
csharp: ah, I've only used nouveau |
| 11:30 |
csharp |
I do just enough gaming that nouveau doesn't do the job for me :-) |
| 11:41 |
Bmagic |
Anyone heard of using a selfcheck machine where certain items are checked out and then immediately checked back in on the server (tracking in-house purposes) ? |
| 11:44 |
|
jvwoolf left #evergreen |
| 11:58 |
|
khuckins joined #evergreen |
| 12:08 |
miker |
Bmagic: never ... and, of course, we have a separate in-house-use function, so the numbers would be wonky (compared to the designed workflow) |
| 12:09 |
Bmagic |
miker: yeah, I thought it was a strange concept. Apparently the SIRSI system did this for the library |
| 12:10 |
Bmagic |
Any solutions for SIP and In-House use? |
| 12:10 |
dbs |
more like a self-in-house system - I could see that as being a potentially useful thing, kind of like my hacked-together simple web UI for moving items to a different location or deletion |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:13 |
berick |
Bmagic: this is for patrons? |
| 12:14 |
Bmagic |
yep |
| 12:16 |
Bmagic |
Things like paperbacks and magazines and even seed packets where the library doesn't care that they bring them back. So a traditional circulation will end up getting marked lost at some point |
| 12:16 |
Bmagic |
They do however, need to know that they were checked out, for inventory reasons |
| 12:18 |
bshum |
Are these items actually inventoried? meaning attached barcodes on records, etc. |
| 12:19 |
Dyrcona |
Wonder if you can set a loan duration to infinity? |
| 12:19 |
bshum |
Cause hey, if you had the workstation registered for the selfcheck, you could trace all circs applied there or the selfcheck user account too, and then setup a script to periodically check back in the copies (using some flags to disable things like transit, hold triggering, etc.) ? |
| 12:20 |
bshum |
Dyrcona: 999 years, obviously? :D |
| 12:21 |
Bmagic |
bshum: yes, they are cataloged with barcodes |
| 12:22 |
Bmagic |
I would like to avoid more one-off software for this one library |
| 12:22 |
Bmagic |
I offered them a solution that would deny the checkout, forcing the patron to come to the desk, so that the staff can perform an in-house checkout |
| 12:23 |
Bmagic |
it hurts a little bit, because they were used to it working just fine |
| 12:23 |
Bmagic |
It was called a "ephemeral" checkout |
| 12:24 |
Dyrcona |
bshum: Interval can apparently go to 178000000 years |
| 12:24 |
Dyrcona |
I was hoping for an actual inifinity, though. |
| 12:25 |
Dyrcona |
Though infinity is a special value for date/time fileds. |
| 12:26 |
Dyrcona |
I suppose with some modification infinite check outs could be supported. |
| 12:26 |
jeff |
Bmagic: non-cat circ via sip2 was something we considered doing work to support. it looked reasonable. |
| 12:27 |
Dyrcona |
Anyway, I should grab something to eat. |
| 12:27 |
Bmagic |
jeff: yeah, I think that is the real answer |
| 12:27 |
Bmagic |
however, does SIP have this type of thing in the spec? |
| 12:27 |
Dyrcona |
jeff: I ran into some issues with that and NCIPServer, though I'm fuzzy on the details. |
| 12:27 |
jeff |
Bmagic: our use case was paperbacks, and we were going to either rfid tag them with all the same thing, or with a given prefix and a meaningless serial number. |
| 12:27 |
jeff |
Dyrcona: non-cat or pre-cat? |
| 12:28 |
jeff |
Bmagic: not officially spelled out that i've seen, but at least one vendor has "support generic all-the-same item ids" for just this kind of thing. |
| 12:28 |
Dyrcona |
pre-cat prolly. Whatever the option name that I'm too lazy to look up right now says. :) |
| 12:29 |
Bmagic |
best case, we have a special in-house category and the self check would know based on the barcode which category to assign the in-house checkout |
| 12:29 |
jeff |
Dyrcona: pre-cats are "this item has a barcode and maybe a dummy title/author/isbn/circ_mod"... non-cats are "this is a PAPERBACK, or a MAGAZINE, it has no barcode, we don't care if it comes back, there are no overdues, etc" |
| 12:29 |
mmorgan |
Bmagic: noncat circ seems like it would save them some work, if they don't need to know the details on the items, just counts. |
| 12:29 |
mmorgan |
They wouldn't need to catalog them. |
| 12:29 |
Dyrcona |
Long term, I think an infinite checkout duration that can be controlled by the matchpoints is the way to go. |
| 12:30 |
jeff |
and in-house use is something else entirely -- and doesn't seem to fit what you're describing. |
| 12:30 |
jeff |
Dyrcona: i agree with you there. :-) |
| 12:30 |
Dyrcona |
jeff: yeah, pre-cats. There was a branch to make it easier/better, but it still didn't do what I expected and with a deadline looming, I gave up on making it work. |
| 12:30 |
Dyrcona |
I was going to use them for incoming items as an option. |
| 12:31 |
* Dyrcona |
goes to get something to eat for real this time. |
| 12:31 |
Bmagic |
I probably need more information from the library to decide. |
| 12:32 |
jeff |
adding support to sipserver for generic item ids or item id prefixes that translate to the same thing that you get in the staff client when checking out a non-cat item is something i would probably be interested in helping with. |
| 12:32 |
mmorgan |
So, infinite-term checkout, the items would always show checked out to the patron? That may not be what they're looking for. |
| 12:32 |
jeff |
mmorgan: i don't think anyone has voiced a need for that. |
| 12:32 |
jeff |
mmorgan: i think Dyrcona was pondering it as a means of accomplishing something, but then dismissed it. :-) |
| 12:33 |
mmorgan |
Ok, gotcha |
| 12:33 |
jeff |
especially in what Bmagic has said, i don't think he wants/needs that based on "the library doesn't care that they bring them back" |
| 12:34 |
mmorgan |
Right. Sounds like a non-cataloged checkout |
| 12:34 |
Bmagic |
yeah, I am leaning toward non-cat now after this discussion |
| 12:36 |
jeff |
Bmagic: it would be good if you could determine from the library how their selfchecks supported this -- are the items in question barcoded or rfid tagged? was there an on-screen "i am taking 3 paperbacks" option? are the item ids if present all identical for a given type, or have a serial number of some kind? |
| 12:37 |
Bmagic |
jeff: the impression I got, was the machine didn't know the difference. The server however, knew that this type of item needed to be checked back in immediately. |
| 12:37 |
jeff |
ideally the sip clients send a checkout message, and the item identifier in the checkout message contains something that you can use to determine the "type" of item. beyond that, it doesn't much matter. |
| 12:38 |
Dyrcona |
Yeah, inifinite checkout has issues. (My lunch is heating up.) |
| 12:39 |
Dyrcona |
Basically, you want to give something to a patron but have it counted as a checkout for stats and other purposes, but not count as an item out for the patron? |
| 12:39 |
Dyrcona |
I'm leaving selfchecks out of it for now. |
| 12:39 |
jeff |
right, that's what non-cat does. |
| 12:40 |
Dyrcona |
It does? I thought they still had due dates... I guess I'd better review that again. |
| 12:40 |
jeff |
they aren't circs, though. you report on them separately, or you join them together in a report via one of a handful of other ways. |
| 12:41 |
Dyrcona |
Oh, right. |
| 12:41 |
Dyrcona |
I'm always confusing that with pre-cat. :) |
| 12:41 |
jeff |
also, non-cats can have in-house uses as well as "circs" (that aren't circs) |
| 12:41 |
jeff |
action.non_cataloged_circulation vs action.non_cat_in_house_use |
| 12:42 |
|
rlefaive joined #evergreen |
| 12:43 |
jeff |
entries in config.non_cataloged_type do have a boolean for in_house and also have a circ_duration interval |
| 12:47 |
Bmagic |
what does the hold targeter do when it encounters an item with age protection and the settings are setup to compare to active_date but the active date is null? |
| 12:48 |
berick |
Bmagic: looks like it defaults to NOW() |
| 12:48 |
jeff |
non-cataloged circulations do not appear to patrons in tpac, and they don't appear by default in the staff client unless you specifically select non-cataloged circulations in the items out views in staff clients. |
| 12:48 |
|
rlefaive joined #evergreen |
| 12:48 |
Bmagic |
berick: oh sweet |
| 12:49 |
jeff |
and webby at least seems to have an issue either with checking out a non-cat item or showing it. |
| 12:49 |
jeff |
disregarding that for a moment, the non-cat "circs" go away completely in the staff client once they're past their "due date" |
| 12:50 |
jeff |
and i think that's circ_time + interval, meaning if you change the interval it'll affect the display of existing non-cat "circs" |
| 12:51 |
jeff |
(i don't consider that a big issue -- but i can imagine that it might surprise someone, so it should probably at least be documented if not changed) |
| 12:51 |
jeff |
(and i'm not advocating changing it) |
| 12:51 |
Dyrcona |
So an interval of 0 minutes makes them disappear. |
| 12:51 |
Dyrcona |
Or a similarly short interval, like 1 minute. |
| 13:00 |
|
khuckins_ joined #evergreen |
| 13:27 |
|
khuckins__ joined #evergreen |
| 13:35 |
|
rlefaive joined #evergreen |
| 14:45 |
gmcharlt |
https://evergreen-ils.org/evergreen-3-0-development-update-2/ |
| 14:47 |
bshum |
gmcharlt++ |
| 14:54 |
berick |
gmcharlt++ |
| 15:00 |
mmorgan |
gmcharlt++ |
| 15:02 |
remingtron |
bird_jigsaw_puzzles++ |
| 15:04 |
abneiman |
gmcharlt++ # privacy, offline, AND duck trivia! |
| 15:11 |
gmcharlt |
my_friend_arlene++ # every birder in my life is now at risking of being asked for all their pictures of ducks |
| 15:18 |
jeff |
heh. that moment when you return to your irc window only to think, "wait! where did the last hour or two of scrollback go," before realizing that said scroll was all privmsg. |
| 15:19 |
|
jvwoolf joined #evergreen |
| 15:21 |
jeff |
er, that sounded more mysterious than intended. |
| 15:39 |
|
Jillianne joined #evergreen |
| 15:54 |
|
khuckins_ joined #evergreen |
| 16:29 |
|
khuckins__ joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:19 |
|
jvwoolf left #evergreen |
| 21:02 |
|
khuckins__ joined #evergreen |
