14:06:30 #startmeeting 2014-02-12 Developer Meeting 14:06:30 Meeting started Wed Feb 12 14:06:30 2014 US/Eastern. The chair is jeff. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:06:30 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:06:30 The meeting name has been set to '2014_02_12_developer_meeting' 14:06:37 jeff++! 14:06:43 #info Agenda is at: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2014-02-12 14:06:56 #topic Introductions 14:07:10 #info jeff is Jeff Godin, Traverse Area District Library (TADL) 14:07:27 #info phasefx is Jason Etheridge, Equinox 14:07:37 #info dbwells is Dan Wells, Hekman Library (Calvin College) 14:07:39 #info remingtron is Remington Steed, Hekman Library (Calvin College) 14:08:02 #info senator is Lebbeous Fogle-Weekley, Equinox 14:08:54 #info eeevil is Mike Rylander, ESI 14:09:16 as always, please continue to introduce at any point. 14:09:18 #info ldwhalen is Liam Whalen, Sitka 14:09:25 #link agenda: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2014-02-12 14:09:33 #info berick Bill Erickson, ESI 14:09:33 #info gmcharlt is Galen Charlton, ESI 14:09:34 (not sure if #info vs #link matters, but there) 14:09:51 #info jeffdavis is Jeff Davis, Sitka 14:09:51 #topic Past Action Items 14:10:25 #action bshum to summarize bug tracking based on feedback from developers 14:10:26 #info kmlussier is Kathy Lussier, MassLNC 14:10:37 (bshum is on a plane, and stated status in the agenda already) 14:10:48 * gmcharlt is writing up release notes for OpenSRF 2.3-beta, will cut today 14:10:58 #info gmcharlt is writing up release notes for OpenSRF 2.3-beta, will cut today 14:11:14 eeevil: how's baseline schema write-up going? 14:11:20 it's way too late to start such a discussion for 2.6, so I won't raise that until after 2.6.0 is out 14:11:31 sounds good. 14:11:50 #action eeevil After 2.6.0 is cut, eeevil to 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. 14:12:22 dbwells reviewed and pushed fix for bug 1242999 to master and will backport to 2.5.3. anyone present have opinions on backporting to 2.4? 14:12:23 Launchpad bug 1242999 in Evergreen 2.5 "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 12) [Undecided,Confirmed] https://launchpad.net/bugs/1242999 - Assigned to Dan Wells (dbw2) 14:12:32 * dbs is late, also Dan Scott, Laurentian University 14:12:35 * eeevil chuckles at "eeevil's plan" ... 14:12:46 #info dbs is late, also Dan Scott, Laurentian University 14:13:05 It might come down to "will one of the supported distros start including Encode.pm >= 2.54 before Evergreen 2.4 is EOL?" 14:13:34 dbs: my thanks for your patience also for bringign me on the right track with the conerto loader 14:15:30 I'd love to have that fix backported, dunno if I have time to poke at it though. 14:15:35 #action dbwells to backport bugfix for Encode.pm (bug 1242999) issues to rel_2_5, feedback requested on backporting to earlier releases 14:15:36 Launchpad bug 1242999 in Evergreen 2.5 "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 12) [Undecided,Confirmed] https://launchpad.net/bugs/1242999 - Assigned to Dan Wells (dbw2) 14:15:38 #link https://bugs.launchpad.net/evergreen/+bug/1242999 14:16:16 jeff: I guess we should target 2.4. I will backport if it picks relatively clean 14:16:21 #info bshum has fixed up the 2.4.5 and set 2.4.6 milestones in LP 14:16:40 #action bshum to go through and update the bug statuses to "fix released" for things that are done in milestones for 2.4.5 and 2.4.6 14:17:08 #info dbs has written up the release notes as promised in bug # 1261939 for per-library TPAC pages 14:17:15 #link http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46f49173b6a08f4c7b755de728edbe6bafb9879a 14:17:15 [evergreen|Dan Scott] Release notes for the TPAC library web pages - 14:18:08 #info bshum has granted dbwells access to dev calendar so that RM milestone dates can be added 14:18:18 jeffdavis eeevil: I don't think it will be a problem as far as code conflicts go, it was more just a risk/reward type question (the changes are kinda low-level, and the overlap between newer Encode and older EG is pretty small). 14:19:02 dbwells: would you like an action item for adding RM dates to the dev calendar? 14:19:05 #link http://www.google.com/calendar/embed?src=tfm2bbqnt7q890jidnqe3u29j4%40group.calendar.google.com&ctz=America/New_York 14:19:12 eeevil: I can do the backport when I do rel_2_5, as long is you are fine with it going in. 14:19:13 dbwells: with all the tests I'm fairly comfortable, fwiw 14:19:28 dbwells: if you're offering, sure thing! :) 14:19:42 (comfortable with a backport generally) 14:19:44 eeevil: yes, no problem 14:19:53 jeff: Why not 14:19:57 #action dbwells to add RM dates to dev calendar 14:20:36 #info berick has opened OpenSRF LP bug with current websocket info 14:20:38 #link https://bugs.launchpad.net/opensrf/+bug/1268619 14:20:39 Launchpad bug 1268619 in OpenSRF "WebSockets Gateway and JS Library" (affected: 1, heat: 6) [Undecided,New] 14:20:56 i added a note today about the current state of the code 14:21:08 on to Updates! 14:21:27 #topic Google Summer of Code (GSoC) 2014 14:21:53 GSoC deadline is in two days, Friday February 14. 14:22:07 * bshum is now phoning in over airplane wifi. 14:22:16 Is anyone present interested in participating and being a mentor on behalf of the Evergreen project? 14:22:19 bshum++ 14:22:29 no 14:22:40 or not I, I should say 14:22:58 I would be willing to admin, but can't commit to mentoring :/ 14:23:10 I am fine with gmcharlt speaking for everyone on this :) 14:23:15 heh 14:23:55 if we're going to do it, I'd rather see more support from everyone on it, then letting one or two people carry the mentor load. I'm in favor of not doing it this time :) 14:23:58 I think our ideas page is super old. 14:24:03 dbs: Am I correct in thinking that the application due Friday requires mentors to be identified before submission? 14:24:19 Oh yeah, the ideas page is terribly old. Should be updated regardless I guess 14:24:24 And I'd be worried about having enough time to update it again. 14:24:27 jeff: no, but it would help 14:24:29 jeff: strictly speaking, no, but we shoudln't apply unless we're sure that we have enough committment 14:24:32 s/then/rather than/ 14:24:32 Prior to submission. 14:25:04 gmcharlt: exactly 14:25:05 Past mentors: what time committment and what number of mentors do you see as being required for success? 14:25:30 Two mentors per student, 10 - 15 hours per week. 14:25:37 I agree with dbs 14:25:40 "for success" being the key part of your question 14:28:08 I'd be tempted to try again (since last year's student was disappointing) but I'd like to get some fresher ideas on file. 14:28:24 I don't have any immediate suggestions though. 14:28:35 So that kind of kills me off by default. 14:28:55 Working on a piece of the new staff client would be fun and exciting :) 14:29:14 My sense is that we could benefit from taking a break. Next year will be here before you know it. 14:29:22 I'd be interested in mentoring, but would rather not do it alone. Someone who's mentored before would be great to have involved. 14:29:28 I think we need full enthusiasm on the part of potential mentors; I agree that we need a break 14:29:42 +1 to taking a break 14:30:06 +1 14:30:15 (note: if you want to mentor, there may be other orgs you can mentor for... and learn from them) 14:30:38 +1 to break 14:30:47 +1 14:31:06 +1 14:31:20 +1 14:31:38 #agreed We'll be taking a break from participation in GSoC for this year 14:31:56 moving on to release info 14:32:06 #topic Release Info - OpenSRF 14:32:20 Someone should write back to the inquiry we have on the general list on GSoC. Now that we've agreed. 14:32:21 gmcharlt: beta 2.3 to be cut later today, correct? 14:32:30 yep 14:32:45 #info OpenSRF 2.3 beta to be cut later today 14:32:50 anything else to add for OpenSRF? 14:34:34 #topic Release Info - Evergreen 14:34:49 gmcharlt: (apologies if you were typing something other than "nope!") 14:34:58 nope 14:35:02 as it were ;) 14:35:19 dbwells++ for a very entertaining RM 2.6 update yesterday. :-) 14:35:37 dbwells++ indeed! 14:35:57 #info 2.6 beta review period is underway, and is scheduled to conclude on the 18th. Alpha awards have been awarded. 14:37:35 #link http://permalink.gmane.org/gmane.education.libraries.open-ils.general/9189 Evergreen 2.6 Alpha - Summary and Awards 14:37:57 I'll try to get a beta related email out soon, but since we have trimmed away a lot of the stuck bugs, the milestone itself is a pretty accurate representation of what is ready for review. 14:38:00 #link https://launchpad.net/evergreen/+milestone/2.6.0-beta1 63 bugs targeted for Evergreen 2.6 Beta 14:38:28 jeff: thanks 14:38:39 on to new business! 14:38:55 #topic PostgreSQL 9.3 support 14:39:46 #info several aspects of PostgreSQL 9.3 that break Evergreen 14:39:53 This kind of bleeds into 9.2 support too, for the XPath() changes, but we've seen a few extra 9.3 pain points pop up (per the listed bugs) 14:40:11 some have bugs already, such as bug 1253163, bug 277731, and bug 1243023 14:40:14 Launchpad bug 1253163 in Evergreen "authority indexes can fail on Postgres 9.3.0" (affected: 2, heat: 12) [Undecided,Confirmed] https://launchpad.net/bugs/1253163 14:40:15 Launchpad bug 277731 in update-manager (Ubuntu) "Upgrade complete dialog shows: ugprade" (affected: 0, heat: 6) [Low,Fix released] https://launchpad.net/bugs/277731 14:40:16 Launchpad bug 1243023 in Evergreen "Browse catalogue titles are doubly escaped?" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1243023 14:40:34 also, copying and pasting from the agenda (thanks, dbs): Stricter type handling in function arguments (INTs no longer automatically coerced to TEXTs) breaks STRING_AGG() in a few places, possibly other functions - not sure this is bugged yet 14:40:53 It seems likely that a) people are going to want to adopt 9.3 and beyond aggressively for performance improvements and b) that even the non-early adopters will get pushed to 9.3 once distros catch up 14:41:10 and again, copying and pasting, dbs asks: 14:41:12 > Should we make PostgreSQL 9.3 support a release blocker for Evergreen 2.6 to avoid accumulating too much technical deficit / causing too much pain for those who aren't aware of the 9.3 problems? 14:41:22 discussion? 14:41:43 dbwells: I'd be interested in your thoughts especially on making 9.3 support a 2.6 blocker. 14:41:50 jeffdavis: I know Sitka was planning on jumping to 9.3 real soon and Robin Johnson was surprised when I cautioned him on that... 14:42:34 dbs: jeffdavis has stepped out 14:43:03 I think having 9.3 support as a release blocker for 2.6 is a reasonable stance to take. 14:43:14 ldwhalen: oh hey, well you're a good sitka person :) 14:43:25 the xpath issue is the most difficult to solve, IMO. any thoughts on my proposed (admittedly hand-wavy) path? 14:43:58 re the xpath functions - and the XML and XSLT in general - I'd suggest going back to rolling our own, based on libxml2/libxslt, possibly via their Perl wrappers 14:44:02 the others are just whack-a-mole and "be less clever" issues 14:44:22 * dbs is working on the known STRING_AGG() text-casting at least 14:44:26 it would be a pain, but this is one area where I think I trust ourselves more than I trust the Pg devs 14:45:06 gmcharlt: that doesn't sound too crazy to me. either way, with some pgTAP tests to ensure that the results are consistent across versions 14:45:08 gmcharlt: do you expect performance pain in addition to transition pain, or does this fall under the umbrella of "if we're xpath'ing too much, we're already doing something wrong"? 14:45:26 tradeoffs might include performance and/or the time of maintaining our own extensions if we decide to write C instead of Perl to wrap around libxml2/libxslt 14:45:36 jeff: you beat me to it... speed is my concern 14:46:08 our xpath-ery is mostly on ingest / update yeah? 14:46:18 still a real cost though :/ 14:46:58 eeevil's aforementioned "hand-wavy" path: https://bugs.launchpad.net/evergreen/+bug/1243023/comments/13 14:47:00 Launchpad bug 1243023 in Evergreen "Browse catalogue titles are doubly escaped?" (affected: 1, heat: 6) [Undecided,New] 14:47:24 I just had a quick chat with Robin here. He would like to go to 9.3. So, I am in favour of making 9.3 support a blocker for 2.6. 14:47:32 benchmarking is key, of course, but yeah, I'd expect it to be slower, particularly if we go the rought of using PL/Perl wrappers 14:47:45 "rought"? a trip through dry areas? 14:47:46 route 14:47:46 if we're stricter about our search_path stuff, we don't even have to move the built-ins out of the way 14:48:08 we just put xslt_process and xpath() in the evergreen schema 14:48:08 okay. I don't think we're going to decide on a path forward for this specific issue in-meeting. Let me get some agreement going on the overall. 14:48:25 well, almost 14:48:33 Can I get +1s for considering PostgreSQL 9.3 support an Evergreen 2.6 release blocker? 14:48:35 do we have a consensus about 9.3 being a release-blocker for 2.6? 14:48:40 +1 14:48:52 +1 14:49:53 +1 14:49:58 +1 14:50:14 +1 14:50:32 #agreed Evergreen 2.6 will support PostgreSQL 9.3 (PostgreSQL 9.3 issues to be considered release blockers for Evergreen 2.6) 14:51:22 do we need to discuss specific strategy further, or shall that take place in the usual places: launchpad, irc, and the dev list? 14:51:45 I think we can hash that out outside this meeting 14:52:00 dbwells: would you be willing to drive that as a 2.6-specific group of tasks? 14:52:38 dbs: Yes, if I understand your meaning. 14:53:28 Also, I have another meeting at 3:00pm, so discussion will need to happen later or without me, at this point. 14:53:57 dbwells++ 14:54:07 #info Further strategy on resolving PostgreSQL 9.3 issues will take place in the existing LP bugs, and/or in irc and on the dev list 14:54:24 * dbs just meant to track the pg 9.3 things in 2.6 release reports 14:55:32 #action dbwells to summarize Evergreen 2.6 aspects of PostgreSQL 9.3 support in future 2.6 RM reports 14:55:40 #topic Evergreen Hackfest Plans 14:56:38 wiki page for ideas sounds like a good starting point. does anyone have structural ideas for the dev hackfest in Boston? 14:57:23 one question - is there any interest in doing tutorials of any sort? 14:58:20 I would like a hand on understanding how the fieldmapper works 14:58:40 I've some interest. It might depend on who shows up. 14:59:01 * dbs isn't going to be at the hackfest this year :( 14:59:07 aww :-( 14:59:12 announcing tutorials in advanace might affect who shows up, of course :) 14:59:53 I'll start a wiki page for dev:hackfest:eg2014 with some space for tutorials and other structural ideas, as well as the usual list-o-ideas. 15:00:25 #action jeff to start dev:hackfest:eg2014 wiki page and announce on dev list, solicit ideas and further discussion 15:00:33 anything else before we adjourn? 15:01:22 #endmeeting