15:01:33 <gmcharlt> #startmeeting Development meeting, 3 May 2017
15:01:33 <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:33 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:33 <pinesol_green> The meeting name has been set to 'development_meeting__3_may_2017'
15:01:41 <gmcharlt> #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-05-03
15:01:56 <gmcharlt> #topic Introductions
15:02:04 <gmcharlt> #info Galen Charlton, EOLI, 3.0 RM
15:02:11 <dbs> @info Dan Scott, Laurentian University
15:02:11 <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:12 <DPearl> #info DPearl is Dan Pearl, C/W MARS Inc.
15:02:16 <dbs> #info Dan Scott, Laurentian University
15:02:19 <abowling> #info abowling = Adam Bowling, Emerald Data Networks
15:02:19 <rhamby> #info Rogan Hamby, Equinox
15:02:22 <phasefx> #info Jason Etheridge, EOLI
15:02:23 <dbs> It's going to be one of those days, is it?
15:02:27 <kmlussier> #info Kathy Lussier, MassLNC
15:02:35 <Dyrcona> #info Jason Stephenson, C/W MARS
15:02:38 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
15:02:47 <kmlussier> dbs: Would you like me to point you to our IRC beginner's guide? ;)
15:02:49 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:02:50 <berick> #info berick Bill Erickson, KCLS
15:02:58 <csharp> #info csharp is Chris Sharp, GPLS
15:03:37 <gmcharlt> one moment as I update agenda with action items from conf
15:03:45 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka)
15:04:38 <gmcharlt> so, done
15:04:45 <gmcharlt> please refresh https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-05-03
15:04:55 <gmcharlt> #topic Action items from previous meeting
15:05:52 <gmcharlt> so, first one is for me to send out a call to use open-ils-dev more
15:06:13 <gmcharlt> I'll carry that over and do it this week + discuss it on my weekly dev update blog post
15:06:16 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:06:20 <gmcharlt> so,
15:06:23 <gmcharlt> #action Galen will send out a call for patch authors to use open-ils-dev to introduce new features.
15:06:44 <gmcharlt> next action is "Galen starts bugging ALL THE FOLKS on #evergreen"
15:06:45 <dbs> gmcharlt++ # weekly dev update posts
15:06:48 <gmcharlt> which I am doing
15:06:58 <gmcharlt> so y'all please consider yourselves bugged
15:06:59 <kmlussier> gmcharlt++ indeed
15:07:11 <gmcharlt> ... wait, maybe that didn't come out quite right ;)
15:07:31 <Dyrcona> The channel is logged, we're all bugged. :)
15:07:48 <abowling> like trump tower?
15:07:50 <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:57 <gmcharlt> next one - Ben Shum and Dan Scott will set up Launchpad and the bzr repo to start permitting series-level translations.
15:08:05 <gmcharlt> bshum, dbs: ^^ updates?
15:08:42 <dbs> bshum was doing some experimentation
15:08:50 <dbs> but I have nothing concrete to share
15:09:15 <dbs> I think the realization that some of the translations were way out of whack took priority
15:09:32 <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:45 <gmcharlt> but yeah, there've been multilingual spiders crawling out
15:10:19 <gmcharlt> any other i18n comments at the moment?
15:10:45 <dbs> nope
15:10:54 <abowling> there was some interest at the conference during our session
15:11:36 <abowling> specifically, cherokee had multiple persons in support...but nothing technical to add
15:11:58 <gmcharlt> Cherokee the language, you mean?
15:12:11 <abowling> yes, sorry. i realize that was vague.
15:12:21 <gmcharlt> neat!
15:12:33 <bshum> gmcharlt: Oh sorry I wasn't watching my screen
15:12:43 <gmcharlt> welcome, bshum
15:12:44 <bshum> Yes, we setup 2.12 bzr
15:12:55 <bshum> So we're capable of doing translations for specific series now
15:13:02 <dbwells> Bmagic and I did at least pull in a new PO from the bzr branch for 2.12.1
15:13:07 <bshum> I think Bmagic used those steps
15:13:08 <bshum> yup
15:13:14 <Bmagic> I did
15:13:23 <gmcharlt> ah, cool, I had missed that
15:13:28 <dbwells> We generated the newpot too, but not sure exactly how/when that gets picked up
15:13:40 <abowling> i thought so too, especially because it didn't occur to me that indigenous American languages might be a hotbed
15:13:43 <bshum> Yeah I want to tweak the timing a bit more too
15:13:53 <dbwells> hoping it just flows in by tracking 2_12?
15:13:56 <bshum> Right now it's doing git -> bzr at 10 pm Eastern for 2.12
15:14:03 <bshum> So it should flow through any changes
15:14:13 <dbwells> cool, thanks for confirming
15:14:13 <bshum> And vice versa when you pull back
15:14:29 <dbs> bshum++
15:14:34 <gmcharlt> bshum++
15:14:46 <gmcharlt> OK, then I think we can consider that actino item done
15:14:58 <gmcharlt> so, moving on
15:15:05 <gmcharlt> #topic OpenSRF release info
15:15:33 <gmcharlt> #info bug 1684970 warrants a release of 2.5.1 this month
15:15:33 <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:03 <gmcharlt> any other particular questions, concerns, burning bugs, or works-in-progress for OpenSRF?
15:17:48 <gmcharlt> going once
15:18:05 <gmcharlt> going twice
15:18:13 <gmcharlt> #topic Evergreen releases
15:18:27 <gmcharlt> #info 2.12.1, 2.11.4, and 2.10.11 were released on 19 April
15:18:44 <gmcharlt> #info 2.10.11 is the last bugfix release for 2.10.x, which is now security only
15:19:29 <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:45 <gmcharlt> indeed
15:20:02 <gmcharlt> also, somebody highlighted bug 1646638
15:20:02 <pinesol_green> Launchpad bug 1646638 in Evergreen "SIP authentication sessions timeout in 2.11" [Undecided,Confirmed] https://launchpad.net/bugs/1646638
15:20:26 <gmcharlt> which at first blush looks like would be easy to include in the May releases
15:20:41 * dbs was "somebody"
15:20:50 <gmcharlt> dbs++
15:20:53 <dbs> I had forgotten about that bug until rsoulliere ran into it
15:20:54 <Bmagic> dbs++ # SIP patch
15:21:16 <Bmagic> We ran into it as well, it was killing us for about 3 weeks
15:21:24 <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:44 <Bmagic> I don't see why not
15:21:52 * dbs borrows from improv and suggests "and"
15:21:54 <Dyrcona> Yes, I think it would.
15:22:19 <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:22 <dbs> opac + patch for short-term, new auth for next release
15:22:33 <dbs> csharp++
15:22:36 <kmlussier> csharp++
15:22:43 <dbs> and Bmagic++ # opening the bug
15:22:51 <csharp> dbs++
15:22:57 <csharp> all_yall++
15:22:58 <dbs> upgrades are such a blur
15:23:02 <gmcharlt> OK, I'll also open an LP for a new auth type as well
15:23:04 <csharp> dbs: srsly
15:23:39 <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:44 <gmcharlt> ?
15:24:38 <gmcharlt> going  once
15:25:00 <gmcharlt> going twice
15:25:15 <gmcharlt> #topic Statement of responsibilities of core committers
15:25:17 <gmcharlt> #link https://wiki.evergreen-ils.org/doku.php?id=contributing:core_committer_responsibilities
15:25:37 <gmcharlt> this was something that was drafted by kmlussier and me and initially discussed at the conference
15:26:03 <gmcharlt> and at this point, I'd like to open it up any further discussion
15:26:16 <gmcharlt> and unless blockers arise, hold a vote of this meeting on whether to formally adopt it
15:28:26 <gmcharlt> any comments before I start the vote?
15:28:37 <dbs> The only thing I stumbled over was the use of the word "integrity" to describe evergreen's architecture
15:28:43 <kmlussier> No comments from me. I think it covers things well.
15:29:10 * phasefx hides the hamster wheels
15:29:21 <gmcharlt> dbs: in the sense that "integrity of architecture" is perhaps aspirational, or a substantive concern about aiming for it?
15:29:45 <dbs> It just seems like the wrong word?
15:30:03 <dbs> "To advocate for the integrity of Evergreen's architecture", I don't know what that means
15:30:15 <gmcharlt> "consistency"?
15:30:36 <phasefx> and/or quality?
15:30:42 <dbs> s/integrity/technical soundness/ ?
15:30:48 <dbs> I like "quality" better
15:31:06 <gmcharlt> "quality" works for me
15:31:08 <dbs> maybe it's just me
15:31:12 <phasefx> s/architecture/codebase/?
15:31:12 <kmlussier> I could get on board with 'quality'
15:31:16 <Dyrcona> Perhaps the use of integrity in this case is an Americanism.
15:32:02 <dbs> The senses of "integrity" that I'm familiar with are either completeness, or moral
15:32:19 * dbwells looks in thesaurus, laughs at "nature of beast"
15:32:30 <Dyrcona> Well, completeness is more what I think it means.
15:32:34 * phasefx 's reference is Star Trek, hull and shields
15:32:56 <gmcharlt> dbs: yeah, the denotation I was going for was "The state of being unimpaired; soundness.
15:32:56 <gmcharlt> "
15:33:31 <dbs> And I *think* what is meant is that we should be continually trying to improve the quality of the architecture
15:33:45 <dbwells> I like "quality" fine.  Also like "soundness", actually.
15:34:08 <dbs> Okay. Whatever helps us kick XUL and Dojo to the curb :)
15:34:16 <phasefx> har
15:34:17 <kmlussier> heh
15:34:19 <gmcharlt> dbs: yes, as well as to resist making changes that reduce archtectural quality in the name of undue expedience
15:34:49 <jeffdavis> integrity implies coherence/consistency as a goal to me
15:35:11 <jeffdavis> dunno if that should be specifically articulated
15:35:25 <gmcharlt> so, here's what I've come up with
15:35:26 <gmcharlt> "The quality of Evergreen's architecture and its continual improvement"
15:37:05 <dbs> +1
15:37:17 <gmcharlt> OK, I've saved the wiki edit
15:37:31 <gmcharlt> any other wording tweaks before we vote?
15:38:34 <gmcharlt> ok
15:38:39 <dbwells> berick and I talked a bit at the conference about the last individual one
15:39:25 <dbwells> I just wonder if we need to be that specific, or if "model good participation" really says enough.
15:40:28 <dbwells> I have no problem with the concept, but just how it comes across to any casual reader of the document.
15:40:48 <Dyrcona> The model good participation one is kind of vague.
15:41:06 <dbs> Perhaps the example could be added to the "model good participation" clause and the more negative clause could be deleted?
15:41:22 <Dyrcona> That might work.
15:41:34 <dbs> dbwells: you mean casual reader thinks "oh this place sounds toxic, I'm out of here"?
15:41:42 <dbwells> dbs: yes, exactly
15:42:21 <kmlussier> I'm not sure the example exactly goes with the 'model good participation' bit.
15:42:51 <Dyrcona> To me the whole list reads like a model of good participation.
15:44:09 <Dyrcona> After reading it yet again, I think I'm in favor of dropping the last individual one, too.
15:44:52 <Dyrcona> I'd prefer a list of "thou shalts" over "thou shalt nots"
15:44:58 <Bmagic> we could have a meeting about it.....
15:45:07 <Dyrcona> heh
15:45:38 <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:01 <Dyrcona> Yes, but should policy be made around the exceptions or the general rule?
15:46:27 <dbs> and that providing examples might help us recognize negative patterns of behaviour for ourselves that we otherwise would not
15:47:13 <kmlussier> Yes, I was thinking the same as dbs.
15:47:25 * dbs can benefit from this kind of reflection
15:47:26 <gmcharlt> so yeah, one of the potential things here - and this might be better as an example - is the use of snark
15:47:35 <dbwells> Well, how about simply "To encourage other committers who are taking on group responsibilities."  ?
15:48:08 <gmcharlt> to which I will cop -- but is also something that can discourage participation
15:48:31 <gmcharlt> to tease apart what I was trying to do here
15:48:40 <dbwells> Then leave the example as well.
15:48:53 <gmcharlt> (a) commiters don't necessarily need to feel obligated to participate in ALL collective responsibilities
15:49:24 <dbwells> We can all use more encouragement from time to time, and that isn't mentioned anywhere yet :)
15:49:32 <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:54 <gmcharlt> but should take care to direct folks to the ones who are interested
15:50:01 <gmcharlt> and also pay attention to overall tone of communications
15:50:52 <gmcharlt> and I do think that it's important to both acknolwedge patterns *and* antipatterns
15:51:08 <gmcharlt> so,
15:51:15 <gmcharlt> here's a suggested alternative
15:51:56 <Dyrcona> I like dbwells suggested wording.
15:52:44 <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:11 <gmcharlt> I would propose dbwells' wording as an *additional* point
15:54:02 <jeffdavis> +1 to that wording and to adding "model good participation" as an additional point
15:54:39 <kmlussier> gmcharlt: That sounds good to me.
15:55:14 <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:38 <Dyrcona> jeffdavis: Model good participation is already there, in case you missed it.
15:55:43 <gmcharlt> OK, please refresh https://wiki.evergreen-ils.org/doku.php?id=contributing:core_committer_responsibilities
15:56:04 <jeffdavis> Dyrcona: ha, so I did, thanks
15:56:05 <gmcharlt> er, refresh again (added a missing "to")
15:56:13 <kmlussier> :)
15:57:07 <gmcharlt> so, ready for vote?
15:57:39 <dbwells> sorry to need to delay the vote, thanks to all for listening!
15:58:02 <kmlussier> I'm ready
15:58:18 <dbwells> ready
15:58:25 <gmcharlt> #startvote Shall the statement of committer responsibilities linked above be adopted? Yes, No, Abstain
15:58:25 <pinesol_green> Begin voting on: Shall the statement of committer responsibilities linked above be adopted? Valid vote options are Yes, No, Abstain.
15:58:25 <pinesol_green> Vote using '#vote OPTION'. Only your last vote counts.
15:58:34 <gmcharlt> #vote Yes
15:58:36 <dbwells> #vote Yes
15:58:39 <kmlussier> #vote Yes
15:58:46 <abowling> #vote Yes
15:58:49 <dbs> #vote Yes
15:58:54 <Dyrcona> #vote Yes
15:58:59 <DPearl> #vote Yes
15:59:00 <jeff> #vote Yes
15:59:02 <rhamby> #vote Yes
15:59:04 <phasefx> #vote yes
15:59:12 <remingtron> #vote yes
15:59:41 <berick> #vote yes
16:00:47 <gmcharlt> #endvote
16:00:47 <pinesol_green> Voted on "Shall the statement of committer responsibilities linked above be adopted?" Results are
16:00:47 <pinesol_green> Yes (12): kmlussier, DPearl, jeff, berick, abowling, phasefx, dbwells, Dyrcona, gmcharlt, remingtron, dbs, rhamby
16:01: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:14 <gmcharlt> so, we're now jsut past an hour, with stuff left on the agenda
16:01:37 <gmcharlt> I'm inclined to start a thread regarding LP replacement on open-ils-dev
16:01:44 <gmcharlt> but we also have three highlighted bugs
16:01:56 <dbwells> +1 to LP replacement thread
16:02:00 <kmlussier> +1 to email thread
16:02:09 <Dyrcona> Yeah, I'll move to skip that and discuss it on the list.
16:02:11 <gmcharlt> thought so :)
16:02:24 <dbs> I'm happy to just have some eyes on the bugs, doesn't need to be discussed here
16:02:31 <gmcharlt> #action gmcharlt will start thread on moving forward with investigation of replacing LP
16:02:54 <Dyrcona> I am looking at Gitlab, fwiw.
16:03:17 <dbwells> dbs++
16:03:26 <gmcharlt> dbs: I've been keeping an eye on them, and thus far not seeing any conceptual blockers
16:03:42 <kmlussier> dbs: Should bug 1687545 be addressed before bug 1411699 goes in?
16:03:42 <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:42 <gmcharlt> (other than sort out & vs ; in the one)
16:03:43 <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:17 <dbs> kmlussier: 1411699 has two branches, one which could go in immediately
16:04:36 <dbs> the other (rewrite to remove dojo) could follow on after 1687545
16:04:57 <gmcharlt> #info Patches for bug 1685840, bug 1681095, and bug 1411699 are commended to the dev community for general attention and testing
16:04:57 <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:57 <dbs> not to be confused with the rewrite to remove dojo for google books preview ;)
16:04:58 <kmlussier> dbs: OK, thanks for clarifying.
16:04:59 <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:00 <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:07 <gmcharlt> ok, I think that's a wrap
16:05:12 <gmcharlt> #endmeeting