13:06:24 #startmeeting 2013-10-15 - October Developers meeting 13:06:24 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:06:24 The meeting name has been set to '2013_10_15___october_developers_meeting' 13:06:42 thanks kmlussier 13:07:08 #info berick Bill Erickson, ESI 13:07:17 #info csharp Chris Sharp, GPLS 13:07:23 #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 #info jeff Jeff Godin, TADL 13:07:34 #info phasefx Jason Etheridge, ESI 13:07:37 #info eeevil Mike Rylander, ESI 13:07:42 #info senator Lebbeous Fogle-Weekley, ESI 13:07:56 I'm terrible at running these meetings. :) 13:07:59 #info dbwells Dan Wells, Hekman Library (Calvin College) 13:08:00 #info ldwhalen Liam Whalen, BC Libraries Coop 13:08:11 #info kmlussier is Kathy Lussier, MassLNC 13:08:16 #info remingtron Remington Steed, Hekman Library (Calvin College) 13:08:21 #info RoganH, SCLENDS 13:08:38 #info bshum = Ben Shum, Bibliomation 13:08:47 * bshum hates the 3 hour time difference 13:09:08 #topic Action Items from Last Meeting 13:09:35 #info [extra old action item from summer doldrums] Start on the 2.6 development road map page 13:09:41 There's no name assigned to that action item. 13:10:07 I can do that 13:10:30 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 heh 13:10:47 * berick bows 13:10:56 #link http://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:2.6 13:11:27 #info [extra old action item ” ” ”] bshum to summarize bug tracking based on feedback from developers 13:11:53 I think I'm going to generally loop that into a larger discussion about how much we all hate LP 13:12:10 But specifically, no, I have yet to complete a better writeup of bug procedures. 13:12:43 I do thank dbwells and remingtron for handling most of the bug shifting during this 2.5 release cycle though. 13:12:47 Should we be kicking off on a discussion for replacing LP? 13:13:08 #info Bmagic = Blake GH, MOBIUS 13:13:42 * kmlussier eyes bug 1235642 13:13:43 Launchpad bug 1235642 in Evergreen "Launchpad Too Cumbersome" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1235642 13:16:10 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 I did do some minor investigation during the last conference, but those didn't get too far. 13:16:31 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 might be good to start with specifics. that LP entry is pretty slim ;) 13:17:19 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 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 dbwells: +1 13:18:43 however, if the community wants, GPLS could set up a server for experimentation 13:19:04 OK, so then do you want to defer your action item to summarize bug tracking to the next meeting? 13:19:14 bshum ^ ^ 13:19:16 kmlussier: Yes. 13:19:31 #action bshum to summarize bug tracking based on feedback from developers 13:19:41 And Dyrcona can put some thoughts towards that bug ticket, since he helped start it :) 13:19:55 #info [extra old action item ” ” ”] kmlussier to raise bug squashing day to the lists for further discussion/feedback 13:20:32 #info kmlussier posted message to the dev list today http://georgialibraries.markmail.org/thread/22six3nkgbhr3f3t 13:21:19 If anyone has anything to contribute to that discussion, feel free to send it to the list. 13:21:40 #info gmcharlt to release opensrf 2.2.1 soon(?) post-vacation 13:21:57 #info gmcharlt to release 2.2.1 this week 13:22:09 gmcharlt++ 13:22:20 (and KohaCon as a vacation for Koha's release manager? you jest, surely! ;) ) 13:22:38 #info csharp to test 2.4.2 rc so we can officialize it 13:22:42 gmcharlt: this includes the new opensrf controller script from berick, yes? 13:22:52 Related to opensrf, is there anything in master that lends cutting of a 2.3.0? 13:22:56 kmlussier: that happened, 2.4.3 is waiting in the wings 13:22:59 Like the control stuff 13:23:17 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 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 eeevil: btw, i copied your 2.4.3 files into place as well (though i'm getting ahead of myself) 13:24:31 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 gmcharlt: I'm for 2.3.0. enough user-visible changes, IMO 13:24:49 I agree, +1 for 2.3.0 13:25:18 (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 +1 to moving to 2.3.0 on account of the control script changes 13:26:03 I suppose we just need to update the README in Evergreen to use the new control commands. 13:26:03 #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 +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 jeff: too slow! ;) 13:26:21 heh 13:26:35 gmcharlt++ 13:27:02 so which opensrf version will be paired with EG 2.5? 13:27:18 * gmcharlt suggests 2.3.0 13:27:18 camembert 13:27:20 csharp: "latest" :) ... 2.2+ 13:27:26 ok 13:27:33 senator++ 13:27:33 as recommended, with note that 2.2.1 is compatible 13:27:41 (yes, 2.3+ recommended) 13:28:14 #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 Moving on to the next action item... 13:28:48 #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 senator++ # Thanks for all the action items! 13:29:32 #info eeevil to commit a techref doc explaining how to build pgTAP test 13:31:04 kmlussier: I have not done that yet. it's on my gtasks list, though! 13:31:23 nor have I had time to do the next one 13:31:39 OK, I'll add both as action items for next time then. 13:31:51 #action eeevil to commit a techref doc explaining how to build pgTAP test 13:32:03 thanks 13:32:08 #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 That's it for action items, and I think we've also covered OpenSRF Release Info? 13:33:16 #topic Evergreen release info 13:33:33 dbwells: Should we start with 2.5? 13:34:17 Sure. After a couple brief rounds of testing and bug squashing, RC1 is uploaded to the usual. 13:34:31 usual place, that is 13:35:10 Been having fun working out the release notes, but that is done as well, and will be uploaded shortly. 13:36:20 #info 2.5 RC1 is uploaded. Release notes will be uploaded shortly. 13:36:32 dbwells: Anything else to add? 13:36:41 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 It's really all about more testing at this point, so maybe RC will inspire some folks. 13:37:52 That's about it, unless folks have questions I might be able answer. 13:37:52 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 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 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 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 gmcharlt: I haven't looked at it, but I certainly will. 13:40:38 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 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 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 seems like it's too difficult to simulate in a test environment 13:41:52 csharp++ 13:42:17 dbwells: +1 # fwiw 13:42:33 dbwells: I know it's a pain, having just gone through packaging, but I'm +1 to that 13:43:03 dbwells: thanks -- but also, TIA to anybody who tests it 13:43:46 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 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 +1 13:45:08 * dbwells will test what he can of it, but RC1 will be out today, or BUST 13:45:48 dbwells++ 13:46:22 #agree dbwells will pull back RC1 and incorporate memory leak patches. Sign-off from other testers will be appreciated. 13:46:31 Any other questions for dbwells? 13:46:56 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 just need a volunteer from the web team (a Webster?) to update the downloads page 13:47:31 ha! 13:47:36 webster++ 13:47:38 * berick has nothing else to report on releases 13:48:07 bshum / moodaepo: Are either of you available to update the downloads page? 13:48:20 kmlussier: available 13:48:23 * dbwells almost called berick an acq-olyte yesterday (sorry) 13:48:25 kmlussier: I'd prefer to ask someone else to do it. I'm not a fan of my connection right now. 13:48:30 dbwells++ 13:48:35 moodaepo++ 13:48:36 bshum: go back to your poker chips 13:48:40 :) 13:48:46 puns++ :-D 13:48:59 :) 13:49:00 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 #topic Update on OmniTI Performance Work 13:49:31 I'll make this quick. 13:49:45 #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 depesz++ 13:50:05 #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 depesz++ indeed 13:50:29 #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 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 kmlussier++ 13:51:29 Or, conversely, if jsime has any questions for the devs. :) 13:52:09 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 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 instead of getting the list of patrons, then iterating through it to get each of their details in turn 13:56:19 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 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 phasefx: thanks for the link - berick's notes under General Improvement are spot on for that 13:58:10 OK, we're running short on time. I'm going to move on to the next agenda item. 13:58:19 #topic Discuss freezing of master during beta/RC phase 13:59:38 yeah, i was asking about that. thanks for added that.. dbwells? 13:59:42 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 my main concern was that stuff would accidentally seep into the beta/RC's 14:00:03 but that can probably be avoided with consensus on the plan, communication, etc. 14:00:23 I see two parts of it 14:00:27 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 freeze 'master' for new features to encourage folks to work on release-critical bugs 14:00:51 or, freeze master to avoid stuff slipping in by accident 14:01:01 the later could be addressed just by branch rel_2_5 14:01:04 *branching 14:01:33 the reason I don't like branching is that it increases the workload for the new-version RM 14:01:54 which is (I think dbwells and berick will agree) already pretty high 14:02:08 yes 14:03:23 indeed. so, it seems like everyone's in agreement in general. i'm also fine w/ the honor system 14:04:20 so, no version branch until x.x.0 is tagged? 14:05:03 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 +1 14:06:13 +1 14:06:14 +1 14:06:52 #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 Did I get that right? 14:07:08 kmlussier++ 14:07:26 OK, anything else for this meeting before we wrap up? 14:07:28 kmlussier: I imagine the bot would whine if you didn't :) 14:07:53 :) 14:08:06 #endmeeting