15:07:18 <dbwells> #startmeeting 2012-08-29 - Developer Meeting
15:07:18 <pinesol_green> Meeting started Wed Aug 29 15:07:18 2012 US/Eastern.  The chair is dbwells. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:18 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:07:20 * eeevil looks around
15:07:33 * gmcharlt here
15:08:03 <dbwells> #info dbwells is Dan Wells, Hekman Library, Calvin College
15:08:18 <denials> #info denials is Dan Scott, Laurentian University
15:08:40 <eeevil> #info eeevil is Mike Rylander, Equinox
15:08:49 <gmcharlt> #info gmcharlt is Galen Charlton, Equinox
15:09:31 <tsbere> #info tsbere is Thomas Berezansky, MVLC
15:10:02 <senator> #info senator is Lebbeous Fogle-Weekley, Equinox
15:10:04 <pwaak> info pwaak is Paul Waak, North Texas Library Partners
15:10:08 <danielR> #info danielR is Daniel Rizea, Gsoc student on project:  Android client for EG
15:10:10 <jeff> #info jeff is Jeff Godin, TADL
15:10:43 <dbwells> #topic Action Items from Last Meeting
15:11:23 <dbwells> #info denials still going to write up �How to set up an alias for cherry-picking w/ signoff in tig�
15:11:40 <denials> danielR: you're an Evergreen developer; GSoC is just how we were lucky enough to meet you
15:12:02 * denials is still going to write that up, in more than the one-line .tigrc he posted to IRC
15:12:33 <dbwells> good enough, I think
15:12:42 <dbwells> #info STATUS: denials is still going to write that up, in more than the one-line .tigrc he posted to IRC
15:13:32 <dbwells> #info GSoC reports are deferred for later in the meeting
15:14:11 <dbwells> next, berick to announce alpha2 release on general/dev list.  Anything more to report or worth logging along those lines?
15:14:53 <berick> i'll make sure the rc1 release actually gets some kind of announcement
15:15:03 <eeevil> heh
15:15:03 <berick> apart from the -dev stuff
15:15:43 <dbwells> #info berick to announce alpha2 release on general/dev list.  STATUS: Done, along with beta1 and beta2
15:16:19 <dbwells> #action berick will make sure the rc1 release actually gets some kind of announcement
15:17:31 <dbwells> sorry in advance for being inconsistent, still trying to work out the most useful things to mark in the logs.  And if anyone else wants to chair, I am happy to hand it over.  Next, "denials will open bug to track TPAC locale selector needs"
15:18:36 <denials> done, and implemented, and merged back through 2.2 with the assistance of senator and berick (IIRC)
15:19:00 <senator> denials++
15:19:06 <denials> bug 1025921 and ...
15:19:07 <pinesol_green> Launchpad bug 1025921 in Evergreen "TPAC needs a locale picker" (affected: 2, heat: 10) [Undecided,Fix committed] https://launchpad.net/bugs/1025921
15:19:16 <denials> bug 1033003
15:19:17 <pinesol_green> Launchpad bug 1033003 in Evergreen "TPAC: Use POST for setting the locale picker" (affected: 1, heat: 6) [Undecided,Fix committed] https://launchpad.net/bugs/1033003
15:19:46 <denials> That's one small step for i18n
15:19:48 <denials> :)
15:20:28 <dbwells> Thank you.
15:20:40 <dbwells> #info denials will open bug to track TPAC locale selector needs -- STATUS: done, and implemented, and merged back through 2.2 with the assistance of senator and berick (I'denials'RC), LP bugs 1025921 and 1033003
15:20:43 <pinesol_green> Launchpad bug 1025921 in Evergreen "TPAC needs a locale picker" (affected: 2, heat: 10) [Undecided,Fix committed] https://launchpad.net/bugs/1025921
15:20:44 <pinesol_green> Launchpad bug 1033003 in Evergreen "TPAC: Use POST for setting the locale picker" (affected: 1, heat: 6) [Undecided,Fix committed] https://launchpad.net/bugs/1033003
15:21:46 <dbwells> Next, "senator will update the bug with an outline of what could be changed for more speed"
15:22:53 <dbwells> senator: is that the same bug you asked me about earlier, or something else?
15:23:28 <jeff> that seems to be in reference to bug 1024095
15:23:29 <pinesol_green> Launchpad bug 1024095 in Evergreen "Extremely slow batch marc loading in 2.2 Vandelay" (affected: 3, heat: 16) [Undecided,New] https://launchpad.net/bugs/1024095
15:23:32 <senator> yeah i think we're talking about the same one, 1024095
15:23:38 <senator> right, as jeff says
15:23:43 <jeff> logs++
15:24:45 <senator> so that bug has been updated by dbwells and by me since the last meeting, but with his help i plan to move forward on that soon
15:24:55 <pranjal710> #info
15:26:00 <dbwells> #info senator will update the bug with an outline of what could be changed for more speed -- STATUS: senator and dbwells have made some progress on understanding the issue, and expect to have it resolved soon
15:26:21 <dbwells> #info bug in question is LP 1024095
15:26:23 <pinesol_green> Launchpad bug 1024095 in Evergreen "Extremely slow batch marc loading in 2.2 Vandelay" (affected: 3, heat: 16) [Undecided,New] https://launchpad.net/bugs/1024095
15:27:00 <dbwells> #action senator and dbwells will work out the remaining details on bug 1024095
15:27:31 <dbwells> #info bshum / moodaepo will mark Evergreen 2.0.x as deprecated, and style it to look as dead and unappealing as possible -- STATUS: Done.
15:27:31 <denials> #info a howto for tig cherry-picking with sign-off is at http://www.evergreen-ils.org/dokuwiki/doku.php?id=dev:git:tig
15:28:06 <dbwells> bshum++  moodaepo++ denials++
15:28:58 <denials> shame++
15:29:16 <dbwells> Ok, moving along...
15:29:18 <dbwells> #topic GSoC Reports
15:29:42 <dbwells> Do denials and/or gmcharlt want to say something first?
15:30:08 <gmcharlt> to start off with some good news, all four students have passed
15:30:31 <gmcharlt> I suggest that students (if present) and their mentors do a quick summary of the final result of each project
15:30:57 <gmcharlt> so, in alphabetical order by nick - danielR and dbwells?
15:31:07 <dbwells> I know my student is present, and is having connection issues, so let's start with him if he is there.
15:31:28 <danielR> Hello
15:31:46 <danielR> yes I am here bun I am not 100% sure of my net conenction
15:32:28 <danielR> Me and dbwells, my mentor, have worked on the Android client for EG
15:34:25 <jeff> danielR++ # thanks for your contributions!
15:34:41 <danielR> To make a quick summary the project is an Android EG client (it has all the OPAC web functionalities: search, checkout, holds and bookbags) + barcode ISBN scan (and search based on the barcode) + notifications (notify the user when a checkout is about to expire)
15:35:06 <danielR> I am glad that I could help
15:35:14 <denials> danielR++ # one of my Java-savvy colleagues, artunit, has looked at your code and thinks quite highly of it
15:36:43 <dbwells> For my own part, I took on this project knowing it was one of the less defined projects we had sketched out on the suggestions page, so I wasn't fully sure where it would end up.
15:36:53 <danielR> thank you, but I still have to do some work in this direction
15:37:25 <dbwells> All in all, I see two big benefits beyond the actual app code.
15:38:29 <dbwells> First, we were able to make use of some of berick's (and others?) hard work on the Java libraries.  I think it is of great benefit to have some working samples to continue building upon.
15:39:28 <jeff> dbwells++ danielR++
15:39:39 <jeff> berick++
15:39:46 <dbwells> Second, we put a lot of thought and effort into the actual design and layout for small devices.  It all seems so easy until you try it! :)
15:39:58 <danielR> :)
15:40:04 <denials> danielR: awesome - hopefully you'll keep working with us on this (and other) code!
15:40:30 <danielR> It will be my pleasure
15:40:41 <jeff> denials: yay! welcome!
15:40:43 <jeff> er
15:40:49 <jeff> too many "d" folk.
15:40:52 <denials> :)
15:40:54 <jeff> danielR: yay! welcome!
15:40:57 <jeff> that's better.
15:41:07 <danielR> There is still work to be done and I have discuss with my mentor some future improvements :)
15:41:08 <dbwells> We take all the Dan's we can get around here.
15:41:27 <eeevil> dbwells: indeed ... Dans tend to work out well ;)
15:42:33 <gmcharlt> Dans++
15:42:42 <gmcharlt> so, eeevil, you're up next
15:42:49 <eeevil> WHEE
15:42:57 <dbwells> wait one second
15:43:05 * eeevil waits
15:43:23 <dbwells> #info danielR reports "To make a quick summary the project is an Android EG client (it has all the OPAC web functionalities: search, checkout, holds and bookbags) + barcode ISBN scan (and search based on the barcode) + notifications (notify the user when a checkout is about to expire)"
15:43:36 <dbwells> ok, thanks, proceed
15:43:51 <eeevil> heh
15:44:01 * eeevil does
15:44:20 <eeevil> I don't see my student in here... so I'll just dive in
15:44:49 <eeevil> he started by converting the search_normalize and naco_normalized stored procedures from plperl to plc
15:45:03 <eeevil> on long strings, that make a big difference in speed
15:45:05 <eeevil> however...
15:45:20 <eeevil> most strings indexed in evergreen, from bib records are not ... long
15:46:01 <eeevil> there is a small improvement, though, and the work set out a good template for ICU-based string manipulation in C-based stored procs
15:46:58 <eeevil> his code is good, and his methodology was sound -- even in the face of too little availability from me, he completed the tasks we'd defined
15:47:22 <eeevil> anyway, after that, he moved on to working on other plperl stored procs
15:47:40 <eeevil> some of the MARC handling stuff
15:48:28 <eeevil> there wasn't time for him to fully debug those, but there's good groundwork laid out
15:49:25 <eeevil> I need to find time to dig into those further, but while we don't have commits we can push into master, I think overall the result was positive
15:49:33 <denials> Do you know if he plans to keep on working on those, or on other areas in Evergreen?
15:50:13 <eeevil> denials: he's back in school, but he has said he wants to keep working on search in evergreen, yes
15:50:44 <eeevil> he found the twisty paths intruiging, I believe ;)
15:51:16 <senator> does that bring it to me?
15:51:16 <gmcharlt> folks_not_getting_scared_away_by_twisty_paths++ ;)
15:51:25 <gmcharlt> senator: yep
15:51:32 * senator gives dbwells a moment to compose his info
15:51:47 <denials> awesome!
15:52:19 <dbwells> senator: go ahead, I'll just blurt it out when it's ready :)
15:52:28 <senator> dbwells: heh cool
15:52:41 <senator> so pranjal710 is in the room, and he completed PHP client bindings for OpenSRF
15:53:00 <jeff> pranjal710++
15:53:33 <senator> this essentially means PHP users now have an easy and consistent way to call any opensrf method using fieldmapper objects in the parameters and getting them in results, too
15:53:49 <senator> based on the IDL published by the host being contacted
15:54:09 <denials> that is really great, pranjal710++
15:54:19 <senator> pranjal710's work is on github and he's working on getting it into PEAR for PHP users' convenience
15:54:21 <jeff> pranjal710++ often attempted, now completed!
15:55:32 <pranjal710> Thankyou :) . My mentor helped me a lot.
15:55:41 <pranjal710> I am planning to improve the code
15:55:46 <denials> nothing like "pear install Services-OpenSRF" or the like to make things easy !
15:56:11 <pranjal710> like using HTTP_Request 2 instead of cURL
15:56:12 <dbwells> #info eeevil reported on behalf of his student (swenyu) -- Converted string normalizing functions led to small speed improvements and a good template for ICU-based string manipulation in C-based stored procs.  swenyu also started some MARC handling code, and is interested in continuing to work on search in evergreen.
15:56:40 * denials wonders if the VuFind people know about pranjal710's work, yet
15:56:45 <senator> pranjal, you're back in school, right, and busy with new projects, but you hope to continue contributing with this project?
15:57:01 <denials> they've been looking for a robust evergreen connector for a while, sounds like this would be the ticket
15:57:12 <pranjal710> Yes, I am back to my school, but I will keep contributing to this project
15:57:16 <senator> pranjal710++
15:58:13 <gmcharlt> pranjal710++
15:58:28 <denials> one of us, one of us!
15:58:34 <gmcharlt> tsbere: you're next
15:58:37 <pranjal710> Thankyou :)
15:58:41 <senator> the link to guthub, btw: https://github.com/pranjal710/osrf
15:58:42 <dbwells> #info senator and pranjal710 report that pranjal710 completed PHP client bindings for OpenSRF.  This essentially means PHP users now have an easy and consistent way to call any opensrf method using fieldmapper objects in the parameters and getting them in results, too, based on the IDL published by the host being contacted.  pranjal710 is working on getting it into PEAR for PHP users' convenience.
15:59:00 <dbwells> #info https://github.com/pranjal710/osrf
15:59:34 <tsbere> Joseph had another meeting to attend today. From my own testing it seems he got everything working up through dojo 1.6, and started dealing with the massively annoying changes that were made for 1.7 on.
16:00:41 <tsbere> For reference, apparently dojo no longer supports the require syntax used up through 1.6, which breaks any hope of compatibility without major rewriting. :(
16:01:11 <denials> http://evergreengsoc.blogspot.ca/2012/08/little-shoves.html is joseph's most recent blog post, which sounds like he made a huge amount of progress. and unit tests!
16:01:23 <jeff> tests++
16:01:37 <tsbere> He has indicated that, time permitting, he would like to continue working on the changes
16:02:40 <jeff> gsoc++ # and by that, i mean everyone involved
16:03:09 <dbwells> #info tsbere reported on behalf of his student (joelewis) -- joelewis seems to have everything working up through dojo 1.6, and started dealing with the massively annoying changes that were made for 1.7 on.  For reference, apparently dojo no longer supports the require syntax used up through 1.6, which breaks any hope of compatibility without major rewriting.
16:03:20 <denials> dojo 1.7/1.8 might be a pretty great thing to aim for for evergreen 2.4
16:03:31 <jeff> joelewis++
16:03:35 <tsbere> Also, Joseph has indicated he made up a master dev vm of his own that he thinks the community might like, though I haven't gotten additional details like what it runs on yet from him.
16:03:38 <denials> joelewis++
16:04:30 <dbwells> Anything else to say about GSoC before moving on?
16:05:13 <dbwells> #topic Release Info
16:05:14 <denials> Lessons learned?
16:06:29 <denials> I'm wondering if we could keep the level of surprise about how well things are going down if we treated future GSoC students as full-fledged Evergreen developers from day one
16:07:21 <denials> It's amazing & awesome that all of the student devs this year want to keep contributing, any way you look at it
16:07:41 <senator> agreed
16:08:19 <dbwells> Yeah, I actually find it a little moving, but I'm soft.
16:08:58 <denials> But maybe for next year, if we're selected to participate again, GSoC participants should be filling out the dev meeting availability polls, opening bugs against our code (well, mine mostly I'm sure!), etc :)
16:11:04 <denials> I have a feeling that we could all learn a lot from the GSoC participants as they go along - Dojo.new, Java/Android, PHP/PEAR, ICU - all great stuff! We're lucky to have these devs in our midst.
16:11:18 <denials> And lucky to have mentors who were willing to step up to help them out, too
16:12:08 <senator> hear hear
16:12:27 <senator> next year, more up front effort to bring the gsoc students further out into the daylight
16:12:51 <senator> because they're doing great work anyway, and let's get it recognized sooner
16:13:35 <JoeLong_UDJ> Hey, quick question.  We're migrating from a server with Evergreen 2.0.5 to one with 2.2.0.  We've exported the MARC records (including assets) into UNIMARC format then try to import the results into the new server.  The records all import and about half of the assets are imported, the other half error out with a pgsql error message "function "label_normalizer" line 16 at EXECUTE statement".
16:13:54 <dbwells> We should definitely keep these thoughts going, but since the meeting is running long already, I think we need to talk now about OpenSRF releases.  Anything?
16:13:55 <JoeLong_UDJ> Anyone encountered something like this while using the Evergreen Import Marc Records interface?
16:14:05 <JoeLong_UDJ> sorry if I'm interrupting anyting
16:14:07 <JoeLong_UDJ> *anything
16:14:13 <jeff> hi, JoeLong_UDJ! there's actually a meeting going on at this instant, but if you stick around there might be some able to give you some advice/info.
16:14:26 <JoeLong_UDJ> that'd be perfect, thanks.  Sorry for stepping on any toes.
16:14:30 <JoeLong_UDJ> :D
16:14:46 <denials> berick: did CORS get integrated?
16:16:02 <denials> dbwells: doesn't look like it (logs say "no")
16:17:04 <dbwells> #info OpenSRF - no release info to report
16:17:37 <dbwells> berick: Next, 2.3.x release update.
16:17:50 <berick> denials: no.  never heard any response to my last question in the lp.  (pinged github too).  after that i let it sit
16:18:36 <berick> 2.3.x.. RC1 Friday, probably friday night (traveling most of the day)
16:18:42 <berick> so..
16:18:49 <berick> get yr bugs in while they're hot!
16:19:08 <dbwells> berick: thank you
16:19:16 <dbwells> #info 2.3.x.. RC1 Friday, probably friday night
16:19:36 <dbwells> senator: latest on 2.2.x release?
16:21:14 <senator> 2.2.3 should be due in late september. that gives it a little time to accumulate bugfixes since 2.2.2, i should think. that's barring anything to accelerate the release, like any security bugs that should turn up
16:21:50 * denials will try to sync up with senator on the next 2.1.x release as well
16:22:16 <dbwells> I know it's a little late, but everyone can feel free to 'info' their own statements.  That works, I think.  Then I don't need to repeat so much.
16:22:25 <dbwells> #info 2.2.3 should be due in late september. that gives it a little time to accumulate bugfixes since 2.2.2, i should think. that's barring anything to accelerate the release, like any security bugs that should turn up
16:22:34 <denials> #info denials will try to sync up with senator on the next 2.1.x release as well
16:22:43 <denials> aside: did we forget to set the eg_version variable in the upgrade scripts for the most recent releases?
16:23:22 <senator> curses.
16:24:01 * denials curses too
16:25:07 <senator> also, i gotta be afk for a bit. sorry, but if i remembered to put it on the agenda, i wanted to start a discussion soon about when we can nominate and add new core committers  (sic!)   so be thinking about it. sorry for skipping ahead and not sticking around to discuss immediately
16:25:10 <denials> #action denials to patch make_release so that it sets the eg_version var on the upgrade scripts
16:25:59 <dbwells> ok, last topic
16:26:02 <dbwells> #topic Hack-a-way
16:26:43 <dbwells> This is under "release info" on the agenda, but I think it was meant as a general topic.
16:27:54 <dbwells> Can anyone from Equinox report on overall expected attendance?
16:28:36 <berick> 3 confirmed attendees apart from ESI-ites
16:28:46 <berick> mo4r peoplez plz!
16:29:10 <gmcharlt> OR ELSE THE KIDNAPPING SQUADS WILL BE LOOSED!
16:29:18 <berick> gmcharlt++
16:29:19 <gmcharlt> (did I say that out loud?)
16:29:20 * tsbere has been waiting on final hotel details and such before making final plans, due to having to consider the GSoC mentor summit as well
16:30:02 * denials is still waiting on word from university librarian on budget. ~$1000 round-trip for airfare, unless a seat sale comes up :/
16:32:02 <dbwells> Is there anything else people wanted from this agenda item?  I fear the hour-thirty mark of the meeting might not be the best place for productive discussion :)
16:32:02 <berick> tsbere: what else do you need to know about the hotel?
16:33:04 <tsbere> berick: Amongst other things I also need two people to not be on vacation at the same time in the office. >_>
16:34:19 * denials is in favour of calling it a wrap
16:34:42 * dbwells raises the gavel
16:34:56 <dbwells> #endmeeting