| Time |
Nick |
Message |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 08:17 |
|
kmlussier joined #evergreen |
| 08:23 |
|
rlefaive joined #evergreen |
| 08:32 |
|
krvmga joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:43 |
|
collum joined #evergreen |
| 08:44 |
|
collum joined #evergreen |
| 08:48 |
|
bos20k joined #evergreen |
| 08:57 |
remingtron |
kmlussier: I'm looking at the 2.12_needs wiki page. Do you think the Biblio Fingerprint improvements would fit into the metabib docs you touched recently? |
| 08:59 |
kmlussier |
remingtron: I didn't touch upon those improvements in the docs. I'm not sure that it would be worth adding the specific changes to the docs. |
| 08:59 |
remingtron |
sure, that sounds fine |
| 08:59 |
kmlussier |
It might be worthwhile to provide some documentation on how the fingerprints are generated. Which fields are used for matching records. I don't think we have that yet. |
| 09:00 |
kmlussier |
But that's not a 2.12 need; it's a general doc need. |
| 09:00 |
remingtron |
right, and it's highly technical |
| 09:00 |
kmlussier |
Yeah, I was just wondering where that information would fit best. |
| 09:00 |
|
jvwoolf joined #evergreen |
| 09:01 |
remingtron |
maybe an appendix of some kind |
| 09:02 |
kmlussier |
Actually, I could see adding something in the public catalog docs that just mention which fields are used in the fingerprint. I get that question every once and a while from catalogers. |
| 09:03 |
* kmlussier |
wanders off to look at the docs to make sure she didn't break anything last night. :) |
| 09:03 |
remingtron |
well, real life questions prove some amount of need! |
| 09:07 |
|
rlefaive joined #evergreen |
| 09:13 |
|
Dyrcona joined #evergreen |
| 09:18 |
|
maryj joined #evergreen |
| 09:24 |
|
yboston joined #evergreen |
| 09:52 |
|
mmorgan1 joined #evergreen |
| 09:54 |
|
maryj_ joined #evergreen |
| 09:57 |
|
maryj joined #evergreen |
| 09:57 |
|
maryj_ joined #evergreen |
| 10:12 |
kmlussier |
https://evergreen-ils.org/communicate/committees/ should probably be updated. Before I put Tim's name there, does anyone know if oversight evergreen-ils.org is now going to tspindler? |
| 10:18 |
bshum |
kmlussier: I can change it to that. |
| 10:18 |
bshum |
Once I find Tim's email |
| 10:18 |
kmlussier |
I can give you his email. Hold on... |
| 10:18 |
bshum |
I got it |
| 10:18 |
kmlussier |
bshum++ |
| 10:19 |
bshum |
kmlussier: Okay, all switched |
| 10:19 |
bshum |
Or should be |
| 10:19 |
bshum |
I'll send a test email to verify :) |
| 10:19 |
bshum |
Looks good |
| 10:21 |
kmlussier |
OK, page updated. Looks like the only other update needed now is for conference committees. I'll contact a couple of people to see if I can get those names. |
| 10:22 |
bshum |
kmlussier++ # tidying the website |
| 10:27 |
|
Christineb joined #evergreen |
| 10:34 |
* csharp_ |
notices that documentationevergreen-ils.org is just going to yboston - should someone else be added? |
| 10:35 |
yboston |
csharp_: I thought it went to phasefx too? |
| 10:35 |
bshum |
remingtron: See csharp's question above about the documentation email alias |
| 10:36 |
|
csharp joined #evergreen |
| 10:36 |
yboston |
csharp: he replied to an email recently before I got to it |
| 10:36 |
csharp |
hmm |
| 10:37 |
csharp |
oh - there's docsevergreen-ils.org too which has phasefx |
| 10:37 |
yboston |
csharp: also I am ad admin to the DIG mailing list. I still discard spam messages, and allow non memebrs to post emails (when contributing docs,etc.) |
| 10:37 |
csharp |
yboston: ok - good to know |
| 10:37 |
* csharp |
isn't concerned about it - just noticed :-) |
| 10:41 |
bshum |
Maybe "documentation" should just alias to "docs" |
| 10:42 |
kmlussier |
csharp: The problem is that we don't have a new DIG facilitator who we can tack on to that email address. |
| 10:42 |
kmlussier |
yboston: Is there a lot of email that comes through that address? |
| 10:43 |
yboston |
to be honest, never realized there were two, so I am not sure how much volume one or the other has |
| 10:44 |
yboston |
I suspect one is listed for getting wiki access, and that is the one that phasefx also replies too |
| 10:45 |
bshum |
I think the docs one is on the wiki for wiki access |
| 10:45 |
bshum |
I've been searching for where "documentation" is used |
| 10:45 |
bshum |
So far, nada |
| 10:46 |
bshum |
Ahaa |
| 10:46 |
bshum |
Back to good ol' https://evergreen-ils.org/communicate/committees/ |
| 10:46 |
bshum |
It's on the DIG committee page |
| 10:46 |
remingtron |
bshum: I may have recently changed some wiki references from "documentation@" to "docs@" not knowing the difference |
| 10:46 |
bshum |
So it's intended for use by the facilitator |
| 10:46 |
bshum |
Or was in the past |
| 10:47 |
bshum |
I think that's fine, honestly. The key thing is making sure someone is available at the other end of the line. |
| 10:48 |
bshum |
But that's up to you guys |
| 10:48 |
gmcharlt |
reminder to add items to the agenda for today's dev meeting: https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-05-03 |
| 10:50 |
|
abowling joined #evergreen |
| 10:56 |
|
rlefaive joined #evergreen |
| 11:01 |
|
rlefaive joined #evergreen |
| 11:12 |
|
maryj joined #evergreen |
| 11:15 |
dbs |
gmcharlt: heh, I just updated the meeting time in the wiki doc from March 1 @ 1 to today @ 3 |
| 11:15 |
dbs |
humans++ |
| 11:16 |
gmcharlt |
note to self: add or find a timezone convert plugin for pinesol_green ;) |
| 11:17 |
abowling |
rjackson_isl++ for helping in my forgetfulness |
| 11:24 |
abowling |
setup a new consortium instance. been so long, can anyone remind me how to make the home library option show the org units i've added instead of "CONS"? |
| 11:25 |
Dyrcona |
abowling: Did your run autogen.sh? |
| 11:26 |
abowling |
dyrcona: indeed...and restarted every service just to be sure |
| 11:26 |
rjackson_isl |
for new library this AM it required a restart of services as well to pick up the autogen results - 11 app servers and half way thru a reload was 50/50 on actaully showing the new branches |
| 11:27 |
Dyrcona |
The xul staff client downloads that when you first connect. You'll also want to quit the staff client and start it again. |
| 11:27 |
Dyrcona |
If you haven't already done that. |
| 11:30 |
abowling |
Dyrcona: this is in webby. Staff client seems to handle it fine. |
| 11:31 |
Dyrcona |
Dunno. Try clearing the browser cache and local storage. |
| 11:33 |
abowling |
Dyrcona: yeah, i think... |
| 11:33 |
dbs |
Hatch? |
| 11:33 |
Dyrcona |
I haven't used webby that much, and not added new locations. |
| 11:37 |
dbs |
maybe nginx/haproxy/etc caching? So many wonderful possibilities :) |
| 11:40 |
berick |
ohh.. webby has its own org cache, which we probably need to kill or make smarter |
| 11:41 |
berick |
in sessionStorage -- which clears with each tab, though |
| 11:42 |
berick |
abowling: if you open a new browser tab w/ webby does it still not see the orgs? |
| 11:46 |
|
khuckins joined #evergreen |
| 11:47 |
kmlussier |
Or maybe try it in a different browser. I usually do that just to really, really make sure it's not a cache issue. |
| 11:48 |
abowling |
berick: opening in firefox (rather than the chrome i was using) seems to confirm the consensus viewpoint. it's a cache issue, as they now appear as they should. |
| 11:49 |
abowling |
kmlussier: 100% agree. that's my go-to ^ :) |
| 11:49 |
abowling |
dbs: indeed |
| 11:49 |
berick |
abowling: that's good to know, but the new-tab question would also be good to know.. |
| 11:49 |
berick |
so we can narrow down where the caching issue lies |
| 11:50 |
abowling |
berick: new tab works correctly! |
| 11:50 |
berick |
abowling: awesome, thanks for confirming |
| 11:52 |
abowling |
berick: sure thing! and here's one that'll drive you nuts. new tab SEEMS to break the old tab |
| 11:52 |
abowling |
berick: or maybe you knew that already |
| 11:53 |
berick |
nope, that's a new one :) |
| 11:54 |
berick |
but i'm not surprised old tab is funky, since its data is out of sync w/ the DB |
| 11:57 |
abowling |
berick: agreed. that's more of an education of THIS user than anything else ;) |
| 11:58 |
* abowling |
is a webby n00b, but is looking to change that...quickly |
| 11:59 |
|
sandbergja joined #evergreen |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:29 |
|
mmorgan joined #evergreen |
| 12:55 |
|
rlefaive joined #evergreen |
| 13:02 |
kmlussier |
@dessert |
| 13:02 |
* pinesol_green |
grabs some Coconut Cream Cake for kmlussier |
| 13:36 |
|
_adb joined #evergreen |
| 14:18 |
|
Jillianne joined #evergreen |
| 14:18 |
|
rlefaive joined #evergreen |
| 14:34 |
* jeff |
looks to see what we did the last time we phased out an opensrf service |
| 14:38 |
|
rjackson_isl_ joined #evergreen |
| 14:38 |
|
Callender_ joined #evergreen |
| 14:39 |
jeffdavis |
Bmagic: with your test case for bug 1686194, an item with $0.20/day fine and, say, $100.00 max fines gets marked lost after 3 days, returned after 6, and overdues are "reinstated" at the max fines value of $100 (instead of 6 days X $0.20/day) - is that what you're seeing? |
| 14:39 |
pinesol_green |
Launchpad bug 1686194 in Evergreen 2.12 "Fine generation does not factor adjustments into max fines calculation" [Undecided,Confirmed] https://launchpad.net/bugs/1686194 |
| 14:41 |
|
kmlussier joined #evergreen |
| 14:42 |
Bmagic |
jeffdavis: yes, accept it's $10 max |
| 14:43 |
Bmagic |
with the other part of the bug though, the account_adjustments make the balance_owed smaller which is another bug (fixed by dbwells patch) |
| 14:43 |
|
rlefaive joined #evergreen |
| 14:44 |
dbwells |
Bmagic: So it actually generates fines into the future? |
| 14:45 |
dbwells |
That's just so... unexpected. |
| 14:46 |
Bmagic |
It lumps it in one money.billing line with note: System: LOST RETURNED - OVERDUES REINSTATED |
| 14:46 |
Bmagic |
the fine generator isn't involved |
| 14:49 |
jeffdavis |
It does seem like a separate bug to me, but yikes! |
| 14:49 |
dbwells |
Not looking ATM, but it should be applying one fine for reinstatement, then firing off the generator if that option is on. |
| 14:49 |
Dyrcona |
Was anything backdated? |
| 14:49 |
Bmagic |
backdating is part of the equation |
| 14:50 |
Dyrcona |
Well, there you go! :) |
| 14:50 |
dbwells |
Dyrcona: :D |
| 14:51 |
Bmagic |
backdating executes other logic? And that is the logic that is flawed then? |
| 14:51 |
Dyrcona |
Things can get weird with backdating and fine generation. |
| 14:53 |
dbwells |
If the reinstated fine == max fines, then max_fines must have existed before the thing went lost, AFAIK. If we are trying to backdate into some middle of the reinstatement, I can imagine that not working out. |
| 14:53 |
dbwells |
It also wouldn't have anything to do with lost->found fine regeneration in that case. |
| 14:54 |
Dyrcona |
I'm also not finding a super-relevant open bug at the moment. |
| 14:54 |
kmlussier |
I wonder if the best solution when we try to mix too many billing 'things' (mixing backdates with reinstated fines, for instance) if the system should just pop up a box and say, how much do you want to charge? |
| 14:55 |
dbwells |
kmlussier++ |
| 14:55 |
Dyrcona |
heh. |
| 14:56 |
dbwells |
and the picture will be someone tearing their hair out |
| 14:56 |
kmlussier |
Of course, I'm not really serious, but complicated billing scenarios just make my head hurt. |
| 14:58 |
mmorgan |
Are there any uncomplicated billing scenarios? |
| 14:58 |
dbwells |
"Hello, and welcome to Moviefone...Why don't you just tell me the movie you want to see?" :) |
| 14:58 |
Dyrcona |
Stop charging fines. |
| 14:58 |
gmcharlt |
^^ This |
| 14:58 |
* gmcharlt |
is half-joking, half-serious |
| 14:58 |
jeffdavis |
"Because actual users get up to all kinds of unexpectedness, we only recreate up to $circ->max_fine in bills. I know you think it wouldn't happen that bills could get created, voided, and recreated more than once, but I guaran-damn-tee you that it will happen." |
| 14:58 |
gmcharlt |
dev meeting in a couple minutes |
| 14:58 |
mmorgan |
And lost books aren't allowed. |
| 14:59 |
jeffdavis |
^ Actual comment from the checkin_handle_lost_or_lo_now_found_restore_od function in Circulate.pm, which is probably the place that needs to be tweaked to fix Bmagic's issue. |
| 14:59 |
kmlussier |
mmorgan: If we got rid of the overdue fines, the lost book bills wouldn't be nearly as complicated. |
| 15:00 |
mmorgan |
True, I'm totally in favor of no fines :) |
| 15:01 |
|
DPearl joined #evergreen |
| 15:01 |
gmcharlt |
and now time to start the meeting |
| 15:01 |
gmcharlt |
#start_meeting Development meeting, 3 May 2017 |
| 15:01 |
dbs |
yay |
| 15:01 |
gmcharlt |
#startmeeting Development meeting, 3 May 2017 |
| 15:01 |
pinesol_green |
Meeting started Wed May 3 15:01:33 2017 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:01 |
pinesol_green |
The meeting name has been set to 'development_meeting__3_may_2017' |
| 15:01 |
gmcharlt |
#info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-05-03 |
| 15:01 |
gmcharlt |
#topic Introductions |
| 15:02 |
gmcharlt |
#info Galen Charlton, EOLI, 3.0 RM |
| 15:02 |
dbs |
@info Dan Scott, Laurentian University |
| 15:02 |
pinesol_green |
dbs: (info <url|feed>) -- Returns information from the given RSS feed, namely the title, URL, description, and last update date, if available. |
| 15:02 |
DPearl |
#info DPearl is Dan Pearl, C/W MARS Inc. |
| 15:02 |
dbs |
#info Dan Scott, Laurentian University |
| 15:02 |
abowling |
#info abowling = Adam Bowling, Emerald Data Networks |
| 15:02 |
rhamby |
#info Rogan Hamby, Equinox |
| 15:02 |
phasefx |
#info Jason Etheridge, EOLI |
| 15:02 |
dbs |
It's going to be one of those days, is it? |
| 15:02 |
kmlussier |
#info Kathy Lussier, MassLNC |
| 15:02 |
Dyrcona |
#info Jason Stephenson, C/W MARS |
| 15:02 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 15:02 |
kmlussier |
dbs: Would you like me to point you to our IRC beginner's guide? ;) |
| 15:02 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 15:02 |
berick |
#info berick Bill Erickson, KCLS |
| 15:02 |
csharp |
#info csharp is Chris Sharp, GPLS |
| 15:03 |
gmcharlt |
one moment as I update agenda with action items from conf |
| 15:03 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) |
| 15:04 |
gmcharlt |
so, done |
| 15:04 |
gmcharlt |
please refresh https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-05-03 |
| 15:04 |
gmcharlt |
#topic Action items from previous meeting |
| 15:05 |
gmcharlt |
so, first one is for me to send out a call to use open-ils-dev more |
| 15:06 |
gmcharlt |
I'll carry that over and do it this week + discuss it on my weekly dev update blog post |
| 15:06 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:06 |
gmcharlt |
so, |
| 15:06 |
gmcharlt |
#action Galen will send out a call for patch authors to use open-ils-dev to introduce new features. |
| 15:06 |
gmcharlt |
next action is "Galen starts bugging ALL THE FOLKS on #evergreen" |
| 15:06 |
dbs |
gmcharlt++ # weekly dev update posts |
| 15:06 |
gmcharlt |
which I am doing |
| 15:06 |
gmcharlt |
so y'all please consider yourselves bugged |
| 15:06 |
kmlussier |
gmcharlt++ indeed |
| 15:07 |
gmcharlt |
... wait, maybe that didn't come out quite right ;) |
| 15:07 |
Dyrcona |
The channel is logged, we're all bugged. :) |
| 15:07 |
abowling |
like trump tower? |
| 15:07 |
gmcharlt |
next action item, exploring potential LP repacements, has begun, and has an agenda item later on, so we'll just consider that one done and discuss in a bit |
| 15:07 |
gmcharlt |
next one - Ben Shum and Dan Scott will set up Launchpad and the bzr repo to start permitting series-level translations. |
| 15:08 |
gmcharlt |
bshum, dbs: ^^ updates? |
| 15:08 |
dbs |
bshum was doing some experimentation |
| 15:08 |
dbs |
but I have nothing concrete to share |
| 15:09 |
dbs |
I think the realization that some of the translations were way out of whack took priority |
| 15:09 |
gmcharlt |
IIRC from recent discussions, I think bshum is getting close enough that we can tentiavely plan to 2.12.2 including another POT sync |
| 15:09 |
gmcharlt |
but yeah, there've been multilingual spiders crawling out |
| 15:10 |
gmcharlt |
any other i18n comments at the moment? |
| 15:10 |
dbs |
nope |
| 15:10 |
abowling |
there was some interest at the conference during our session |
| 15:11 |
abowling |
specifically, cherokee had multiple persons in support...but nothing technical to add |
| 15:11 |
gmcharlt |
Cherokee the language, you mean? |
| 15:12 |
|
beanjammin joined #evergreen |
| 15:12 |
abowling |
yes, sorry. i realize that was vague. |
| 15:12 |
gmcharlt |
neat! |
| 15:12 |
bshum |
gmcharlt: Oh sorry I wasn't watching my screen |
| 15:12 |
gmcharlt |
welcome, bshum |
| 15:12 |
bshum |
Yes, we setup 2.12 bzr |
| 15:12 |
bshum |
So we're capable of doing translations for specific series now |
| 15:13 |
dbwells |
Bmagic and I did at least pull in a new PO from the bzr branch for 2.12.1 |
| 15:13 |
bshum |
I think Bmagic used those steps |
| 15:13 |
bshum |
yup |
| 15:13 |
Bmagic |
I did |
| 15:13 |
gmcharlt |
ah, cool, I had missed that |
| 15:13 |
dbwells |
We generated the newpot too, but not sure exactly how/when that gets picked up |
| 15:13 |
abowling |
i thought so too, especially because it didn't occur to me that indigenous American languages might be a hotbed |
| 15:13 |
bshum |
Yeah I want to tweak the timing a bit more too |
| 15:13 |
dbwells |
hoping it just flows in by tracking 2_12? |
| 15:13 |
bshum |
Right now it's doing git -> bzr at 10 pm Eastern for 2.12 |
| 15:14 |
bshum |
So it should flow through any changes |
| 15:14 |
dbwells |
cool, thanks for confirming |
| 15:14 |
bshum |
And vice versa when you pull back |
| 15:14 |
dbs |
bshum++ |
| 15:14 |
gmcharlt |
bshum++ |
| 15:14 |
gmcharlt |
OK, then I think we can consider that actino item done |
| 15:14 |
gmcharlt |
so, moving on |
| 15:15 |
gmcharlt |
#topic OpenSRF release info |
| 15:15 |
gmcharlt |
#info bug 1684970 warrants a release of 2.5.1 this month |
| 15:15 |
pinesol_green |
Launchpad bug 1684970 in OpenSRF "Proxy setup masks client IP needed by osrf-http-translator" [Medium,Confirmed] https://launchpad.net/bugs/1684970 |
| 15:16 |
gmcharlt |
any other particular questions, concerns, burning bugs, or works-in-progress for OpenSRF? |
| 15:17 |
gmcharlt |
going once |
| 15:18 |
gmcharlt |
going twice |
| 15:18 |
gmcharlt |
#topic Evergreen releases |
| 15:18 |
gmcharlt |
#info 2.12.1, 2.11.4, and 2.10.11 were released on 19 April |
| 15:18 |
gmcharlt |
#info 2.10.11 is the last bugfix release for 2.10.x, which is now security only |
| 15:19 |
dbs |
Speaking of which, there is a security bug with a patch that should probably be looked at for the next round of releases... |
| 15:19 |
gmcharlt |
indeed |
| 15:20 |
gmcharlt |
also, somebody highlighted bug 1646638 |
| 15:20 |
pinesol_green |
Launchpad bug 1646638 in Evergreen "SIP authentication sessions timeout in 2.11" [Undecided,Confirmed] https://launchpad.net/bugs/1646638 |
| 15:20 |
gmcharlt |
which at first blush looks like would be easy to include in the May releases |
| 15:20 |
* dbs |
was "somebody" |
| 15:20 |
gmcharlt |
dbs++ |
| 15:20 |
dbs |
I had forgotten about that bug until rsoulliere ran into it |
| 15:20 |
Bmagic |
dbs++ # SIP patch |
| 15:21 |
Bmagic |
We ran into it as well, it was killing us for about 3 weeks |
| 15:21 |
gmcharlt |
that bug also reminds me of a semi-related issue -- would it make sense to define a new auth type for SIP rather than using opac? |
| 15:21 |
Bmagic |
I don't see why not |
| 15:21 |
* dbs |
borrows from improv and suggests "and" |
| 15:21 |
Dyrcona |
Yes, I think it would. |
| 15:22 |
csharp |
I just remembered that PINES applied that commit in advance of our January upgrade - I forgot to circle back around and sign off on it - just did |
| 15:22 |
dbs |
opac + patch for short-term, new auth for next release |
| 15:22 |
dbs |
csharp++ |
| 15:22 |
kmlussier |
csharp++ |
| 15:22 |
dbs |
and Bmagic++ # opening the bug |
| 15:22 |
csharp |
dbs++ |
| 15:22 |
csharp |
all_yall++ |
| 15:22 |
dbs |
upgrades are such a blur |
| 15:23 |
gmcharlt |
OK, I'll also open an LP for a new auth type as well |
| 15:23 |
csharp |
dbs: srsly |
| 15:23 |
gmcharlt |
any other Evergreen release issues to discuss (noting that we have some more requests for feedback at the end of the agenda) |
| 15:23 |
gmcharlt |
? |
| 15:24 |
gmcharlt |
going once |
| 15:25 |
gmcharlt |
going twice |
| 15:25 |
gmcharlt |
#topic Statement of responsibilities of core committers |
| 15:25 |
gmcharlt |
#link https://wiki.evergreen-ils.org/doku.php?id=contributing:core_committer_responsibilities |
| 15:25 |
gmcharlt |
this was something that was drafted by kmlussier and me and initially discussed at the conference |
| 15:26 |
gmcharlt |
and at this point, I'd like to open it up any further discussion |
| 15:26 |
gmcharlt |
and unless blockers arise, hold a vote of this meeting on whether to formally adopt it |
| 15:28 |
gmcharlt |
any comments before I start the vote? |
| 15:28 |
dbs |
The only thing I stumbled over was the use of the word "integrity" to describe evergreen's architecture |
| 15:28 |
kmlussier |
No comments from me. I think it covers things well. |
| 15:29 |
* phasefx |
hides the hamster wheels |
| 15:29 |
gmcharlt |
dbs: in the sense that "integrity of architecture" is perhaps aspirational, or a substantive concern about aiming for it? |
| 15:29 |
dbs |
It just seems like the wrong word? |
| 15:30 |
dbs |
"To advocate for the integrity of Evergreen's architecture", I don't know what that means |
| 15:30 |
gmcharlt |
"consistency"? |
| 15:30 |
phasefx |
and/or quality? |
| 15:30 |
dbs |
s/integrity/technical soundness/ ? |
| 15:30 |
dbs |
I like "quality" better |
| 15:31 |
gmcharlt |
"quality" works for me |
| 15:31 |
dbs |
maybe it's just me |
| 15:31 |
phasefx |
s/architecture/codebase/? |
| 15:31 |
kmlussier |
I could get on board with 'quality' |
| 15:31 |
Dyrcona |
Perhaps the use of integrity in this case is an Americanism. |
| 15:32 |
dbs |
The senses of "integrity" that I'm familiar with are either completeness, or moral |
| 15:32 |
* dbwells |
looks in thesaurus, laughs at "nature of beast" |
| 15:32 |
Dyrcona |
Well, completeness is more what I think it means. |
| 15:32 |
* phasefx |
's reference is Star Trek, hull and shields |
| 15:32 |
gmcharlt |
dbs: yeah, the denotation I was going for was "The state of being unimpaired; soundness. |
| 15:32 |
gmcharlt |
" |
| 15:33 |
dbs |
And I *think* what is meant is that we should be continually trying to improve the quality of the architecture |
| 15:33 |
dbwells |
I like "quality" fine. Also like "soundness", actually. |
| 15:34 |
dbs |
Okay. Whatever helps us kick XUL and Dojo to the curb :) |
| 15:34 |
phasefx |
har |
| 15:34 |
kmlussier |
heh |
| 15:34 |
gmcharlt |
dbs: yes, as well as to resist making changes that reduce archtectural quality in the name of undue expedience |
| 15:34 |
jeffdavis |
integrity implies coherence/consistency as a goal to me |
| 15:35 |
jeffdavis |
dunno if that should be specifically articulated |
| 15:35 |
gmcharlt |
so, here's what I've come up with |
| 15:35 |
gmcharlt |
"The quality of Evergreen's architecture and its continual improvement" |
| 15:37 |
dbs |
+1 |
| 15:37 |
gmcharlt |
OK, I've saved the wiki edit |
| 15:37 |
gmcharlt |
any other wording tweaks before we vote? |
| 15:38 |
gmcharlt |
ok |
| 15:38 |
dbwells |
berick and I talked a bit at the conference about the last individual one |
| 15:39 |
dbwells |
I just wonder if we need to be that specific, or if "model good participation" really says enough. |
| 15:40 |
dbwells |
I have no problem with the concept, but just how it comes across to any casual reader of the document. |
| 15:40 |
Dyrcona |
The model good participation one is kind of vague. |
| 15:41 |
dbs |
Perhaps the example could be added to the "model good participation" clause and the more negative clause could be deleted? |
| 15:41 |
Dyrcona |
That might work. |
| 15:41 |
dbs |
dbwells: you mean casual reader thinks "oh this place sounds toxic, I'm out of here"? |
| 15:41 |
dbwells |
dbs: yes, exactly |
| 15:42 |
kmlussier |
I'm not sure the example exactly goes with the 'model good participation' bit. |
| 15:42 |
Dyrcona |
To me the whole list reads like a model of good participation. |
| 15:44 |
Dyrcona |
After reading it yet again, I think I'm in favor of dropping the last individual one, too. |
| 15:44 |
Dyrcona |
I'd prefer a list of "thou shalts" over "thou shalt nots" |
| 15:44 |
Bmagic |
we could have a meeting about it..... |
| 15:45 |
Dyrcona |
heh |
| 15:45 |
|
rlefaive joined #evergreen |
| 15:45 |
dbs |
My guess is that there have been specific incidents that as a community we would like to avoid repeating in the future |
| 15:46 |
Dyrcona |
Yes, but should policy be made around the exceptions or the general rule? |
| 15:46 |
dbs |
and that providing examples might help us recognize negative patterns of behaviour for ourselves that we otherwise would not |
| 15:47 |
kmlussier |
Yes, I was thinking the same as dbs. |
| 15:47 |
* dbs |
can benefit from this kind of reflection |
| 15:47 |
gmcharlt |
so yeah, one of the potential things here - and this might be better as an example - is the use of snark |
| 15:47 |
dbwells |
Well, how about simply "To encourage other committers who are taking on group responsibilities." ? |
| 15:48 |
gmcharlt |
to which I will cop -- but is also something that can discourage participation |
| 15:48 |
gmcharlt |
to tease apart what I was trying to do here |
| 15:48 |
dbwells |
Then leave the example as well. |
| 15:48 |
gmcharlt |
(a) commiters don't necessarily need to feel obligated to participate in ALL collective responsibilities |
| 15:49 |
dbwells |
We can all use more encouragement from time to time, and that isn't mentioned anywhere yet :) |
| 15:49 |
gmcharlt |
(b) they should not get in the way, however -- and there may be cases where somebody is really not inteested in a given technical aspect |
| 15:49 |
gmcharlt |
but should take care to direct folks to the ones who are interested |
| 15:50 |
gmcharlt |
and also pay attention to overall tone of communications |
| 15:50 |
gmcharlt |
and I do think that it's important to both acknolwedge patterns *and* antipatterns |
| 15:51 |
gmcharlt |
so, |
| 15:51 |
gmcharlt |
here's a suggested alternative |
| 15:51 |
Dyrcona |
I like dbwells suggested wording. |
| 15:52 |
gmcharlt |
"To assist in directing people to other committers who are working on a group responsibility, even when not personally engaged in it" |
| 15:53 |
gmcharlt |
I would propose dbwells' wording as an *additional* point |
| 15:54 |
jeffdavis |
+1 to that wording and to adding "model good participation" as an additional point |
| 15:54 |
kmlussier |
gmcharlt: That sounds good to me. |
| 15:55 |
dbwells |
gmcharlt: Thanks for explaining. New wording sounds great. I'd be happy to get an "encouragement" point added as well, but ok without, too. |
| 15:55 |
Dyrcona |
jeffdavis: Model good participation is already there, in case you missed it. |
| 15:55 |
gmcharlt |
OK, please refresh https://wiki.evergreen-ils.org/doku.php?id=contributing:core_committer_responsibilities |
| 15:56 |
jeffdavis |
Dyrcona: ha, so I did, thanks |
| 15:56 |
gmcharlt |
er, refresh again (added a missing "to") |
| 15:56 |
kmlussier |
:) |
| 15:57 |
gmcharlt |
so, ready for vote? |
| 15:57 |
dbwells |
sorry to need to delay the vote, thanks to all for listening! |
| 15:58 |
kmlussier |
I'm ready |
| 15:58 |
dbwells |
ready |
| 15:58 |
gmcharlt |
#startvote Shall the statement of committer responsibilities linked above be adopted? Yes, No, Abstain |
| 15:58 |
pinesol_green |
Begin voting on: Shall the statement of committer responsibilities linked above be adopted? Valid vote options are Yes, No, Abstain. |
| 15:58 |
pinesol_green |
Vote using '#vote OPTION'. Only your last vote counts. |
| 15:58 |
gmcharlt |
#vote Yes |
| 15:58 |
dbwells |
#vote Yes |
| 15:58 |
kmlussier |
#vote Yes |
| 15:58 |
abowling |
#vote Yes |
| 15:58 |
dbs |
#vote Yes |
| 15:58 |
Dyrcona |
#vote Yes |
| 15:58 |
DPearl |
#vote Yes |
| 15:59 |
jeff |
#vote Yes |
| 15:59 |
rhamby |
#vote Yes |
| 15:59 |
phasefx |
#vote yes |
| 15:59 |
remingtron |
#vote yes |
| 15:59 |
berick |
#vote yes |
| 16:00 |
gmcharlt |
#endvote |
| 16:00 |
pinesol_green |
Voted on "Shall the statement of committer responsibilities linked above be adopted?" Results are |
| 16:00 |
pinesol_green |
Yes (12): kmlussier, DPearl, jeff, berick, abowling, phasefx, dbwells, Dyrcona, gmcharlt, remingtron, dbs, rhamby |
| 16:01 |
gmcharlt |
#agreed https://wiki.evergreen-ils.org/doku.php?id=contributing:core_committer_responsibilities is adopted as a statement of committer responsbilities |
| 16:01 |
gmcharlt |
so, we're now jsut past an hour, with stuff left on the agenda |
| 16:01 |
gmcharlt |
I'm inclined to start a thread regarding LP replacement on open-ils-dev |
| 16:01 |
gmcharlt |
but we also have three highlighted bugs |
| 16:01 |
dbwells |
+1 to LP replacement thread |
| 16:01 |
kmlussier |
+1 to email thread |
| 16:02 |
Dyrcona |
Yeah, I'll move to skip that and discuss it on the list. |
| 16:02 |
gmcharlt |
thought so :) |
| 16:02 |
dbs |
I'm happy to just have some eyes on the bugs, doesn't need to be discussed here |
| 16:02 |
gmcharlt |
#action gmcharlt will start thread on moving forward with investigation of replacing LP |
| 16:02 |
Dyrcona |
I am looking at Gitlab, fwiw. |
| 16:03 |
dbwells |
dbs++ |
| 16:03 |
gmcharlt |
dbs: I've been keeping an eye on them, and thus far not seeing any conceptual blockers |
| 16:03 |
kmlussier |
dbs: Should bug 1687545 be addressed before bug 1411699 goes in? |
| 16:03 |
gmcharlt |
(other than sort out & vs ; in the one) |
| 16:03 |
pinesol_green |
Launchpad bug 1687545 in Evergreen "W3C wants query parameters standardized on ampersands; semicolons are now bad" [Undecided,New] https://launchpad.net/bugs/1687545 |
| 16:03 |
pinesol_green |
Launchpad bug 1411699 in Evergreen "TPAC: Don't load dojo widgets unless we actually need them (for autocomplete)" [Wishlist,Confirmed] https://launchpad.net/bugs/1411699 |
| 16:04 |
dbs |
kmlussier: 1411699 has two branches, one which could go in immediately |
| 16:04 |
dbs |
the other (rewrite to remove dojo) could follow on after 1687545 |
| 16:04 |
gmcharlt |
#info Patches for bug 1685840, bug 1681095, and bug 1411699 are commended to the dev community for general attention and testing |
| 16:04 |
dbs |
not to be confused with the rewrite to remove dojo for google books preview ;) |
| 16:04 |
pinesol_green |
Launchpad bug 1685840 in Evergreen "Google Books Preview should not require Dojo or any other framework" [Wishlist,Triaged] https://launchpad.net/bugs/1685840 |
| 16:04 |
kmlussier |
dbs: OK, thanks for clarifying. |
| 16:04 |
pinesol_green |
Launchpad bug 1681095 in Evergreen "Extend browser cache-busting support for all stylesheets, JavaScript, and images in default public catalogue" [Undecided,New] https://launchpad.net/bugs/1681095 |
| 16:05 |
pinesol_green |
Launchpad bug 1411699 in Evergreen "TPAC: Don't load dojo widgets unless we actually need them (for autocomplete)" [Wishlist,Confirmed] https://launchpad.net/bugs/1411699 |
| 16:05 |
gmcharlt |
ok, I think that's a wrap |
| 16:05 |
gmcharlt |
#endmeeting |
| 16:05 |
pinesol_green |
Meeting ended Wed May 3 16:05:12 2017 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:05 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-05-03-15.01.html |
| 16:05 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-05-03-15.01.txt |
| 16:05 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-05-03-15.01.log.html |
| 16:05 |
dbwells |
gmcharlt++ |
| 16:05 |
dbs |
gmcharlt++ |
| 16:05 |
kmlussier |
gmcharlt++ |
| 16:05 |
Dyrcona |
gmcharlt++ |
| 16:05 |
phasefx |
gmcharlt++ |
| 16:05 |
remingtron |
gmcharlt++ |
| 16:05 |
Dyrcona |
dbs: I have a question about google books preview: Do I need to do any special signup with Google in order to use/test it? |
| 16:06 |
jeffdavis |
I wanted to invite input on bug 1684988, but no discussion needed |
| 16:06 |
pinesol_green |
Launchpad bug 1684988 in Evergreen "Patron account can be retrieved without opt-in" [Undecided,New] https://launchpad.net/bugs/1684988 |
| 16:06 |
dbs |
Dyrcona: nope, it should just work |
| 16:07 |
dbs |
(assuming you turn it on in config.tt2) |
| 16:07 |
Dyrcona |
OK, then. I'll see if I can find some time to look at it. |
| 16:07 |
dbs |
my bar for replacing LP is "do links in emails send me to the Italian Linux Society?" |
| 16:08 |
dbs |
Dyrcona: bshum added an example record from the Concerto set that should result in a preview |
| 16:08 |
Dyrcona |
OK. |
| 16:10 |
Bmagic |
gmcharlt++ |
| 16:11 |
Dyrcona |
That reminds me that I'm still sitting on the Czech records that I was told could be added to Concerto. |
| 16:13 |
jeff |
jeffdavis: asking because you guys use opt-in currently -- what is the best description of how opt-in should work? |
| 16:14 |
jeff |
jeffdavis: i.e., "don't show patrons in searches until they have shown up at least once and been retrieved by barcode and 'opted in'" was the last summary I think I had, but is it just searches, or should patrons also not appear in other interfaces, etc? |
| 16:14 |
dbs |
we use it too. if a patron hasn't opted into sharing their account with another org_unit, they shouldn't be able to be retrieved via anything except barcode (so they can then opt in) |
| 16:14 |
kmlussier |
Dyrcona: And that reminds me that bug 1672434 still needs to be addressed. |
| 16:14 |
pinesol_green |
Launchpad bug 1672434 in Evergreen "Improved method for adding new bib records to test dataset" [Undecided,New] https://launchpad.net/bugs/1672434 |
| 16:15 |
jeff |
dbs: so, they shouldn't show up in a list of holds on a bib, for example? |
| 16:15 |
dbs |
in XUL there is leakage through other interfaces like item circ history, IIRC, but it would be preferred to not show up there |
| 16:16 |
jeff |
okay. is there a document (or commit message, wiki page, sitka/etc third party documentation) that describes how it currently works and how it should work? |
| 16:16 |
dbs |
jeff: yeah, I think the design and implementation focused on the primary interface but didn't manage to address the others |
| 16:18 |
jeffdavis |
We've got the XUL client patched so that non-opted-in patrons (first/last name, barcode, home OU) show up in an item's circ history, for example, but you can't actually retrieve the account without opting them in |
| 16:19 |
jeffdavis |
Not showing them in circ history etc at all might be desirable, but not necessarily in all cases. |
| 16:20 |
jeff |
jeffdavis: to help me understand, can you give an example where you might want a non-opted-in patron's details to show in circ history? |
| 16:20 |
dbs |
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2009-June/004649.html is the earliest I've found so far |
| 16:20 |
jeff |
dbs++ |
| 16:21 |
jeffdavis |
jeff: A majority of our libraries are part of a kind of super-federation called "BC Interlibrary Connect", but patrons from a BC ILC library still need to be opted in at other BC ILC libraries. |
| 16:22 |
dbs |
Slightly earlier but less information http://libmail.georgialibraries.org/pipermail/open-ils-general/2009-April/001436.html |
| 16:22 |
jeffdavis |
Resources can be shared between libraries but patrons don't have to let their info be shared with every single library in the super-federation. |
| 16:23 |
jeffdavis |
(Of course opt-in isn't actually a hard block on retrieving a patron account, but there is at least an attempt at having a record of consent to sharing info.) |
| 16:24 |
jeffdavis |
Conversely, there is a "disallow opt-in" org setting which can prevent an org unit's patrons from being opted in at all. In that case, we'd probably *not* want the patrons to show up in circ history etc. |
| 16:25 |
jeff |
i'm still not sure i follow why you'd want a patron to show in circ history at a library where they had not opted in... |
| 16:26 |
jeff |
but maybe i'm misunderstanding something more fundamental. |
| 16:27 |
Dyrcona |
Maybe if patron from library A has an item checked out from library B, but hasn't opted in at library B, the latter should still the patron's info for that circulation? |
| 16:27 |
jihpringle |
if the item was lent to another library through interlibrary connect, checked out at that library and then returned to it's home library by the patron and something was wrong with the item (ie dvd was missing, item damaged) the owning library would need to know who borrowed the item so they could follow up with that patron's home library |
| 16:28 |
jihpringle |
(patrons in BC can return items to any public library regardless of where they checked it out) |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:34 |
jeff |
okay, and the owning library would require the patron name rather than the patron's home library being the only one to look it up. interesting. |
| 16:36 |
jihpringle |
if the item was returned directly to the owning library without the info in the last circ the owning doesn't know which borrowing library to contact for followup |
| 16:36 |
jeff |
would displaying the library instead of the patron details in the circ history be useful in that case? |
| 16:38 |
jihpringle |
that's probably all the info the library really needs |
| 16:38 |
jeffdavis |
It's an extra step for the patron's home library to look up the circ history themselves to find the user if they need to contact them. I'll defer to jihpringle on whether that is an issue though. :) |
| 16:38 |
jihpringle |
but as jeffdavis says it does make additional work for the home library over the owning library |
| 16:39 |
jeffdavis |
jeff: let me dig up our local changes that force an opt-in check in circ history and other places in the XUL client, there may be cases where it's important to have some kind of patron-identifying info |
| 16:42 |
jeffdavis |
http://git.sitka.bclibraries.ca/gitweb/?p=sitka/evergreen.git;a=commitdiff;h=a45a759 |
| 16:44 |
jeffdavis |
a beast of a commit, that one :) |
| 16:47 |
mmorgan |
Is there nothing in the action trigger hooks or validators for overdue notices that looks at xact_finish? |
| 16:48 |
mmorgan |
I see checkin_time and stop_fines, but not xact_finish. |
| 16:49 |
jeff |
jeffdavis: "comprehensive" :-) |
| 16:51 |
jeff |
mmorgan: do you have a scenario in mind where checkin_time would be null and stop_fines would null, MAXFINES, or LONGOVERDUE and xact_finish would need to be consulted? a longoverdue + paid transaction? |
| 16:52 |
mmorgan |
jeff: Exactly. LOST or LONGOVERDUE, then paid. |
| 16:52 |
jeff |
well, LOST wouldn't validate CircIsOverdue, so that's covered already. |
| 16:53 |
mmorgan |
Ah. ok. Good point. |
| 16:53 |
mmorgan |
So the LONGOVERDUE paid items are the problem. |
| 16:53 |
jeff |
but I can see LONGOVERDUE being worth looking into a little more... do you have an environment where an A/T that uses CircIsOverdue is timed to happen AFTER a circ would normally be marked LONGOVERDUE? |
| 16:56 |
mmorgan |
Yes, we do end of semester reminders for some of our academics. I guess that's the only situation where this would be an issue. |
| 16:57 |
jeff |
interesting. how do you time those? |
| 16:57 |
mmorgan |
The processing delay and max validity cover due dates for the whole semester, so potentially a few paid long overdues would get pulled in. |
| 16:57 |
jeff |
ah |
| 16:57 |
mmorgan |
It's a backward way of doing statements, I know, but gets the job done. |
| 16:58 |
mmorgan |
Thanks, jeff. I realize it's only an issue for this type of trigger, so not as big a deal as I thought at first. |
| 16:58 |
mmorgan |
jeff++ |
| 16:59 |
jeff |
it might still make sense to adjust the criteria for CircIsOverdue |
| 16:59 |
jeff |
you could always make an XactIsOpen validator, but... |
| 17:01 |
mmorgan |
yes, I think it would make sense to adjust CircIsOverdue. Can't hurt, might help :) |
| 17:01 |
jeff |
CircIsOverdue including LONGOVERDUE makes sense, but it probably should then ALSO check xact_finish |
| 17:02 |
jeff |
though we then get into a philosophical debate on "is a long overdue item which has been billed and paid still overdue?" ;-) |
| 17:03 |
mmorgan |
Yes, exactly. Come to think of it, we do have another trigger that's affected, too. We send final reminders after six months long overdue. |
| 17:03 |
mmorgan |
So we really need that change. |
| 17:03 |
* mmorgan |
will open a launchpad bug. |
| 17:06 |
mmorgan |
jeff: re the philosophical thing, that's uncertain -- until it's returned. :) |
| 17:06 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:22 |
|
Jillianne2 joined #evergreen |
| 18:30 |
|
sandbergja joined #evergreen |
| 19:50 |
|
beanjammin joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
| 22:53 |
|
rlefaive joined #evergreen |
| 23:03 |
|
Callender joined #evergreen |
| 23:16 |
|
khuckins joined #evergreen |
