15:03:11 <jeffdavis> #startmeeting Evergreen Developer Meeting, 1 June 2016
15:03:11 <pinesol_green> Meeting started Wed Jun  1 15:03:11 2016 US/Eastern.  The chair is jeffdavis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:11 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:11 <pinesol_green> The meeting name has been set to 'evergreen_developer_meeting__1_june_2016'
15:03:14 <kmlussier> jeffdavis++
15:03:30 <jeffdavis> #info Agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-06-01
15:03:52 <jeffdavis> #topic Introductions
15:04:02 <jeffdavis> #info jeffdavis = Jeff Davis, Sitka
15:04:15 <Bmagic> #info Bmagic =  Blake GH, MOBIUS
15:04:16 <Dyrcona> #info Dyrcona = Jason Stephenson, MVLC
15:04:18 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:04:29 <jlitrell> #info jlitrell = Jake Litrell, MassLNC
15:05:03 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:05:07 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
15:05:20 <berick> #info berick Bill Erickson, KCLS
15:06:02 <jeffdavis> if anyone else joins, please introduce yourself as above
15:06:24 <jeffdavis> # topic Action Items from Last Meeting
15:06:28 <jeffdavis> er
15:06:31 <jeffdavis> #topic Action Items from Last Meeting
15:07:37 <brahmina> #info brahmina = Brahmina Burgess, Sitka
15:07:41 <jeffdavis> first action item is "Dyrcona to write up bug report for nodejs installation item on Ubuntu 14.04", sounds like that is resolved?
15:08:10 <Dyrcona> Yes. It was resolved by npm getting their act together. :)
15:08:38 <jeffdavis> #info DONE: Dyrcona to write up bug report for nodejs installation item on Ubuntu 14.04 - resolved upstream by npm folks
15:09:20 <jeffdavis> where are we at with Xenial support? is there more work to be done there?
15:09:37 <Dyrcona> I don't think so.
15:10:04 <Dyrcona> Ubuntu trusty and Debian Jessie could use a small patch that turned up in the Xenial work, but Xenial is working for me.
15:10:25 <berick> xenial working for me too
15:10:49 <jeffdavis> great!
15:11:10 <jeffdavis> #info DONE: Dyrcona will work on Xenial Xerus Evergreen and OpenSRF support between now and the EG conference - thanks to Dyrcona, csharp, and bshum
15:11:33 <jeffdavis> #info DONE: gmcharlt will send an email to the mailing lists announcing the Pg dependency change
15:12:01 <gmcharlt> #info gmcharlt = Galen Charlton, ESI
15:13:12 <jeffdavis> last action item was about Sqitch
15:13:36 <jeffdavis> i.e. more detailed evaluation/testing thereof
15:13:46 <jeffdavis> status according to the agenda: "Bill pushed a version of the Sqitch setup with a reified database (1 schema file and a handful of data files) for discussion. Confirmed Ubuntu 16.04 has a Sqitch package. Need to explore release-building options (presumably via 'sqitch bundle –from foo –to bar'). Probably other stuff too."
15:14:06 <jeffdavis> Is there anything else to add or discuss there for now?
15:14:08 <Dyrcona> I'd call that "in progress."
15:14:22 <Dyrcona> For the sake of the minutes.
15:14:30 <berick> 'in progress' sounds good
15:15:10 <jeffdavis> shall we capture those details in the minutes as well?
15:15:41 <Dyrcona> I'd just say in progress: action item.
15:15:52 <Dyrcona> I don't think the minutes need the detail.
15:16:02 <Dyrcona> It'll be in the logs and the agenda.
15:16:26 <jeffdavis> #info IN PROGRESS: evaluation/testing of Sqitch
15:16:40 <miker> #info miker = Mike Rylander, ESI
15:17:01 <jeffdavis> #action developers to continue looking at Sqitch, particularly release-building options
15:17:42 <jeffdavis> #topic OpenSRF release
15:18:31 <gmcharlt> so, there are some patches in the queue that I need to review
15:18:50 <gmcharlt> and ensure that OpenSRF master will build all on all of the target platforms
15:19:04 <gmcharlt> I've also got some pull requests that I may tap some people to review
15:19:22 <gmcharlt> but upshot, we can plan on a release before ALA Annual, in both the 1.5 and 1.4 series
15:20:45 <jeffdavis> gmcharlt: sorry, 1.5 and 1.4 series?
15:20:53 <miker> s/1\.(\d)/2.$1/g
15:21:16 <jeffdavis> ah perfect
15:21:16 <gmcharlt> er, yeah, what miker said
15:21:25 * jeff arrives
15:21:45 <gmcharlt> Announcing OpenSRF random() !
15:22:07 * miker gets his delorian out of the garage
15:22:13 <jeff> #info jeff == Jeff Godin, Traverse Area District Library (TADL)
15:22:58 <jeffdavis> #action gmcharlt to review a few outstanding OpenSRF patches/pull requests
15:23:52 <jeffdavis> would the 2.5 release be an alpha/beta, or do we expect to have 2.5.0 ready by ALA?
15:25:50 <jeffdavis> #info New OpenSRF releases for both 2.4 and 2.5 are expected before ALA Annual in late June
15:26:06 <gmcharlt> jeffdavis: depends on what I see in the patches
15:26:16 <gmcharlt> but at most there would be a beta prior to the 2.5.0 release
15:27:05 * jeffdavis nods
15:28:04 <jeffdavis> moving on...
15:28:12 <jeffdavis> #topic Evergreen release
15:28:48 <miker> I'll have a firm proposed schedule for the list tomorrow. don't expect it to deviate much from last summer's
15:29:03 <dbwells> I've got a TODO to send an introductory email to my fellow buildmasters plus miker, nothing too involved, but a stake in the ground at least. Feel free to add as an action item.
15:29:26 <miker> dbwells: that's be great
15:29:49 <miker> and, with the schedule, a list of likely branches I hope to see merged
15:30:17 <miker> and, secondarily, a list of possible upcoming tickets lacking pullrequests
15:31:02 <miker> and, thirdly, but not least-ly, a bugs-we-should-really-finally-finish list
15:31:13 <miker> the first list being features with pullrequests
15:32:48 <miker> if anyone has specific strong desires, I'm happy to lend my RM poking stick to the effort. also, poke me if I miss something you really want/need
15:33:29 * kmlussier never realized a poking stick came with the RM position.
15:33:43 <miker> kmlussier: it's a very floppy stick
15:33:57 <miker> +0 damage
15:34:08 <kmlussier> :)
15:34:09 <gmcharlt> comes from the same box as the noodle lash
15:34:11 <jeffdavis> miker++
15:34:19 <kmlussier> miker++
15:35:01 <Dyrcona> Sounds like miker gave himself an action to send an email to the lists....
15:35:15 <miker> Dyrcona: I did, indeed
15:35:23 <jeffdavis> #action miker will email the list with a proposed schedule for 2.11 and a list of pending bugs/pullrequests
15:35:44 <Dyrcona> miker++
15:35:47 <jeffdavis> #action dbwells will email the list with an introduction to the 2.11 release manager and buildmasters
15:36:10 <dbwells> jeffdavis: actually not the list, just some internal coordination
15:36:11 <miker> jeffdavis: that second one may not be a list email... dbwells?
15:36:12 <miker> heh
15:36:39 <jeffdavis> #action dbwells will send an introductory email to the 2.11 release manager and buildmasters
15:36:50 <jeffdavis> #action jeffdavis will read IRC more carefully
15:36:52 <jeffdavis> :P
15:37:17 <jeffdavis> anything else on EG releases before we move on?
15:37:20 <Dyrcona> :)
15:37:30 <miker> not from me
15:38:45 <jeffdavis> ok, on to new business then
15:38:55 <jeffdavis> #topic Defining Bug Fixes and New Features
15:39:18 <jeffdavis> Dyrcona: I think this was your agenda item
15:39:27 <Dyrcona> Most of what I have to say about it is summarized in point 2, 3, and 4 in comment 38 from the Agenda.
15:39:32 <Dyrcona> #link https://bugs.launchpad.net/evergreen/+bug/1501781/comments/38
15:39:34 <pinesol_green> Launchpad bug 1501781 in Evergreen "Patron name search should be diacritic-insensitive" [Wishlist,Confirmed] - Assigned to Terran McCanna (tmccanna)
15:40:23 <Dyrcona> We don't have any actual rules about we do or do not backport as far as fixes go, and it might be helpful to clarify a few things.
15:41:04 <dbwells> I think that comment it a pretty good summary, and I agree with all of it in the sense of making them guidelines.
15:41:09 <miker> IMO, I'd go futher and say that anything that changes the db for reasons other that wrongness or broad performance (index or such) should have a high bar for backport
15:41:35 <kmlussier> I'm okay of identifying guidelines for what should be considered a bug fix / new feature. But I think some judgment should be used too. If something is a bug, it's a bug, even if the fix requires the introduction of a new string.
15:41:55 <kmlussier> okay *with*
15:42:24 <gmcharlt> I agree that judgment must be permitted on the part of the rmaints
15:42:57 <Dyrcona> Yeah, I'm not trying to usurp any power from maintainers. Ultimately, it should be their call.
15:44:07 <gmcharlt> to respond to a couple points in Dyrcona's comments on the LP
15:45:01 <gmcharlt> #1 - whether or not this is a bug kinda depends on one's locale, no? I think things that increase usability for non-EN locales should get some leeway
15:45:46 <gmcharlt> #2 - the inability to easily get string changes for maintenance releases is, IMO, more reflective of a weakness in our translation infrastructure than anything else
15:46:15 <gmcharlt> not that I'm offering an immediate solution, mind you
15:46:55 <gmcharlt> so I guess one question I have: what problems are we specifically trying to solve by limiting what gets backported as bugfixes?
15:47:21 <gmcharlt> to be sure, I don't disagree with the general notion that new features generally should not be backported into maintenance releases
15:47:59 <Dyrcona> I think one issue we have is, "what is a bug?" There is often disagreement.
15:48:41 <gmcharlt> so, some things I think we could have a quick consensus on
15:48:50 <gmcharlt> so, a couple suggestions along those lines
15:49:14 <gmcharlt> 1. security issues may potentially trump other considerations
15:50:08 <gmcharlt> 2. something that that adds a new depency (in the form of a Perl module or APT or RPM package) should not be backported without extreeme provocation
15:51:16 <gmcharlt> with the motivation for ^^ being a more general principle that "maintenance release upgrades should be quick, easy, and unsurprising to the sysadmin"
15:51:26 <gmcharlt> is this useful as a starting point?
15:51:38 <jeff> seems quite reasonable so far.
15:52:08 <kmlussier> Yes, I agree with everything above
15:52:18 <jeffdavis> +1
15:52:22 <miker> +1
15:52:41 <gmcharlt> 3. (in agreement with Dyrcona) things that add YAOUS are generally not candidates for backporting
15:53:16 <kmlussier> +1
15:53:28 <gmcharlt> (and a side note on dependencies in general: I'm a big fan of *not* adding new dependencies unless there's no other reasonable way to add functionality)
15:53:31 <Dyrcona> +1
15:54:38 <miker> can that be generalized to "things that change existing correct behavior are not bug fixes", with the key being "correct" for some reasonable definition?
15:54:45 <miker> or is that a bridge too far
15:54:52 <gmcharlt> 4. anything that *requires* that the EG admin do something post-upgrade should be discouraged from being backported
15:55:42 <gmcharlt> miker: well, "correct" is kinda the sticking point :)
15:56:00 <kmlussier> miker: the definition of 'existing correct behavior' is a squish as the definitions for bug and new feature IMO. I've seen many people say something is incorrect that probably meets your definition of 'existing correct behavior.'
15:56:29 <gmcharlt> but to take the example of bug 1501781, I would give more weight if (say) the Czech folks chimed in and said "we really need this sooner rather than later"
15:56:31 <pinesol_green> Launchpad bug 1501781 in Evergreen "Patron name search should be diacritic-insensitive" [Wishlist,Confirmed] https://launchpad.net/bugs/1501781 - Assigned to Terran McCanna (tmccanna)
15:56:31 <miker> fair
15:56:53 * kmlussier needs to run, but generally likes where this discussion is going.
15:57:12 <kmlussier> jeffdavis: We can defer my agenda item to the next meeting. There's no rush on it.
15:57:22 <jeffdavis> kmlussier: ok noted, thanks
15:57:29 <kmlussier> jeffdavis++
15:57:43 <jeffdavis> gmcharlt: do you have further points to suggest beyond your #4 above?
15:58:05 <gmcharlt> jeffdavis: nothing organized, and I've been monologuing enough anyway :)
15:58:15 <jeffdavis> ha ok :)
15:58:40 <jeffdavis> it seems to me there is a general consensus on the points discussed
15:59:12 <jeffdavis> Dyrcona: do you feel like this addresses the concerns you've had? Any concerns or anything more you want to raise here?
15:59:47 <Dyrcona> I don't have anything to add.
15:59:58 <dbwells> I see whatever comes of this as a "Considerations for Backporting" page, to help everyone remember and recognize the pros and cons to an invariably squishy process.
16:00:40 <jeffdavis> How do we want to capture this for future use? Anyone want to volunteer to summarize these points on a wiki page, for example?
16:00:46 <gmcharlt> if Dyrcona wants, I'd be willing to volunteer to work with him on such a thing
16:01:16 <Dyrcona> Sounds good to me.
16:01:18 <gmcharlt> (as I think we kinda represent somewhat contrary views, so hopefully the squishy middle we'd end up with would be good, as it were :) )
16:02:07 <jeffdavis> #action gmcharlt and Dyrcona to summarize results of this discussion on the wiki for future use by release maintainers
16:02:12 <jeffdavis> Dyrcona++
16:02:14 <jeffdavis> gmcharlt++
16:02:44 <jeffdavis> moving along
16:02:46 <jeffdavis> #topic Mentoring new developers in the community
16:02:53 <jeffdavis> #info Discussion deferred to next dev meeting
16:03:02 <jeffdavis> #topic Recent config changes affecting ingest speed
16:03:11 <jeffdavis> dbwells, want to speak to this?
16:03:56 <dbwells> yes, one moment
16:04:04 * Dyrcona wishes that branch existed over 72 hours ago. :)
16:04:22 <dbwells> Has anyone taken a look at the change?
16:04:29 <jeff> I have.
16:04:33 <jeff> Looks reasonable.
16:04:37 <miker> as have I. I like it
16:04:54 <jeff> And a good way to cope with the 2234% increase in rows in crad. :-)
16:05:14 <dbwells> Alright, maybe that's enough for now.  I will create a bug for it, and post  a few extra thoughts there.
16:05:19 <Dyrcona> I've looked at the code, and have a slow server that it would be perfect to test on.
16:05:26 <miker> not sure if an index would actually matter, but might be worth testing
16:05:34 <Dyrcona> I even have timings for comparison-sake.
16:06:07 <dbwells> miker: Yes, an index on ctype also helps, so that's a secondary play.
16:06:39 <jeffdavis> #action dbwells to create a bug report for discussing some proposed ingest speed improvements
16:06:47 <jeffdavis> dbwells++ # looks promising to me!
16:07:23 <jeff> I think I was seeing a roughly "12x slower" record attr ingest with 2.10 when I was measuring timings, so a "7x better than that" is quite promising.
16:07:36 <dbwells> One question I'll want more input on is whether we should flip the 'filter' flag off for some of the new rows by default, especially those which don't index anything.
16:08:00 <Dyrcona> my record attr ingest that I started Sunday, took 67 hours to complete, on the "slow" server.
16:08:01 <dbwells> It would be belt + suspenders at that point, but maybe worth not tripping over again down the road.
16:08:09 <jeff> if they don't index anything, is the filter bit being set just an error?
16:08:26 <dbwells> filter is true by default, so an error of omission if anything.
16:08:40 <dbwells> But I can't read minds!
16:09:43 <dbwells> I know we're over time already, and I think bugs are a better place to capture stuff like this anyway.  Just wanted a quick reaction before heading down that route.  Thanks, all.
16:09:52 <jeff> dbwells++
16:09:55 <jeffdavis> thanks dbwells
16:10:04 <miker> dbwells++
16:10:07 <jeffdavis> #topic Feedback for New Features Under Development
16:10:22 <jeffdavis> bug 1373690 was mentioned on the agenda - berick, is that you?
16:10:23 <pinesol_green> Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick)
16:10:36 <berick> that's me
16:10:41 <berick> trying to kill the bug that won't die
16:10:58 <berick> hoping to make significant changes to how we generate EDI
16:11:10 <berick> need sample data from the wild to be sure the new code is covering edge cases
16:11:26 * Dyrcona can have a look.
16:11:38 <berick> in short, moving all logic into Perl and out of the A/T templates
16:12:01 <jeffdavis> berick: I'll pass that one along to our support folks to see if we can test
16:12:24 <berick> beware to test, you have to install the new code (obviously, i guess) which includes some new DB tables
16:12:27 <berick> and data
16:12:53 <berick> the code does not yet have a UI for tweaking settings.  that will come later
16:13:02 <berick> wanted to be sure this is on the right path first
16:13:08 <berick> thanks Dyrcona and jeffdavis
16:13:31 <berick> i'll copy the "how to test" instructions from the agenda to the bug
16:13:40 <jeffdavis> berick++
16:13:47 <Dyrcona> berick++
16:14:34 <jeffdavis> Any other new features to discuss before we adjourn?
16:16:34 <jeffdavis> ok, that's it then - thanks everyone!
16:16:45 <berick> thanks jeffdavis!
16:16:51 <jeff> jeffdavis++
16:16:58 <jeffdavis> #endmeeting