14:06:30 <jeff> #startmeeting 2014-02-12 Developer Meeting
14:06:30 <pinesol_green> 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 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:30 <pinesol_green> The meeting name has been set to '2014_02_12_developer_meeting'
14:06:37 <remingtron> jeff++!
14:06:43 <jeff> #info Agenda is at: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2014-02-12
14:06:56 <jeff> #topic Introductions
14:07:10 <jeff> #info jeff is Jeff Godin, Traverse Area District Library (TADL)
14:07:27 <phasefx> #info phasefx is Jason Etheridge, Equinox
14:07:37 <dbwells> #info dbwells is Dan Wells, Hekman Library (Calvin College)
14:07:39 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
14:08:02 <senator> #info senator is Lebbeous Fogle-Weekley, Equinox
14:08:54 <eeevil> #info eeevil is Mike Rylander, ESI
14:09:16 <jeff> as always, please continue to introduce at any point.
14:09:18 <ldwhalen> #info ldwhalen is Liam Whalen, Sitka
14:09:25 <jeff> #link agenda: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2014-02-12
14:09:33 <berick> #info berick Bill Erickson, ESI
14:09:33 <gmcharlt> #info gmcharlt is Galen Charlton, ESI
14:09:34 <jeff> (not sure if #info vs #link matters, but there)
14:09:51 <jeffdavis> #info jeffdavis is Jeff Davis, Sitka
14:09:51 <jeff> #topic Past Action Items
14:10:25 <jeff> #action bshum to summarize bug tracking based on feedback from developers
14:10:26 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
14:10:37 <jeff> (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 <jeff> #info gmcharlt is writing up release notes for OpenSRF 2.3-beta, will cut today
14:11:14 <jeff> eeevil: how's baseline schema write-up going?
14:11:20 <eeevil> 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 <jeff> sounds good.
14:11:50 <jeff> #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 <jeff> 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 <pinesol_green> 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 <dbs> #info dbs is late, also Dan Scott, Laurentian University
14:13:05 <jeff> 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 <jl-> dbs: my thanks for your patience also for bringign me on the right track with the conerto loader
14:15:30 <jeffdavis> I'd love to have that fix backported, dunno if I have time to poke at it though.
14:15:35 <jeff> #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 <pinesol_green> 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 <jeff> #link https://bugs.launchpad.net/evergreen/+bug/1242999
14:16:16 <eeevil> jeff: I guess we should target 2.4. I will backport if it picks relatively clean
14:16:21 <jeff> #info bshum has fixed up the 2.4.5 and set 2.4.6 milestones in LP
14:16:40 <jeff> #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 <jeff> #info dbs has written up the release notes as promised in bug # 1261939 for per-library TPAC pages
14:17:15 <jeff> #link http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46f49173b6a08f4c7b755de728edbe6bafb9879a
14:17:15 <pinesol_green> [evergreen|Dan Scott] Release notes for the TPAC library web pages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46f4917>
14:18:08 <jeff> #info bshum has granted dbwells access to dev calendar so that RM milestone dates can be added
14:18:18 <dbwells> 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 <jeff> dbwells: would you like an action item for adding RM dates to the dev calendar?
14:19:05 <jeff> #link http://www.google.com/calendar/embed?src=tfm2bbqnt7q890jidnqe3u29j4%40group.calendar.google.com&ctz=America/New_York
14:19:12 <dbwells> 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 <eeevil> dbwells: with all the tests I'm fairly comfortable, fwiw
14:19:28 <eeevil> dbwells: if you're offering, sure thing! :)
14:19:42 <eeevil> (comfortable with a backport generally)
14:19:44 <dbwells> eeevil: yes, no problem
14:19:53 <dbwells> jeff: Why not
14:19:57 <jeff> #action dbwells to add RM dates to dev calendar
14:20:36 <jeff> #info berick has opened OpenSRF LP bug with current websocket info
14:20:38 <jeff> #link https://bugs.launchpad.net/opensrf/+bug/1268619
14:20:39 <pinesol_green> Launchpad bug 1268619 in OpenSRF "WebSockets Gateway and JS Library" (affected: 1, heat: 6) [Undecided,New]
14:20:56 <berick> i added a note today about the current state of the code
14:21:08 <jeff> on to Updates!
14:21:27 <jeff> #topic Google Summer of Code (GSoC) 2014
14:21:53 <jeff> GSoC deadline is in two days, Friday February 14.
14:22:07 * bshum is now phoning in over airplane wifi.
14:22:16 <jeff> Is anyone present interested in participating and being a mentor on behalf of the Evergreen project?
14:22:19 <jeff> bshum++
14:22:29 <gmcharlt> no
14:22:40 <gmcharlt> or not I, I should say
14:22:58 <dbs> I would be willing to admin, but can't commit to mentoring :/
14:23:10 <dbwells> I am fine with gmcharlt speaking for everyone on this :)
14:23:15 <berick> heh
14:23:55 <phasefx> 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 <bshum> I think our ideas page is super old.
14:24:03 <jeff> dbs: Am I correct in thinking that the application due Friday requires mentors to be identified before submission?
14:24:19 <dbs> Oh yeah, the ideas page is terribly old. Should be updated regardless I guess
14:24:24 <bshum> And I'd be worried about having enough time to update it again.
14:24:27 <dbs> jeff: no, but it would help
14:24:29 <gmcharlt> jeff: strictly speaking, no, but we shoudln't apply unless we're sure that we have enough committment
14:24:32 <phasefx> s/then/rather than/
14:24:32 <bshum> Prior to submission.
14:25:04 <dbs> gmcharlt: exactly
14:25:05 <jeff> Past mentors: what time committment and what number of mentors do you see as being required for success?
14:25:30 <dbs> Two mentors per student, 10 - 15 hours per week.
14:25:37 <gmcharlt> I agree with dbs
14:25:40 <dbs> "for success" being the key part of your question
14:28:08 <bshum> 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 <bshum> I don't have any immediate suggestions though.
14:28:35 <bshum> So that kind of kills me off by default.
14:28:55 <dbs> Working on a piece of the new staff client would be fun and exciting :)
14:29:14 <dbwells> My sense is that we could benefit from taking a break.  Next year will be here before you know it.
14:29:22 <jeff> 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 <gmcharlt> I think we need full enthusiasm on the part of potential mentors; I agree that we need a break
14:29:42 <dbs> +1 to taking a break
14:30:06 <senator> +1
14:30:15 <dbs> (note: if you want to mentor, there may be other orgs you can mentor for... and learn from them)
14:30:38 <berick> +1 to break
14:30:47 <eeevil> +1
14:31:06 <phasefx> +1
14:31:20 <bshum> +1
14:31:38 <jeff> #agreed We'll be taking a break from participation in GSoC for this year
14:31:56 <jeff> moving on to release info
14:32:06 <jeff> #topic Release Info - OpenSRF
14:32:20 <bshum> Someone should write back to the inquiry we have on the general list on GSoC. Now that we've agreed.
14:32:21 <jeff> gmcharlt: beta 2.3 to be cut later today, correct?
14:32:30 <gmcharlt> yep
14:32:45 <jeff> #info OpenSRF 2.3 beta to be cut later today
14:32:50 <jeff> anything else to add for OpenSRF?
14:34:34 <jeff> #topic Release Info - Evergreen
14:34:49 <jeff> gmcharlt: (apologies if you were typing something other than "nope!")
14:34:58 <gmcharlt> nope
14:35:02 <gmcharlt> as it were ;)
14:35:19 <jeff> dbwells++ for a very entertaining RM 2.6 update yesterday. :-)
14:35:37 <bshum> dbwells++ indeed!
14:35:57 <dbwells> #info 2.6 beta review period is underway, and is scheduled to conclude on the 18th.  Alpha awards have been awarded.
14:37:35 <jeff> #link http://permalink.gmane.org/gmane.education.libraries.open-ils.general/9189 Evergreen 2.6 Alpha - Summary and Awards
14:37:57 <dbwells> 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 <jeff> #link https://launchpad.net/evergreen/+milestone/2.6.0-beta1 63 bugs targeted for Evergreen 2.6 Beta
14:38:28 <dbwells> jeff: thanks
14:38:39 <jeff> on to new business!
14:38:55 <jeff> #topic PostgreSQL 9.3 support
14:39:46 <jeff> #info several aspects of PostgreSQL 9.3 that break Evergreen
14:39:53 <dbs> 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 <jeff> some have bugs already, such as bug 1253163, bug 277731, and bug 1243023
14:40:14 <pinesol_green> 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 <pinesol_green> 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 <pinesol_green> 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 <jeff> 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 <dbs> 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 <jeff> and again, copying and pasting, dbs asks:
14:41:12 <jeff> > 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 <jeff> discussion?
14:41:43 <jeff> dbwells: I'd be interested in your thoughts especially on making 9.3 support a 2.6 blocker.
14:41:50 <dbs> 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 <ldwhalen> dbs: jeffdavis has stepped out
14:43:03 <dbwells> I think having 9.3 support as a release blocker for 2.6 is a reasonable stance to take.
14:43:14 <dbs> ldwhalen: oh hey, well you're a good sitka person :)
14:43:25 <eeevil> the xpath issue is the most difficult to solve, IMO. any thoughts on my proposed (admittedly hand-wavy) path?
14:43:58 <gmcharlt> 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 <eeevil> 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 <gmcharlt> 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 <dbs> 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 <jeff> 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 <gmcharlt> 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 <eeevil> jeff:  you beat me to it... speed is my concern
14:46:08 <dbs> our xpath-ery is mostly on ingest / update yeah?
14:46:18 <dbs> still a real cost though :/
14:46:58 <jeff> eeevil's aforementioned "hand-wavy" path: https://bugs.launchpad.net/evergreen/+bug/1243023/comments/13
14:47:00 <pinesol_green> Launchpad bug 1243023 in Evergreen "Browse catalogue titles are doubly escaped?" (affected: 1, heat: 6) [Undecided,New]
14:47:24 <ldwhalen> 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 <gmcharlt> 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 <gmcharlt> "rought"?  a trip through dry areas?
14:47:46 <gmcharlt> route
14:47:46 <eeevil> 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 <eeevil> we just put xslt_process and xpath() in the evergreen schema
14:48:08 <jeff> 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 <gmcharlt> well, almost
14:48:33 <jeff> Can I get +1s for considering PostgreSQL 9.3 support an Evergreen 2.6 release blocker?
14:48:35 <gmcharlt> do we have a consensus about 9.3 being a release-blocker for 2.6?
14:48:40 <ldwhalen> +1
14:48:52 <gmcharlt> +1
14:49:53 <dbwells> +1
14:49:58 <eeevil> +1
14:50:14 <dbs> +1
14:50:32 <jeff> #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 <jeff> 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 <gmcharlt> I think we can hash that out outside this meeting
14:52:00 <dbs> dbwells: would you be willing to drive that as a 2.6-specific group of tasks?
14:52:38 <dbwells> dbs: Yes, if I understand your meaning.
14:53:28 <dbwells> Also, I have another meeting at 3:00pm, so discussion will need to happen later or without me, at this point.
14:53:57 <dbs> dbwells++
14:54:07 <jeff> #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 <jeff> #action dbwells to summarize Evergreen 2.6 aspects of PostgreSQL 9.3 support in future 2.6 RM reports
14:55:40 <jeff> #topic Evergreen Hackfest Plans
14:56:38 <jeff> wiki page for ideas sounds like a good starting point. does anyone have structural ideas for the dev hackfest in Boston?
14:57:23 <gmcharlt> one question - is there any interest in doing tutorials of any sort?
14:58:20 <ldwhalen> I would like a hand on understanding how the fieldmapper works
14:58:40 <jeff> 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 <jeff> aww :-(
14:59:12 <gmcharlt> announcing tutorials in advanace might affect who shows up, of course :)
14:59:53 <jeff> 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 <jeff> #action jeff to start dev:hackfest:eg2014 wiki page and announce on dev list, solicit ideas and further discussion
15:00:33 <jeff> anything else before we adjourn?
15:01:22 <jeff> #endmeeting