13:06:24 <kmlussier> #startmeeting 2013-10-15 - October Developers meeting
13:06:24 <pinesol_green> Meeting started Tue Oct 15 13:06:24 2013 US/Eastern.  The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:06:24 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:06:24 <pinesol_green> The meeting name has been set to '2013_10_15___october_developers_meeting'
13:06:42 <berick> thanks kmlussier
13:07:08 <berick> #info berick Bill Erickson, ESI
13:07:17 <csharp> #info csharp Chris Sharp, GPLS
13:07:23 <kmlussier> #info Agenda is at  http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2013-10-15
13:07:24 * eeevil watches everone but kmlussier take a step back
13:07:33 <jeff> #info jeff Jeff Godin, TADL
13:07:34 <phasefx> #info phasefx Jason Etheridge, ESI
13:07:37 <eeevil> #info eeevil Mike Rylander, ESI
13:07:42 <senator> #info senator Lebbeous Fogle-Weekley, ESI
13:07:56 <kmlussier> I'm terrible at running these meetings. :)
13:07:59 <dbwells> #info dbwells Dan Wells, Hekman Library (Calvin College)
13:08:00 <ldwhalen> #info ldwhalen Liam Whalen, BC Libraries Coop
13:08:11 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
13:08:16 <remingtron> #info remingtron Remington Steed, Hekman Library (Calvin College)
13:08:21 <RoganH> #info RoganH, SCLENDS
13:08:38 <bshum> #info bshum = Ben Shum, Bibliomation
13:08:47 * bshum hates the 3 hour time difference
13:09:08 <kmlussier> #topic Action Items from Last Meeting
13:09:35 <kmlussier> #info [extra old action item from summer doldrums] Start on the 2.6 development road map page
13:09:41 <kmlussier> There's no name assigned to that action item.
13:10:07 <berick> I can do that
13:10:30 <kmlussier> Looks like we have a start already http://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:2.6
13:10:33 * berick checks to make sure no one already did.
13:10:35 <berick> heh
13:10:47 * berick bows
13:10:56 <kmlussier> #link http://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:2.6
13:11:27 <kmlussier> #info [extra old action item ” ” ”] bshum to summarize bug tracking based on feedback from developers
13:11:53 <bshum> I think I'm going to generally loop that into a larger discussion about how much we all hate LP
13:12:10 <bshum> But specifically, no, I have yet to complete a better writeup of bug procedures.
13:12:43 <bshum> I do thank dbwells and remingtron for handling most of the bug shifting during this 2.5 release cycle though.
13:12:47 <kmlussier> Should we be kicking off on a discussion for replacing LP?
13:13:08 <Bmagic|2> #info Bmagic = Blake GH, MOBIUS
13:13:42 * kmlussier eyes bug 1235642
13:13:43 <pinesol_green> Launchpad bug 1235642 in Evergreen "Launchpad Too Cumbersome" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1235642
13:16:10 <bshum> Yes, I think that a place to start is probably to get some more discussion going, but I'm not entirely sure what alternatives are best in this case (or who would be able to help contribute to setting up something more distinct)
13:16:26 <bshum> I did do some minor investigation during the last conference, but those didn't get too far.
13:16:31 <dbwells> I think LP is serviceable, and it would be a big effort to move to something else.  I am not opposed to it, but I don't think I could contribute to the effort at this point.
13:16:51 <berick> might be good to start with specifics.  that LP entry is pretty slim ;)
13:17:19 <kmlussier> bshum: Would you be willing to kick off the discussion? Or should I volunteer Dyrcona for it since he's not here? :)
13:18:09 <bshum> kmlussier: I think I agree with dbwells that we haven't shown enough unhappiness with the existing approach to actually put time towards coming up with something new.
13:18:14 <csharp> dbwells: +1
13:18:43 <csharp> however, if the community wants, GPLS could set up a server for experimentation
13:19:04 <kmlussier> OK, so then do you want to defer your action item to summarize bug tracking to the next meeting?
13:19:14 <kmlussier> bshum ^ ^
13:19:16 <bshum> kmlussier: Yes.
13:19:31 <kmlussier> #action bshum to summarize bug tracking based on feedback from developers
13:19:41 <bshum> And Dyrcona can put some thoughts towards that bug ticket, since he helped start it :)
13:19:55 <kmlussier> #info [extra old action item ” ” ”] kmlussier to raise bug squashing day to the lists for further discussion/feedback
13:20:32 <kmlussier> #info kmlussier posted message to the dev list today http://georgialibraries.markmail.org/thread/22six3nkgbhr3f3t
13:21:19 <kmlussier> If anyone has anything to contribute to that discussion, feel free to send it to the list.
13:21:40 <kmlussier> #info gmcharlt to release opensrf 2.2.1 soon(?) post-vacation
13:21:57 <gmcharlt> #info gmcharlt to release 2.2.1 this week
13:22:09 <kmlussier> gmcharlt++
13:22:20 <gmcharlt> (and KohaCon as a vacation for Koha's release manager?  you jest, surely! ;) )
13:22:38 <kmlussier> #info csharp to test 2.4.2 rc so we can officialize it
13:22:42 <eeevil> gmcharlt: this includes the new opensrf controller script from berick, yes?
13:22:52 <bshum> Related to opensrf, is there anything in master that lends cutting of a 2.3.0?
13:22:56 <eeevil> kmlussier: that happened, 2.4.3 is waiting in the wings
13:22:59 <bshum> Like the control stuff
13:23:17 <gmcharlt> eeevil: that's actually something to decide, I suppose -- do we want it as 2.2.1, or branch off and release a 2.3.0 as well?
13:23:46 <eeevil> and, like berick, I'm not going to worry about a 2.4.4 until there's a bigger pile of fixes, or next month, whichever comes first
13:24:07 * gmcharlt has no strong opinion one way or the other, but the new control scripts might represent a large-enough change
13:24:14 <berick> eeevil: btw, i copied your 2.4.3 files into place as well (though i'm getting ahead of myself)
13:24:31 <dbwells> gmcharlt: we upgraded to OpenSRF 2.2.1 (well, master) on production this past Friday.  So far, so good :)
13:24:32 * berick also has no strong opinion re: opensrf version
13:24:38 <eeevil> gmcharlt: I'm for 2.3.0. enough user-visible changes, IMO
13:24:49 <bshum> I agree, +1 for 2.3.0
13:25:18 <bshum> (we've been running that in production since our early September upgrade, so I feel reasonably happy about the state of opensrf master)
13:26:00 <dbwells> +1 to moving to 2.3.0 on account of the control script changes
13:26:03 <bshum> I suppose we just need to update the README in Evergreen to use the new control commands.
13:26:03 <gmcharlt> #info gmcharlt will cut both  OpenSRF 2.2.1 (to include the multipart fix) and OpenSRF 2.3.0 (to include the new signal-handling and control script stuff) this week
13:26:07 <jeff> +1 to 2.3.0, but if the multipart request changes haven't made it to a point release of 2.2.x, that might be a good thing to backport/release.
13:26:17 <gmcharlt> jeff: too slow! ;)
13:26:21 <jeff> heh
13:26:35 <eeevil> gmcharlt++
13:27:02 <csharp> so which opensrf version will be paired with EG 2.5?
13:27:18 * gmcharlt suggests 2.3.0
13:27:18 <senator> camembert
13:27:20 <eeevil> csharp: "latest" :) ... 2.2+
13:27:26 <csharp> ok
13:27:33 <csharp> senator++
13:27:33 <gmcharlt> as recommended, with note that 2.2.1 is compatible
13:27:41 <eeevil> (yes, 2.3+ recommended)
13:28:14 <kmlussier> #info 2.3.0 will be recommended to run with EG 2.5, but 2.2.1 will be compatible as well.
13:28:28 <kmlussier> Moving on to the next action item...
13:28:48 <kmlussier> #info senator to find old incomplete action items to move forward (with help from the channel in making sure I get the right ones) - Done!
13:29:11 <kmlussier> senator++ # Thanks for all the action items!
13:29:32 <kmlussier> #info eeevil to commit a techref doc explaining how to build pgTAP test
13:31:04 <eeevil> kmlussier: I have not done that yet. it's on my gtasks list, though!
13:31:23 <eeevil> nor have I had time to do the next one
13:31:39 <kmlussier> OK, I'll add both as action items for next time then.
13:31:51 <kmlussier> #action eeevil to commit a techref doc explaining how to build pgTAP test
13:32:03 <eeevil> thanks
13:32:08 <kmlussier> #action o publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan.
13:32:37 <kmlussier> That's it for action items, and I think we've also covered OpenSRF Release Info?
13:33:16 <kmlussier> #topic Evergreen release info
13:33:33 <kmlussier> dbwells: Should we start with 2.5?
13:34:17 <dbwells> Sure.  After a couple brief rounds of testing and bug squashing, RC1 is uploaded to the usual.
13:34:31 <dbwells> usual place, that is
13:35:10 <dbwells> Been having fun working out the release notes, but that is done as well, and will be uploaded shortly.
13:36:20 <kmlussier> #info 2.5 RC1 is uploaded. Release notes will be uploaded shortly.
13:36:32 <kmlussier> dbwells: Anything else to add?
13:36:41 <dbwells> Since we are a day late already for the delayed version of 2.5 final, I am not sure where to pin down the timeline, but I am pretty confident things we'll get there soon.
13:37:24 <dbwells> It's really all about more testing at this point, so maybe RC will inspire some folks.
13:37:52 <dbwells> That's about it, unless folks have questions I might be able answer.
13:37:52 <kmlussier> How much time do we usually allow for testing between RC1 and final?
13:38:21 * csharp is testing beta1, but will upgrade to RC
13:38:32 <gmcharlt> dbwells: apologies if it's already been mentioned, but I'd like to take this opportunity to mention the fixes for bug 1086458
13:38:33 <pinesol_green> Launchpad bug 1086458 in Evergreen 2.4 "Staff client memory leaks in 2.3 and later" (affected: 11, heat: 76) [High,Confirmed] https://launchpad.net/bugs/1086458
13:39:01 <gmcharlt> whether or not it's a candidate for inclusion in 2.5.0, I'm pretty sure lots of folks will be very happy if it makes it in by 2.5.1
13:39:54 <dbwells> gmcharlt: I haven't looked at it, but I certainly will.
13:40:38 <kmlussier> I think a lot of people would love to see those patches in sooner rather than later. I'm not sure how to approach testing, though.
13:41:27 <csharp> kmlussier: our approach will probably be a due diligence approach on a test server to make sure nothing breaks, then move to production as soon as we're satisfied
13:41:51 <dbwells> gmcharlt: It doesn't look too bad, and if there are no objections, I can pull back RC1 and cram it in there.  No formal announcements have been made yet.
13:41:52 <csharp> seems like it's too difficult to simulate in a test environment
13:41:52 <kmlussier> csharp++
13:42:17 <csharp> dbwells: +1 # fwiw
13:42:33 <eeevil> dbwells: I know it's a pain, having just gone through packaging, but I'm +1 to that
13:43:03 <gmcharlt> dbwells: thanks -- but also, TIA to anybody who tests it
13:43:46 <kmlussier> Is everyone in agreement to include the memory leak patches in RC1 then?
13:43:54 * gmcharlt will search for a suitable libation whose name encodes the concept of "at the last minute" for delivery next time I see you ;)
13:44:06 <dbwells> I would also appreciate a test/sign-off/push to master on that branch by anyone else who can take a look.
13:44:15 <gmcharlt> +1
13:45:08 * dbwells will test what he can of it, but RC1 will be out today, or BUST
13:45:48 <csharp> dbwells++
13:46:22 <kmlussier> #agree dbwells will pull back RC1 and incorporate memory leak patches. Sign-off from other testers will be appreciated.
13:46:31 <kmlussier> Any other questions for dbwells?
13:46:56 <kmlussier> eeevil / berick: Is there anything to report on 2.3/2.4 releases other than the fact that you will be skipping this month's point release?
13:47:23 <berick> just need a volunteer from the web team (a Webster?) to update the downloads page
13:47:31 <csharp> ha!
13:47:36 <csharp> webster++
13:47:38 * berick has nothing else to report on releases
13:48:07 <kmlussier> bshum / moodaepo: Are  either of you available to update the downloads page?
13:48:20 <moodaepo> kmlussier: available
13:48:23 * dbwells almost called berick an acq-olyte yesterday (sorry)
13:48:25 <bshum> kmlussier: I'd prefer to ask someone else to do it.  I'm not a fan of my connection right now.
13:48:30 <csharp> dbwells++
13:48:35 <kmlussier> moodaepo++
13:48:36 <moodaepo> bshum: go back to your poker chips
13:48:40 <moodaepo> :)
13:48:46 <csharp> puns++ :-D
13:48:59 <kmlussier> :)
13:49:00 <sylvar> berick: http://jsfiddle.net/vojtajina/js64b/14/ would make https://demo.evergreencatalog.com/ng-staff/circ/patron/search more awesome (for sorting by date of birth)
13:49:24 <kmlussier> #topic Update on OmniTI Performance Work
13:49:31 <kmlussier> I'll make this quick.
13:49:45 <kmlussier> #info OmniTI began its performance evaluation for Evergreen last month. As most of you have seen, depesz has been looking at the longest-running queries from the C/W MARS server and finding ways to optimize them.
13:50:01 <csharp> depesz++
13:50:05 <kmlussier> #info They will be taking a different approach to the staff client evaluation than originally planned. With the consensus last month to move away from XULRunner and towards a web-based client, it didn't make sense to evaluate the viability of continuing with XULRunner.
13:50:23 <eeevil> depesz++ indeed
13:50:29 <kmlussier> #info Instead, jsime has been looking at the way the client is communicating with the backend to determine if there are ways this communication can be optimized when moving to a web-based client.
13:51:12 <kmlussier> That's all I have to report at the moment, but I just wanted to keep everyone in the loop on what has been happening. I believe jsime is also available if anyone has any questions.
13:51:23 <csharp> kmlussier++
13:51:29 <kmlussier> Or, conversely, if jsime has any questions for the devs. :)
13:52:09 <jsime> just to toss in real quick that the main issue has so far been that parts of the staff client don't seem to always be taking advantage of features that allow grabbing the full depth of a particular object
13:52:28 <jsime> e.g. a patron search which could use the flesh feature to grab both the search results' list of patrons and those patrons' details
13:52:47 <jsime> instead of getting the list of patrons, then iterating through it to get each of their details in turn
13:56:19 <kmlussier> I think one thing we were thinking we might do with that information is include it as part of some kind of best practices for building a new web client. Or maybe there is a better way to share that information as we proceed with the analysis?
13:56:24 <phasefx> jsime: just want to make sure you've seen this: http://wiki.evergreen-ils.org/doku.php?id=dev:testing:performance_issues
13:57:22 <jsime> phasefx: thanks for the link - berick's notes under General Improvement are spot on for that
13:58:10 <kmlussier> OK, we're running short on time. I'm going to move on to the next agenda item.
13:58:19 <kmlussier> #topic Discuss freezing of master during beta/RC phase
13:59:38 <berick> yeah, i was asking about that.  thanks for added that.. dbwells?
13:59:42 <dbwells> This came up a few days ago, and berick suggested we discuss it at the next dev meeting, so I threw it on there.
13:59:48 <berick> my main concern was that stuff would accidentally seep into the beta/RC's
14:00:03 <berick> but that can probably be avoided with consensus on the plan, communication, etc.
14:00:23 <gmcharlt> I see two parts of it
14:00:27 <eeevil> fwiw, I'm in favor of a voluntary freeze by committer, not a branch. reason being, it avoids defocusing committer effort on bugs (though there's not much we can do to REfocus volunteers' time)
14:00:35 <gmcharlt> freeze 'master' for new features to encourage folks to work on release-critical bugs
14:00:51 <gmcharlt> or, freeze master to avoid stuff slipping in by accident
14:01:01 <gmcharlt> the later could be addressed just by branch rel_2_5
14:01:04 <gmcharlt> *branching
14:01:33 <eeevil> the reason I don't like branching is that it increases the workload for the new-version RM
14:01:54 <eeevil> which is (I think dbwells and berick will agree) already pretty high
14:02:08 <dbwells> yes
14:03:23 <berick> indeed.  so, it seems like everyone's in agreement in general.  i'm also fine w/ the honor system
14:04:20 <berick> so, no version branch until x.x.0 is tagged?
14:05:03 <dbwells> If its ever an issue, accidental or otherwise, I think whoever is RM would notice and talking with the committer an reverting if needed wouldn't be so bad.
14:06:03 <eeevil> +1
14:06:13 <dbwells> +1
14:06:14 <berick> +1
14:06:52 <kmlussier> #agree There will be no version branch until x.x.0 is tagged. There will be a feature freeze for master between beta and x.x.0.
14:06:56 <kmlussier> Did I get that right?
14:07:08 <berick> kmlussier++
14:07:26 <kmlussier> OK, anything else for this meeting before we wrap up?
14:07:28 <dbwells> kmlussier: I imagine the bot would whine if you didn't :)
14:07:53 <kmlussier> :)
14:08:06 <kmlussier> #endmeeting