15:04:01 <gmcharlt> #startmeeting Evergreen Development meeting, 7 December 2016 15:04:01 <pinesol_green> Meeting started Wed Dec 7 15:04:01 2016 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:01 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:01 <pinesol_green> The meeting name has been set to 'evergreen_development_meeting__7_december_2016' 15:04:10 <gmcharlt> #info Agenda https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-12-07 15:04:20 <gmcharlt> #topic Introductions 15:04:32 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC 15:04:36 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox's House of Cat and Commit Herding 15:04:46 <abowling> #info abowling = Adam Bowling, Emerald Data Networks 15:04:46 <JBoyer> #info JBoyer is Jason Boyer, Indiana State Library Evergreen Indiana 15:04:50 <jeff> #info jeff == Jeff Godin, Traverse Area District Library (TADL) 15:05:07 <berick> #info berick Bill Erickson King County Library (KCLS) 15:05:11 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College) 15:05:41 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College) 15:07:03 <gmcharlt> OK, moving on; feel free to continue to introduce yourself 15:07:10 <gmcharlt> #topic Action items from last meeting 15:07:30 <gmcharlt> #info gmcharlt did not cut the OpenSRF 2.5-alpha release yet, but is typing release notes AS WE SPEAK 15:07:47 <gmcharlt> #action gmcharlt will release OpenSRF 2.5-alpha today (7 December 2016) 15:08:11 <gmcharlt> the 2.11 release announcement was blogged 15:08:19 <gmcharlt> kmlussier sent out the press release 15:08:27 <gmcharlt> the RM nominations and election took place 15:08:32 <gmcharlt> kmlussier++ 15:09:05 <gmcharlt> and as it's a carry-over 15:09:08 <Bmagic> #info Bmagic = Blake GH, MOBIUS 15:09:33 <gmcharlt> #gmcharlt and Dyrcona to create guidelines on the wiki to determine what is a bug fix vs. new feature. 15:09:33 <gmcharlt> -- in particular, to suggest guidelines for what should be backported 15:09:54 <gmcharlt> so, I think that does it for action items from back in the mists of time 15:09:57 <gmcharlt> so moving on 15:10:10 <gmcharlt> #topic OpenSRF release info 15:10:22 <gmcharlt> #info OpenSRF 2.5 alpha to be cut on 7 December 15:10:43 <gmcharlt> so, with respect to the alpha, there are some things in particular I'd like to request testing for 15:10:49 <gmcharlt> 1. the proxy configurations 15:10:51 <jeff> TZ changes? 15:10:55 <gmcharlt> 2. bundling and chunking 15:10:57 <jeff> er, you're listing. 15:11:04 <gmcharlt> 3. TZ changes 15:11:13 <gmcharlt> and there's a potential decision point for us 15:11:36 <gmcharlt> namely, do we want to consider having use of a proxy be a default recommended configuration? 15:12:29 <gmcharlt> and whether or not we do that, I'm thinking that before 2.5.0, we should make the default websockets port become a configure-time parameter 15:12:32 <gmcharlt> thoughts? 15:12:35 <jeff> are you making a distinction between recommendation and requirement? 15:13:00 <gmcharlt> jeff: I am, I think 15:13:22 <gmcharlt> "requirement" to me suggests that we bite the bullet and have Evergreen users move over to that configuration 15:13:26 <gmcharlt> but... that's a mare's nest 15:13:29 <Dyrcona> #info Dyrcona = Jason Stephenson, C/W MARS 15:13:30 <jeff> +1 to making websockets port be not-hardcoded 15:13:37 <JBoyer> I think in the long run it would be preferable to shave some weight off of the perl modules loaded in apache processes so it's not necessary at all, but that's not going to be done soon. 15:13:43 <jeff> +1 to recommending proxy 15:13:52 <JBoyer> also +1 to build time port settings 15:13:55 <jeff> +1 to recommending proxy for production 15:14:07 <jeff> (clarifying/qualifying my previous +1) 15:14:13 <berick> +1 to moving toward proxy recommendation. i know of at least one bug using the proxy w/ EG, where a redirectmatch sends the ser from /eg/staff to 7443:/eg/staff/ 15:14:31 <berick> i.e. the internal port number leaks 15:14:49 <gmcharlt> whoopsie 15:14:58 <gmcharlt> and that's certainly something to nail down before .0 15:15:01 <berick> so, it might need a little wider use before full blown recommendation 15:15:15 <berick> gmcharlt: to clarify, it's really an EG bug, but yea.. 15:15:41 <gmcharlt> yeah, most of the question of full-blown recommendation would be on EG's end, particular for install documentatation 15:15:50 <gmcharlt> on the plus side, we have time before 2.12 15:16:20 <gmcharlt> any other questions or thoughts on OpenSRF? 15:16:25 <berick> yeah, and fwiw I've been using the osrf proxy for a while now and that's the only issue i've run into 15:16:44 <gmcharlt> cool 15:16:59 <gmcharlt> the haproxy config will require more testing, but it's what I"ll be running 15:17:21 <gmcharlt> ok, 15:17:23 <gmcharlt> moving on 15:17:27 <gmcharlt> #topic Evergreen releases 15:17:36 <bshum> Would it be good to make websockets required, rather than just optional in a future OpenSRF release? 15:17:41 <bshum> oops heh 15:17:49 <dbwells> One other questions related to chunking/bundling, Bmagic a few weeks back hit what appeared to be an incompatibility with that change in EG master. It's probably possible to fix in a backwards compat. way, but regardless, are we assuming OSRF 2.5 will be recommended for EG 2.12+, or do we need it to work with other current releases? 15:18:42 <gmcharlt> it would be a niceness, but not required, that it work with current releases 15:18:51 <gmcharlt> dbwells: do you happen to have a bug # for that? 15:19:16 <dbwells> gmcharlt: I will find or make one and get back to you. 15:19:21 <gmcharlt> but unless something weird happens, I'm assuming that Evergreen 2.12 would require OpenSRF 2.5 15:19:27 <gmcharlt> dbwells++ 15:19:48 <gmcharlt> any other OpenSRF stuff? 15:20:04 <Dyrcona> I'd say if there is a backwards compatibility issue that can't be resolved, then we need to support 2.4 until it is resolved or 2.11 is no longer supported. 15:20:28 <gmcharlt> that strikes me as easy enough 15:20:54 <gmcharlt> #info Evergreen 2.11.1 and 2.10.8 was released on 16 November 2016 15:20:54 <Bmagic> dbwells: could have been xenial support 15:21:53 <gmcharlt> kmlussier: anything you want to say about 2.12 at the moment? 15:22:16 <kmlussier> #info 2.12 schedule is set - http://markmail.org/message/4jmxknraen6k7nqr 15:22:19 <bshum> Bmagic: I was just thinking that if we do decide to keep OpenSRF 2.4 series around instead of going for 2.5, we should reconsider the decision not to backport Xenial support to that 15:22:59 <kmlussier> #info Roadmap entries can be added to the wiki at https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:2.12 15:23:19 <kmlussier> As I mentioned at the hack-a-way, I would like to schedule some web client hacking days to help us get more work done on the browser client. 15:23:54 <kmlussier> I meant to schedule them as soon as I got back, but now a month has flown by. A question I have for the run, is it doable to try to squeeze one in before the holidays or should I plan on a January date? 15:25:06 * gmcharlt is thinking January 15:26:00 <kmlussier> OK, I'll proceed with a January date then. 15:26:14 <kmlussier> Also, I think bug 1642054 is the chunking issue mentioned by dbwells above. 15:26:14 <pinesol_green> Launchpad bug 1642054 in Evergreen "References to chunking need to be renamed to bundling" [High,New] https://launchpad.net/bugs/1642054 15:26:14 <dbwells> gmcharlt: found the bug, #1642054 . kmlussier++ 15:26:23 <dbwells> heh 15:26:25 <kmlussier> dbwells: Jinx! 15:26:49 <gmcharlt> dbwells: kmlussier: thanks 15:27:21 <gmcharlt> and at first blush, I think these can be readily resolved in such a way that 2.10/2.11 can run on top of OpenSRF 2.5.x 15:27:53 <gmcharlt> and for that matter, I'll mark that as a blocker for the OpenSRF 2.5-beta/2.5.0 release 15:28:31 <gmcharlt> kmlussier: anythhing else for the Evergreen release topic? 15:28:51 <kmlussier> Nope 15:28:58 <gmcharlt> #topic Hatch 15:29:08 <berick> that's me 15:29:28 <berick> i think I said it all in the agenda.. basically, would like to get other eyes on the code / behavior 15:29:44 <berick> help me flesh out the dev install docs and make sure we're all still on the same page 15:30:10 <gmcharlt> #info Hatch omnibus bug https://bugs.launchpad.net/evergreen/+bug/1646166 15:30:11 <pinesol_green> Launchpad bug 1646166 in Evergreen "Hatch 2.12 Omnibus" [Undecided,New] - Assigned to Bill Erickson (berick) 15:30:14 <jeff> I'm still quite interested in that. 15:30:21 <jeff> So, I'll volunteer my eyes. 15:30:22 <kmlussier> I can test installing on Linux 15:30:58 <berick> i have one final note to add to the install docs, the final "here's how you actually use it" bit 15:31:01 <gmcharlt> I can take a look at OS X installation 15:31:03 <berick> but that'll just take a sec 15:31:11 <berick> (and I can do that today) 15:31:30 <berick> thanks jeff kmlussier gmcharlt 15:31:40 <berick> holler w/ any problems or confusion 15:31:51 <berick> gmcharlt: as noted, the mac stuff will be very at-your-own-risk at this point 15:31:58 <berick> well.. s/risk/you figure it out/ 15:32:21 <berick> but I have made it work 15:32:34 <gmcharlt> "let's see, should I push that largish button that has an inviting shade of scarlet?" 15:33:04 <berick> always 15:33:19 <gmcharlt> :) 15:33:25 <gmcharlt> anything else for Hatch? 15:33:36 <berick> i think that's it from me 15:34:14 <gmcharlt> on to new business 15:34:19 <gmcharlt> #topic Documenting the release process 15:35:16 <kmlussier> I added that topic to the agenda to update y'all on the status of this, which was discussed at the hack-a-way. 15:35:47 <kmlussier> I am using https://wiki.evergreen-ils.org/doku.php?id=dev:evergreen:release_checklist, which was developed back in the 2.2 days, as a starting point to outline who does what in the release process. 15:36:23 <kmlussier> I think we could also use this page to link to other wiki pages we have with more detailed instructions on how to build a release, how to do release notes, who to send pr to, etc. 15:37:17 <kmlussier> It's just a draft now, but if anyone has feedback, you know where to find me. 15:37:47 <kmlussier> Also, I just wanted to mention there are some roles there, like bug wrangler, where I don't think we have designated people. 15:38:29 <kmlussier> I don't know if we should fold those tasks into other roles or if we should try to get new volunteers to help with some of these tasks. 15:40:37 <kmlussier> But maybe I can flesh that out more with the other folks who volunteered to work on this. 15:40:47 <gmcharlt> gut feeling -- the more humans involved, the more we will need not only roles, but a specific timeframe 15:41:26 <gmcharlt> e.g., something along the lines of D-Day - 3: release notes finalized 15:41:35 <gmcharlt> D-Day - 1: tarballs built 15:41:37 <gmcharlt> and so forth 15:41:45 <kmlussier> Sure, I think that's doable. 15:42:18 <kmlussier> When we talked about this at the hack-a-way, I think we were also saying that it might not be one point person, but a group of known people who could be called upon when help is needed. 15:42:27 <gmcharlt> another suggestion (maybe nitpick) - perhaps the checklist should be put in the order that steps need to take place 15:42:52 <gmcharlt> e.g., since the release notes are included in the tarball, they need to be finalized before the buildmasters can bild 15:43:06 <kmlussier> sure 15:43:37 <gmcharlt> kmlussier: when and how would be the best way to get feedback to you? 15:44:19 <kmlussier> When could be the end of the month? That will give me time to improve it before the next dev meeting. 15:44:45 <kmlussier> How could be in IRC or e-mail. But I won't be around towards the end of the month, so e-mail may work better. 15:45:19 <gmcharlt> open-ils-dev, or to you directly? 15:45:54 <kmlussier> Why don't you give me an action item to post something to open-ils-dev to solicit feedback. Then, more discussion can happen there. 15:46:04 <gmcharlt> I can do that 15:46:23 <gmcharlt> #action kmlussier will post to open-ils-dev soliciting feedback on the release process documentation 15:47:20 <gmcharlt> anything else on this topic? 15:47:24 <kmlussier> nope 15:47:55 <gmcharlt> OK, that takes us to the end of the agenda, but before we end the meeting, is there anything else that somebody woul like to raise for immediate consideration? 15:48:48 <gmcharlt> going once 15:48:55 <gmcharlt> going twice 15:48:56 <gmcharlt> gone 15:49:05 <gmcharlt> now go forth and code and document for great justice! 15:49:08 <gmcharlt> #endmeeting