15:00:37 <gmcharlt> #startmeeting Evergreen Development Meeting, 6 April 2016
15:00:37 <pinesol_green> Meeting started Wed Apr  6 15:00:37 2016 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:37 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:37 <pinesol_green> The meeting name has been set to 'evergreen_development_meeting__6_april_2016'
15:00:45 <gmcharlt> #info Agenda is http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-03-06
15:00:55 <gmcharlt> #topic Introductions
15:01:10 <gmcharlt> #info Galen Charlton, ESI
15:01:20 <phasefx> #info Jason Etheridge, ESI
15:01:24 <jeffdavis> #info Jeff Davis, Sitka
15:01:27 <kmlussier> gmcharlt++
15:01:33 <kmlussier> #info Kathy Lussier, MassLNC
15:01:36 <rhamby> #info Rogan Hamby, ESI
15:01:42 <Dyrcona> #info Jason Stephenson, MVLC
15:01:57 <JBoyer> #info Jason Boyer, ISL
15:02:26 <berick> #info berick Bill Erickson, KCLS
15:02:28 <brahmina> #info Brahmina Burgess, Sitka
15:02:37 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:02:50 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
15:03:08 <jeffdavis> brahmina is new to Sitka, she is replacing Liam who has moved on to another position
15:03:24 <Dyrcona> Welcome, brahmina!
15:03:28 <kmlussier> Welcome brahmina!
15:03:29 <gmcharlt> welcome, brahmina!
15:03:29 <rhamby> Welcome brahmina!
15:03:36 <brahmina> Thanks! :)
15:03:43 <berick> welcome brahmina;  give our regards to Liam
15:03:58 <gmcharlt> #topic OpenSRF release
15:04:11 <gmcharlt> we have some patches queued up for both a 1.5.0 and a 1.4.x release
15:04:27 <gmcharlt> I'll try to cut them before the Evergreen Conference, but may well end up cutting them AT the Evergreen Conference
15:04:39 <gmcharlt> otherwise, not much to say unless folks have questions
15:05:20 <miker> #info miker Mike RYlander, ESI
15:06:00 <gmcharlt> OK, moving on
15:06:07 <gmcharlt> #topic Evergreen release
15:06:33 <gmcharlt> and we had a few releases last month: 2.8.7, 2.9.3, 2.10.0, and 2.10.1
15:06:59 <gmcharlt> and if I'm remembering the discussion correctly, 2.8.x will hit EOL after the release of 2.8.8 this month
15:07:41 <gmcharlt> any questions
15:07:43 <gmcharlt> ?
15:08:08 <kmlussier> Are the next point releases still happening as scheduled on hackfest day?
15:08:13 <kmlussier> Or should they be rescheduled?
15:08:39 <JBoyer> That seems like a lot happening on the same day.
15:08:39 <Dyrcona> I'm OK with doing 2.9.4 at the hackfest.
15:08:47 <gmcharlt> and ditto for 2.10.2
15:09:41 <Dyrcona> berick?
15:10:12 <berick> works for me
15:10:46 <gmcharlt> OK, moving on then
15:10:52 <gmcharlt> #topic Conference hackfest ideas page
15:11:00 <gmcharlt> #link http://wiki.evergreen-ils.org/doku.php?id=dev:hackfest:eg2016
15:11:23 <gmcharlt> please add your ideas, or else we will ALL be perching on berick's shoulder as he works on the Angular 1.5 patches
15:11:25 <gmcharlt> ;)
15:11:39 <berick> sounds like a super hackfest ;)
15:12:24 <gmcharlt> moving on
15:12:26 <gmcharlt> #topic Call for Release Manager for 2.11
15:12:42 <gmcharlt> #info RM nominations and self-nominations accepted through 15 April
15:12:55 <gmcharlt> #info Vote to be held in #evergreen week of 18 April
15:13:22 <gmcharlt> questions?
15:13:46 <jeffdavis> I'm just curious to see who volunteers, which isn't really a question :)
15:13:58 * Dyrcona nominates jeffdavis.
15:13:59 <kmlussier> Feel free to speak up now! :)
15:14:19 * jeffdavis shakes fist at Dyrcona
15:14:19 <krvmga> lol
15:14:52 <Dyrcona> :)
15:15:00 <gmcharlt> we're calling for nominations...not inescapable mandates! ;)
15:15:10 <gmcharlt> anyway, moving on
15:15:15 <gmcharlt> #topic Follow-up on search discussion
15:15:36 <kmlussier> I don't have much on that. I had hoped to be done with my work by meeting time. :)
15:16:25 <kmlussier> But I'll be sharing more info on the dev list by the end of the week. As you know, we did some focus group discussions in IRC to get feedback on where the community wants to see search going.
15:16:47 <kmlussier> I'm compiling that information now and will be sharing it with the community to make sure I didn't misunderstand anything.
15:17:25 <kmlussier> My next step was to put together a survey based on those discussion to help us prioritize the ideas that were raised. I'll share it with all of you first for feedback before sending it out to the larger community.
15:17:49 <kmlussier> Maybe we can discuss it further at the hackfest to maybe identify some next steps.
15:17:54 <kmlussier> That's all I have for now.
15:18:49 <gmcharlt> thanks, kmlussier
15:19:01 <gmcharlt> #topic npm is failing to install Node.js packages on Ubuntu 14.04
15:19:28 <gmcharlt> er, is there a bug filed for this?
15:19:33 <Dyrcona> As previously mentioned in IRC, I've been failing to get the web staff client working on Ubuntu 14.04 this week.
15:19:55 <Dyrcona> Not a Launchpad bug, but that could be an action item for me if you like.
15:19:59 <gmcharlt> please
15:20:33 <Dyrcona> The problems appear to be related to this closed github issue.
15:20:37 <Dyrcona> #link : https://github.com/npm/npm/issues/12196#issuecomment-205855393
15:20:58 <Dyrcona> Can I action item myself, or does the chair have to do that?
15:21:04 <gmcharlt> #action Dyrconra to write up bug report for nodejs installation item on Ubuntu 14.04
15:21:09 <gmcharlt> er
15:21:15 <Dyrcona> Close enough. :)
15:21:21 <gmcharlt> heh
15:21:56 <Dyrcona> I'll put this in the bug report, but my idea is to update the README to explain how to install Node.js from source, and remove the prerequisites from Makefile.install.
15:22:30 <gmcharlt> https://github.com/nodesource/distributions also looks interesting
15:22:32 <Dyrcona> So that's all I've got for now.
15:22:48 <gmcharlt> #topic Change supported Ubuntu distros
15:23:03 <gmcharlt> i.e., propose to drop supported for 12.04 and add it for 16.04
15:23:43 <gmcharlt> I see we have bug 1551084 already
15:23:44 <pinesol_green> Launchpad bug 1551084 in Evergreen "Add Evergreen support for Ubuntu 16.04 Xenial Xerus" [Wishlist,Triaged] https://launchpad.net/bugs/1551084
15:23:44 <bshum> Historically, Ubuntu support has always been current LTS and previous.  So when 16.04 arrives on the scenes, 12.04 should go away.  Assuming 16.04 isn't going to completely upend everything...
15:24:05 <bshum> https://bugs.launchpad.net/opensrf/+bug/1551090 for OpenSRF too
15:24:05 <pinesol_green> Launchpad bug 1551090 in OpenSRF "Add OpenSRF support for Ubuntu 16.04 Xenial Xerus" [Wishlist,Triaged]
15:24:31 <Dyrcona> Yeah, so I'm volunteering to work on those branches between now and the conference.
15:24:44 <gmcharlt> cool
15:25:05 <Dyrcona> 16.04 release is scheduled for 4/21, day two (one?) of the confernce.
15:25:29 <gmcharlt> #action Dyrcona will work on Xenial Xerus Evergreen and OpenSRF support between now and the EG conference
15:25:41 <Dyrcona> I plan to make the changes in master only, unless the consensus is to backport.
15:25:55 <JBoyer> Seems reasonable.
15:26:17 <bshum> I'd like to suggest also that we only target this change for Ubuntu towards the next major series for each.  Backporting to older versions may not be immediately necessary since 12.04 will still be "supported" till 2017 (through the end of planned life for 2.9 and 2.10 too, probably)
15:26:35 <bshum> What Dyrcona said :)
15:26:42 <gmcharlt> backporting Xenial support to rel_2_10 would be a niceness
15:26:54 <gmcharlt> though I don't care muchly either way
15:27:08 <gmcharlt> as far as 12.04 goes, one thing to mention is that it ships Pg 9.1 by default
15:27:23 <Dyrcona> Right and that leads into a later topic. :)
15:27:54 <gmcharlt> anything else to say about Ubuntu?
15:28:08 <Dyrcona> Not at the moment.
15:28:25 <gmcharlt> #topic Dropping Debian Squeeze support
15:28:32 <gmcharlt> #link https://bugs.launchpad.net/evergreen/+bug/1559121
15:28:33 <pinesol_green> Launchpad bug 1559121 in OpenSRF 2.5 "Drop Debian Squeeze support" [Medium,New]
15:28:46 <bshum> +1
15:29:53 <Dyrcona> what bshum said. :)
15:32:04 <gmcharlt> #info We are all agreed that nobody expect the Spanish Inquisition!!! (er, that Debian Squeeze support is to be dropped)
15:32:18 <gmcharlt> #topic Minimum Pg version to support
15:32:37 <gmcharlt> #info Pg 9.1 support is deprecated as of EG 2.10.x, and will be removed in 2.11.0
15:32:56 <gmcharlt> so, that leaves the question of what minimum Pg version we wish to require
15:33:31 <miker> 9.2 support ends slightly before the EOL for 2.11
15:33:41 <miker> I think
15:34:12 <miker> (just for a data point)
15:34:14 <Dyrcona> 9.3 ships with the at the moment current supported distros.
15:34:22 <Dyrcona> another data point.
15:34:39 <miker> 9.6 it is, then! ;)
15:34:43 <jeffdavis> Is there any reason not to move to 9.3?
15:34:51 <Dyrcona> :)
15:35:13 * Dyrcona just hopes it works on 9.5 for xenial.
15:35:16 <bshum> Doesn't Jessie install on PG 9.4 ?
15:35:26 <miker> jeffdavis: no, and that would be my  preferred minimum
15:35:42 <gmcharlt> bshum: jessie ships 9.4
15:35:46 <Dyrcona> Yeah, I'd prefer 9.3 also.
15:35:54 <bshum> gmcharlt: Gotcha, right.
15:35:58 <miker> prefer 9.3 to 9.2, I mean
15:36:20 <JBoyer> Is 9.2 the default install on any supported OS? I don't know much about the redhat related distros.
15:36:30 <bshum> It wasn't as far as I could remember.
15:36:30 <JBoyer> (Also +1 to 9.3 )
15:36:49 <kmlussier> +1 to 9.3
15:37:50 <gmcharlt> JBoyer: I don't know what RHEL-likes ship by default, but they do have access to http://yum.postgresql.org/
15:37:51 <miker> related to absolute minimums, I have another "supported PG question" ... if/when features of a more modern PG allow us to do Great Things(tm), what is the general opinion on saying "for 3.0 (say) you have to start with PG 9.7 or later" and skipping the ability to use older PGs?
15:38:23 <miker> (and, as a cousin to yum.postgresql.org, there's the PGDG apt repo)
15:38:28 <jeff> miker: Great Things are worth ensuring recent PostgreSQL version, IMO.
15:38:53 <JBoyer> gmcharlt, miker: good points. Certainly beats git clone...
15:39:02 <miker> jeff: that was the rule back in the wild west days, but I don't think we've codified that in the new order
15:39:15 <kmlussier> I'm in favor of high minimums to do great things, especially if supporting lower versions is holding as back, but I'm also not a sys admin who needs to worry about keeping up to date.
15:39:30 <Dyrcona> I think it is OK to do that for future releases, as long as there is no attempt to backport the new features so enabled.
15:39:36 <kmlussier> holding *us* back.
15:39:38 <miker> kmlussier: fwiw, it's already holding us back to a degree ... :(
15:39:44 <gmcharlt> miker: to toss out a suggested rule of thumb: when we want to bump up minimum required Pg, do so soon enough so that we can announce a deprecation the major release before we want to jump to a newer Pg
15:39:47 <kmlussier> miker: yeah
15:39:49 <bshum> "New is always better"?
15:40:26 <miker> *after the new special tweaks have been identified
15:41:12 <miker> gmcharlt: my thought was "only make major jumps when the first number changes, or PG drops support near a second-number release"
15:41:33 <gmcharlt> and given some of Pg's brown bags the past couple years... there is reason not to be too quick to jump
15:41:35 <miker> that sentence may not have enough context...
15:41:51 <Dyrcona> miker: Wasn't that one of the old rules for versioning?
15:42:45 <Dyrcona> "Bump the major version if a Pg version requirement goes up?"
15:42:49 <miker> Dyrcona: indeed it was. maybe we need to just go through them and make sure they either make sense and are officially "adopted" or cut them
15:43:11 <jeffdavis> Is this something we need a general rule about, or can/should it be something decided on a case by case basis?
15:43:17 <Dyrcona> Probably cut them at this point.
15:43:43 <kmlussier> Are those rules posted somewhere?
15:43:49 <miker> jeffdavis: well, it helps with planning big changes ... where they'll land
15:44:02 <gmcharlt> I'm inclined to consider it on a case-by-base basis as new Pg features warrant bumping up; my main other concern is just allowing adequate notice to EG sysadmins
15:44:11 <miker> but it doesn't have to be The Law, things like that can be "official guidelines"
15:45:14 <kmlussier> Yes, so if we decided to go with 9.3 as a minimum for 2.11, the notice should probably go out now to give adequate notice.
15:45:17 <gmcharlt> I'm much less concerned about where EG version numbers fit into the schema (beyond the principle that maintenance releases should never have the required dependencies change underneath them absent extreme provocation)
15:45:40 <gmcharlt> to step back a bit
15:45:55 <gmcharlt> I think we have a consensus to require Pg 9.3 as the minimum for Evergreen 2.11
15:45:59 * Dyrcona pretty much agrees with gmcharlt and miker.
15:46:07 <bshum> PG 9.3 buys us a year to decide what happens next time 'round
15:46:12 <gmcharlt> any disagreement with that (i.e., somebody who wants to aim for 9.4 or 9.5)?
15:46:15 <bshum> Well more than a year anyways
15:46:38 <bshum> Plus I feel like there are already lots of us on PG 9.3 or better
15:46:45 <bshum> So it should be "well tested"
15:46:55 <miker> 9.3 FTW
15:47:09 <gmcharlt> going once...
15:47:24 <jeffdavis> FWIW, looks like CentOS 6 (EOL 2020) comes with PG8.4, and CentOS 7 (EOL 2024) comes with PG9.2; not sure if major PG version advances happen in minor CentOS releases
15:47:36 <jeffdavis> that's based on a quick look, we don't use CentOS
15:47:45 <gmcharlt> going twice...
15:47:50 <jeffdavis> I don't think it's worth maintaining old PG versions for that long of a support cycle though, so +1 to 9.3
15:47:56 <miker> berick: you're using PGDG, yes?
15:48:02 <Dyrcona> jeffdavis: And that's pretty much why we discourage the use of CenOS for Evergreen.
15:48:05 <miker> oh, you're off RH, nm
15:48:31 <dbs> Most PostgreSQL people discourage the use of RedHat/CentOS packages anywya
15:48:44 <berick> miker: not sure, actually.  maybe source.  either way +1 to 9.3
15:48:56 <gmcharlt> dbs: in favor of source or yum.pg.org?
15:49:04 <dbs> yum
15:49:16 <gmcharlt> OK
15:49:28 <gmcharlt> so, I think I'll call it
15:49:44 <gmcharlt> #agreed PostgreSQL 9.3 will be the minimum required version for Evergreen 2.11
15:49:45 <berick> (we're upgrading to 2.7 this weekend.  2.11 is a distant idea ATM).
15:49:58 <gmcharlt> #action gmcharlt will send an email to the mailing lists announcing the Pg dependency change
15:50:40 <kmlussier> berick: Wow!
15:51:21 <berick> kmlussier: gettin' there...
15:52:10 <dbwells> berick: from where you started, 2.7 sounds like a pretty major accomplishment, good job!
15:53:11 <berick> thanks, dbwells
15:53:22 <Dyrcona> Did we talk about sqitch? Do we need to?
15:53:50 <kmlussier> It was an outstanding action item from the last meeting.
15:54:10 <berick> the sqitch branch is ready for wider testing.
15:54:24 <gmcharlt> I can make some time between now and the EG conference to test
15:54:30 <berick> if nothing else, it would be great if someone else got a feel for how it works
15:54:40 <Dyrcona> I should see what it's about, but I have enough action items already. :)
15:54:49 <berick> so I'm not stabbing too long in the dark.  i only have my own experiences
15:55:01 <gmcharlt> but a question, berick: how much of a pain for you if we merge pull requests that touch the schema?
15:55:13 <gmcharlt> "will it be"
15:55:53 <berick> gmcharlt: I have to cross-port each Pg/upgrade/* file.  Not a huge pain, but each change does cause work
15:56:12 <gmcharlt> berick: shall we set the EG conference as a date for the merge?
15:56:30 <miker> gmcharlt: have we decided it's a done deal?
15:56:47 <berick> miker: that's kind of my question too
15:56:53 <gmcharlt> well, that would depend on testing, ultimately
15:57:00 <berick> gmcharlt: right
15:57:39 <gmcharlt> I think to rephrase: assuming that we end up /agreeing/ to run with sqitch, the conference would be a good time to make the switch
15:57:48 <jeff> we usually have a dev meeting at the conf -- if enough people have tested and gotten a feel for squitch in general we could make a merge/no-merge call then?
15:58:31 <miker> I do a good bit of db mangling ... and I won't have time to really dig in before the conf. I'm certainly not The Decider, but I'd like to hear the pitch (I know I missed one at the hack-a-way ... no way I could have made it there, though)
15:58:52 <berick> i'm happy to review, discuss, etc at the conf.
15:58:57 <bshum> It's a cool pitch.  I like the concept, just have to see it in practice more.
15:59:07 <bshum> Well, work with it in practice I mean
15:59:11 <kmlussier> Should we hold off on merging code with schema changes until after the conference then?
15:59:31 <berick> kmlussier: i'd vote no on that.  i'd rather not disrupt the flow
16:00:11 <jeff> that's a long time to go without schema changes (though, ever-shorter as the conf nears). since berick sounds okay with cross-porting... :-)
16:00:44 <Dyrcona> Well, I'd like to learn more if means changing how upgrade scripts are written or if there are extra steps required.
16:00:47 <gmcharlt> kmlussier: berick: agreed; we've got some stuff in the queue that I'd hate to see wait to be merged indefinteily
16:01:40 <berick> I'm OK x-porting if there is motion toward a decision either way
16:02:04 <jeff> berick: mind being verbose and calling attention to the next cross-port you do, for purposes of practical example?
16:02:45 <berick> jeff: sure.  I also have such an example in the wiki page of a crossport
16:03:15 <jeff> heh. i was just going to ask/look... sorry. :-)
16:03:46 <bshum> #info bshum = Ben Shum
16:03:48 <bshum> (before the end!)
16:04:06 <Dyrcona> heh
16:04:44 <Bmagic> #info Bmagic = Blake GH, MOBIUS
16:05:51 <gmcharlt> OK, I got distracted there for a moment
16:05:55 <gmcharlt> but I think we can summarize with
16:06:26 <gmcharlt> #action Various folks will do more detailed evaluation/testing of Sqitch prior to the EG conference, with an eye towards having more informed discussions
16:07:15 <berick> cool, thanks everyone
16:08:39 <DPearl> #info DPearl = Dan Pearl, C/W MARS
16:09:14 <dbs> #info dbs = Dan Scott, Laurentian University
16:09:22 <dbs> Last!
16:09:49 <kmlussier> dbs: Now I'm so tempted to introduce myself again so that I can be last. ;)
16:10:21 <kmlussier> Going back to one of our earlier agenda items (sorry, I was only half paying attention at the time), I'll send out a message to the dev list with a link to the hackfest ideas page so that people who are not here know about it.
16:11:17 <brahmina> dbs: are you Clayton Scott's cousin?
16:13:20 <berick> hopefully, dbs is Bon Scott's cousin
16:13:39 <dbs> Hells Bells!
16:14:13 <kmlussier> heh
16:14:38 <jlitrell> #info jlitrell = Jake Litrell, MassLNC
16:14:39 <gmcharlt> OK
16:14:41 <jlitrell> nyaah
16:14:42 <gmcharlt> #endmeeting