15:06:03 <kmlussier> #startmeeting 2017-03-01 Developer meeting
15:06:03 <pinesol_green> Meeting started Wed Mar  1 15:06:03 2017 US/Eastern.  The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:03 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:06:03 <pinesol_green> The meeting name has been set to '2017_03_01_developer_meeting'
15:06:17 <kmlussier> #topic Introductions
15:06:34 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:06:49 <abowling> #info abowling is Adam Bowling at Emerald Data Networks
15:06:55 <terran> #info terran is Terran McCanna, Georgia PINES
15:07:02 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
15:08:02 <remingtron> looks like it's just us Padawans today
15:08:29 <kmlussier> Yeah, I'm wondering if this is one of those meetings where it might be better to postpone.
15:08:32 <gmcharlt> #info gmcharlt Galen Charlton, EOLI
15:08:59 * kmlussier reads EOLI, but sees Aioli
15:09:25 * gmcharlt commissions a recipe ;)
15:10:22 <gmcharlt> if we want to go with a compressed agenda, I have a suggestion
15:10:31 <berick> #info berick Bill Erickson
15:10:33 <gmcharlt> namely, what are the top priorities for testing for the upcoming releases?
15:12:10 <kmlussier> OK, well the agenda is fairly short as it is, so let's note that the one action item is deferred and move on to updates where we can talk about testing for 2.12.
15:12:26 <gmcharlt> #link https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-03-01#new_business
15:12:39 <kmlussier> Thanks, I was just about to do that! It's been a while since I took the meeting controls.
15:12:50 <kmlussier> #topic Action items from last meeting
15:13:23 <kmlussier> #info kmlussier has not yet solicited feedback on release process documentation.
15:13:30 <kmlussier> #action  kmlussier will post to open-ils-dev soliciting feedback on the release process documentation
15:13:39 <kmlussier> I should have a little more time on my hands in a couple of weeks.
15:13:56 <kmlussier> #topic OpenSRF 2.5 updates
15:14:01 <kmlussier> gmcharlt?
15:14:17 <gmcharlt> #info OpenSRF 2.5.0-rc released today
15:14:32 <gmcharlt> #info OpenSRF 2.5.0 will be released on 14 March
15:14:49 <gmcharlt> #info Testing requested, in particular for installation issues on supported platforms
15:14:56 <gmcharlt> and that's it, unless there are questions.
15:16:25 <kmlussier> Any questions for gmcharlt?
15:16:48 * gmcharlt answers in advance: 42
15:16:58 <kmlussier> :)
15:17:29 <kmlussier> #topic Evergreen 2.12 updates
15:17:57 <kmlussier> #info 2.12 beta was released last week
15:18:18 <kmlussier> Thanks to everyone who helped get the release out and to those who helped with the issues with the automated tests.
15:18:50 <kmlussier> We're getting a lot of bug fixing activity done this week with Bug Squashing Week.
15:18:54 <kmlussier> terran++
15:20:12 <kmlussier> One thing I would like to do for the end of bug squashing week is to see if there are any volunteers in the community who might want to go through some of the use cases we have on the wiki just to make sure the release is in good shape.
15:20:51 <kmlussier> I think I tried something similar for the 2.10 release without much luck, but maybe we'll get some takers.
15:21:35 <kmlussier> I do have a question regarding translations. Eva had contacted me a while ago to see if we might be able to do the translation dance again at the .1 release to give translators more time to get their translations in.
15:21:51 <kmlussier> Is that something that would be doable?
15:22:21 <bshum> kmlussier: As long as we don't merge any new string changes or run any POT updates for the templates, then the PO files won't drift any further than what's in Launchpad
15:22:33 <bshum> So that is doable, until we start merging new features or syncing the templates again
15:23:02 <bshum> Or like how gmcharlt and others fixed some typos in the git branch and touched the change in all the templates too
15:23:05 <kmlussier> bshum: Oh, so if start merging things for the 3.0 release before the .1 release, it could be a problem?
15:23:31 <bshum> kmlussier: It'll only be an issue if we run the template sync job.  If we skip that only do the PO sync, then I think it'll be fine to merge new stuff too
15:23:33 <gmcharlt> bshum: would it be worth trying to set up per-series translations in LP?
15:23:42 <terran> I know Eva is looking at the Czech translation in 2.12 this week
15:24:15 <bshum> gmcharlt: It's probably possible, but I didn't look too much into it given our overall weak support for translations historically, and just not having enough eyes on the subject
15:24:26 <bshum> And I think we'd need to engage dbs into that discussioin
15:24:34 <bshum> Since we're using his bzr branches to do the PO sync updates
15:24:55 <gmcharlt> yeah... but I'm inclined to push a bit to see if we can make it happen
15:25:14 <bshum> It's been hard enough keeping master up to date, than to worry about specific past releases :)
15:25:25 <bshum> But the new round of translators have been especially dedicated :)
15:25:31 <kmlussier> Can we do an action item, then, to investigate the feasibility of doing per-series translations?
15:25:32 <gmcharlt> indeed
15:25:34 <terran> translators++
15:25:42 <gmcharlt> yeah, I'll take an action item
15:26:05 <kmlussier> #action gmcharlt to investigate the feasibility of doing per-series translations
15:26:32 <gmcharlt> just to set some expectations, unless it turns out to be really easy, I'm not contemplating going any earlier than 2.12
15:26:47 <kmlussier> Understood
15:26:55 <kmlussier> Does anyone have any questions or things they want to add about the 2.12 release?
15:27:47 * kmlussier pushes the cat off the keyboard.
15:27:57 <gmcharlt> :)
15:28:16 <kmlussier> #topic Search development and minimum Postgres requirements
15:28:34 <kmlussier> miker wasn't able to make the meeting today to provide more detail on this than I can give.
15:29:14 <kmlussier> MassLNC has contracted with Equinox to do the development to eliminate two-stage work in Evergreen.
15:29:35 <gmcharlt> one implication: we should consider deprecating Pg < 9.4 with the 2.12 release
15:29:42 <kmlussier> The work will need to use functions that are only available in Postgres 9.4 or above.
15:30:24 <bshum> Oh.  Good to know...
15:30:48 <bshum> Cause I was just engaging Dyrcona in my schemes to update Wheezy to use PG 9.3 from the PG community repo.  maybe we should set that to PG 9.4?  :D
15:31:03 <bshum> And make similar adjustments for Ubuntu Trusty
15:31:04 <kmlussier> gmcharlt: Deprecate 9.4 now? Does that give the community enough time.
15:31:23 <gmcharlt> no, deprecate 9.3 now
15:31:31 <gmcharlt> e.g., with 2.12, say:
15:31:33 <kmlussier> heh
15:31:37 <gmcharlt> - minimum required version is 9.3
15:31:44 <gmcharlt> - recommended minimum version is 9.4
15:31:45 <kmlussier> Sorry, that's what my head said. My fingers were thinking differently.
15:31:52 <bshum> Fun times.
15:31:53 <gmcharlt> - 9.3 will be deprecated
15:32:00 <gmcharlt> er, _is_ deprecated
15:32:12 * bshum will always be +1 to moving forward with PG versions
15:32:40 <gmcharlt> and I think there's enough time
15:33:03 <gmcharlt> reasoning: if somebody is planning to upgrade Pg anyway to install 2.12, there's no reason they can't go straight to 9.4
15:33:03 <kmlussier> OK, so right now, we are saying in the docs that 9.3 is minimum. But we should probably be saying the 9.3 is deprecated and 9.4 is recommended, correct?
15:33:10 <gmcharlt> yeah
15:33:12 <bshum> This new search development is intended for 2.next or 3.0, right?
15:33:16 <kmlussier> I'm obviously +1, because I think this development is important for search.
15:33:28 <kmlussier> Yes
15:34:07 <kmlussier> Does anyone have concerns with this plan?
15:34:26 <kmlussier> Or, since we have just a few people here today, should we send something to the dev list ahead of time to get more feedback?
15:34:41 <remingtron> dev list is a good idea
15:34:43 <gmcharlt> worth writing to dev reqardless
15:34:46 <terran> I can't imagine PINES would have a problem with it
15:35:12 <kmlussier> OK, I can take an action item to write something to the dev list then.
15:35:14 * gmcharlt files wishlist bug: authority-record-controlled spellchecking applied to #evergreen
15:36:44 <kmlussier> #action to send message to dev list regarding plan to deprecate Postgres 9.3 and recommend 9.4 for the 2.12 release with plans to remove support for 9.3 in 2.next.
15:36:53 <kmlussier> Sigh...let me try that again.
15:36:53 <terran> (terran just finds out we're already on 9.4)
15:37:06 <kmlussier> #action kmlussier to send message to dev list regarding plan to deprecate Postgres 9.3 and recommend 9.4 for the 2.12 release with plans to remove support for 9.3 in 2.next.
15:37:48 <kmlussier> Any other questions or thoughts on 9.3/9.4 support in Evergreen?
15:38:21 <jeff> I would recommend looking at postgresql EOL dates vs expected Evergreen EOL dates as you consider "minimum" vs "recommended", etc.
15:38:57 <bshum> PG 9.4 ends in December 2019 -- https://www.postgresql.org/support/versioning/
15:39:21 <bshum> So that should be fine for Evergreen.next purposes.  But should look further out I guess as time moves on
15:39:36 <bshum> PG 9.3 for Sept 2018, also fine I think
15:39:38 <kmlussier> 9.3 is end of life in September 2018.
15:39:40 <bshum> For 2.12
15:40:01 <kmlussier> So 2.12 EOL is March 2018
15:40:16 <kmlussier> With security updates going through to September 2018
15:40:44 <bshum> June?  3 months, or is it really six?
15:41:27 <jeff> in the past, we had at least a few Evergreen releases whose "minimum" postgresql version reached EOL before the Evergreen release reached EOL. We know those things ahead of time, usually -- so that might be one of the facts that we could state in the README where we recommend postgresql versions, so that the person making a selection at that time has the "pg x.y is deprecated as of this release and will actually reach EOL before this release of Evergreen i
15:41:29 <bshum> Either way, plenty of coverage
15:41:45 <kmlussier> bshum: You're right. It's 3 months. https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:schedule
15:41:55 <gmcharlt> sounds like an excellent conversation to continue on open-ils-dev
15:42:06 <jeff> gmcharlt++ indeed :-)
15:42:11 <kmlussier> OK, moving on then.
15:42:25 <kmlussier> #topic Starting RM selection for next release
15:42:37 <gmcharlt> so, I have a couple thoughts here
15:42:47 <gmcharlt> namely, that getting started sooner rather than later would be good
15:42:53 <kmlussier> +1
15:43:10 <gmcharlt> so, here's my proposal: I can send out the traditional call for nominations tomorrow
15:43:23 <gmcharlt> with deadline of 3/31
15:43:40 <gmcharlt> and voting to occur in-person and online during the afternoon dev hackfest on 4/6
15:43:52 <gmcharlt> another option would be to compress that timeline a bit
15:44:17 <gmcharlt> with the idea that the next RM would be elected during the week of the 27th
15:44:23 <gmcharlt> i.e., after 2.12.0
15:44:41 <gmcharlt> thoughts on either option (or any other)?
15:45:16 <kmlussier> I know we've traditionally voted at the conference, but I prefer an earlier timeline to give the RM as much time as possible to prepare for the release.
15:46:35 <bshum> Is the plan to make this next one 2.13 or 3.0?  Because I think extra lead time sounds good either way :)
15:47:07 <kmlussier> 3.0 is what we were planning.
15:47:15 <berick> i'm also in favor of extra lead time.  wouuld be cool if the RM was decided before the conf.
15:47:29 <kmlussier> I don't think anything has changed significantly with the web client to make us consider holding off on the big release.
15:47:36 <gmcharlt> agreed
15:47:42 <jeff> I think either timeline sounds reasonable. Practically, the RM may not have THAT much more lead time depending on their travel plans and such, but every bit helps, right? :-)
15:47:59 <gmcharlt> well, the next RM will be literally chained to their desk, so...
15:48:04 <gmcharlt> wait, did I say that part out loud?
15:48:21 <kmlussier> gmcharlt: Wait, I wasn't supposed to be chained to my desk for the last one?
15:48:32 <kmlussier> Now you tell me.
15:48:32 <gmcharlt> :)
15:49:01 <gmcharlt> more seriously, I think there's a small but real factor that the lag period between prev-RM and next-RM discourages merges to master during that period
15:49:14 <gmcharlt> so I'm also in favor of a shorter tiemframe
15:49:31 <kmlussier> gmcharlt: Shall I give you an action item for the kicking off the process under the shorter timeframe?
15:49:39 <gmcharlt> kmlussier: sure!
15:49:48 <berick> gmcharlt: i have the same concerns re: lag
15:51:16 <kmlussier> #action gmcharlt to send out a call for RM nominations tomorrow, with an election planned for the week of March 27
15:51:54 <kmlussier> Anything else on the RM nomination process?
15:52:25 <kmlussier> Does anyone need any feedback on new features under development or have anything else they want to discuss?
15:52:58 <kmlussier> Going once, going twice...
15:53:08 <kmlussier> #endmeeting