13:00:18 <gmcharlt> #startmeeting Evergreen Developer Meeting, 1 May 2013
13:00:18 <pinesol_green> Meeting started Wed May  1 13:00:18 2013 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:18 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:00:18 <pinesol_green> The meeting name has been set to 'evergreen_developer_meeting__1_may_2013'
13:00:25 <gmcharlt> #info agenda is http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-05-01
13:00:37 <gmcharlt> #topic usual round of introductions
13:00:42 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
13:01:02 <eeevil> #info eeevil = Mike Rylander, Equinox
13:01:04 <dbs> #info dbs = Dan Scott, Laurentian University
13:01:06 <tsbere> #info tsbere = Thomas Berezansky, MVLC
13:01:14 <bshum> #info bshum = Ben Shum, Bibliomation
13:01:16 <ktomita> #info ktomita = Kyle Tomita, Catalyst IT Services
13:01:29 <dboyle> #dboyle = David Boyle, Catalyst IT Services
13:01:34 <Dyrcona> #info Dyrcona = Jason Stephenson, MVLC
13:01:38 <dbwells> #info dbwells = Dan Wells, Calvin College
13:01:43 <acoomes> #info acoomes = Andrew Coomes, Catalyst IT Services
13:01:43 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
13:02:08 <phasefx_> #info phasefx_ = Jason Etheridg - Equinox
13:02:22 <senator> #info senator = Lebbeous Fogle-Weekley, Equinox
13:02:23 <dboyle> #info dboyle = David Boyle, Catalyst IT Services
13:03:06 <fparks> #info fparks = Fredrick Parks, Catalyst IT Services
13:03:07 <gmcharlt> thanks -- the one action item from the previous meeting relates to the 2.4 release, so let's discuss it then
13:03:11 <gmcharlt> so moving on
13:03:14 <rfrasur> #info rfrasur = Ruth Frasur, Evergreen Indiana
13:03:22 <gmcharlt> #topic Evergreen 2.5 release manager proposal
13:03:37 <smyers_> #info smyers_ = Scott Myers, Catalyst IT Services
13:03:58 <gmcharlt> I think dbwells has submitted the only proposal to be release manager for 2.5
13:04:10 <gmcharlt> dbwells: could you take a moment to discuss your proposal?
13:04:39 <dbwells> Sure.
13:04:58 <gmcharlt> #info Dan Wells' RM proposal is at http://libmail.georgialibraries.org/pipermail/open-ils-dev/2013-April/008960.html
13:05:37 <yboston> #info Yamil Suarez - Berklee College of music
13:05:39 <dbwells> There isn't a whole lot to it.  The main difference from previous releases would be additional milestones to try and get a more steady stream of merges to master.
13:06:06 <dconnor> #info dconnor = Daniel Connor, Catalyst IT Services
13:06:14 <dbwells> The second highlight will be an effort to systematically clean up some whitespace in the Perl code.
13:06:47 <dbwells> Also, sorry that my lines don't wrap in that web view.
13:06:54 * dbwells blames GroupWise
13:07:10 <dbs> groupwisee-- # /me hatessesss it too
13:07:30 <bshum> http://markmail.org/message/idbm4u57nedcxkk5 might be a nicer view
13:07:41 <gmcharlt> bshum++
13:07:44 <bshum> For those of us reading along.
13:07:56 <dbwells> bshum: thanks!
13:07:59 <gmcharlt> OK, questions and comments for dbwells?
13:09:15 <dbs> dbwells: one of the roles we envisioned for release managers initially was that of being a communication bridge between devs and the broader community
13:09:33 <dbs> any thoughts on whether & how you would play that role?
13:12:02 <dbwells> dbs: Yes.  As mentioned in the proposal, there would be some sort of communication (I'll call it a newsletter) at each of the milestone breaks.  Assuming the milestones work and things actually happen, there should be meaningful things to say.  So, I will more or less promise at least monthly updates, including an extra at the outset to set some expectations.
13:13:07 <gmcharlt> dbwells: another thing to note: the RM has a standing invitation to the Oversight Board meetings, which occur monthly.  Would you be able to attend some or all of them?
13:13:24 <dbs> dbwells: okay, that's primarily dev -> community; any community -> dev communication role?
13:14:32 <dbwells> gmcharlt: I expect that I can attend all of them.
13:15:50 <eeevil> gmcharlt: I actually wasn't aware of the, or if I was made aware I forgot entirely...
13:16:09 <gmcharlt> eeevil: to be clear, this is a new invitation, decided at the conference
13:16:18 <eeevil> ah, k
13:16:59 <dbwells> dbs: I think the newsletters will provide opportunity for feedback, as they will be both a summary of what was done, and a preview of what is coming.  Other than that, I am open to suggestions.
13:18:31 <gmcharlt> Another comment: while I'm not opposed to tab cleanup, I think doing it in three lesser swoops rather than one fell swoop would be more disruptive and take more time to organize.  Could you expand more on why you're proposing three?
13:22:13 <DPearl> #info Dan Pearl -- C/W MARS
13:23:45 <dbwells> gmcharlt: Well, there are a few reasons behind that.  Maybe they won't work out in practice, but first (in theory), there is never time when nobody is working on anything, but there are times when nobody is working on something.  I think we can make an effort to target whitespace fixes to code not being actively developed first.
13:24:30 <dbwells> This also provides an opportunity to make sure the process isn't a disaster, or at least limits the disaster to a smaller scale.
13:24:57 <dbwells> It doesn't necessary need to be three.
13:25:11 <gmcharlt> warrants additional discussion on the list
13:25:33 <dbwells> Yes, definitely, especially if anyone else has ever managed a change like that.
13:26:15 <gmcharlt> are there other questions or comments regarding Dan's proposal?  I'm now starting a 2-minute window for folks who have them to speak up and either ask (or announcing that they're going to ask very soon now)
13:26:23 <rfrasur> Would this be dealing with live code?
13:26:27 <eeevil> not to spend too much more time on that, but PG does it in a very coordinated way in one go
13:26:43 <eeevil> my only comment is:
13:26:47 <eeevil> dbwells++
13:27:10 <bshum> dbwells++ # I like the proposed timetable.
13:27:29 <eeevil> rfrasur: no, this is just cleanup of the source repository
13:27:35 <bshum> (though personally I might have labeled it alpha1, alpha2, alpha3 and just have more directed milestone efforts)
13:27:36 <rfrasur> k, ty
13:27:42 <bshum> But that's labels
13:27:49 <bshum> The core idea, I'm behind.
13:28:31 <bshum> unless you mean that the milestone is just to get code merged vs. cutting releases?
13:28:36 <bshum> And that for milestones they aren't cut
13:29:28 <dbwells> bshum: Yes, milestones are only meant for merging.  I don't call them alphas, since I think that implies some level of completeness which we won't have yet.
13:29:34 <jcamins> For what it's worth, a surprising number of people have installed the milestone releases I've been cutting for Koha.
13:29:35 <dbs> Would be nice if we could at least "git tag" the milestones, to have some release artifact
13:29:56 <jcamins> Non-core-developer types, even.
13:30:27 <bshum> dbwells: That makes sense.  Thanks for clarifying that.
13:30:35 * dbs likes the "ongoing project" approach, would be easy to adapt to, say, adding X% of unit test coverage per milestone for future releases, etc
13:30:48 <dbs> dbwells++
13:30:51 <gmcharlt> and it would be good if the milestones are aimed at being releasable to some degree, whether or not a tarball is actually cut
13:31:00 <gmcharlt> OK, looks like there are no other pending questions, so I'm opening the vote up for three minutes.
13:31:06 <gmcharlt> #startvote Should Dan Wells be Release Manager for Evergreen 2.5?  Yes, No, Abstain
13:31:06 <pinesol_green> Begin voting on: Should Dan Wells be Release Manager for Evergreen 2.5? Valid vote options are Yes, No, Abstain.
13:31:06 <pinesol_green> Vote using '#vote OPTION'. Only your last vote counts.
13:31:08 <Dyrcona> gets us closer to rolling releases...
13:31:21 <gmcharlt> (vote by doing #vote Yes, #vote No, or #vote Abstain)
13:31:26 <Dyrcona> #vote Yes
13:31:27 <DPearl> #vote Yes
13:31:28 <bshum> #vote Yes
13:31:31 <eeevil> #vote Yes
13:31:35 <gmcharlt> #vote Yes
13:31:43 <phasefx_> #vote Yes
13:32:04 <kmlussier> #vote Yes
13:32:23 <senator> #vote Yes
13:32:34 <acoomes> #vote yes
13:32:59 <paxed> oh, dev meeting...
13:33:07 <gmcharlt> acoomes: I'm not positive, but MeetBot's voting may be case-sensitive
13:33:20 <tsbere> #vote Yes
13:33:21 <acoomes> gmcharlt: apologies
13:33:22 <bshum> Guess we'll find out.
13:33:25 <acoomes> #vote Yes
13:33:34 <dbs> #vote yes
13:33:53 <dbs> #vote Yes
13:34:00 <eby> #vote hell yes
13:34:00 <pinesol_green> eby: hell yes is not a valid option. Valid options are Yes, No, Abstain.
13:34:07 <smyers_> #vote Yes
13:34:10 <kmlussier> eby++
13:34:13 <gmcharlt> eby++ # that answers the question
13:34:33 <eby> #vote yes
13:34:47 <gmcharlt> OK, the three minutes are up
13:34:49 <gmcharlt> #endvote
13:34:49 <pinesol_green> Voted on "Should Dan Wells be Release Manager for Evergreen 2.5?" Results are
13:34:49 <pinesol_green> Yes (13): kmlussier, DPearl, smyers_, eby, acoomes, Dyrcona, gmcharlt, phasefx_, bshum, senator, dbs, tsbere, eeevil
13:34:57 <dbwells> Thanks, everyone.  I absolutely will not let you down.
13:35:06 <kmlussier> dbwells++
13:35:06 <gmcharlt> #agreed Dan Wells is elected Release Manager for Evergreen 2.5
13:35:11 <gmcharlt> dbwells++
13:35:13 <rfrasur> dbwells++
13:35:27 * paxed is on vacay, so not really here.
13:35:47 <gmcharlt> #topic Evergreen 2.5 road map
13:35:55 <gmcharlt> #info Road map is at http://evergreen-ils.org/dokuwiki/doku.php?id=faqs:evergreen_roadmap:2.5
13:36:22 <gmcharlt> so, as folks can see, the road map has some projects, but perhaps fewer than I would expect
13:36:45 <paxed> perhaps there should be something about i18n in there.
13:37:20 <gmcharlt> so general call: do folks know of projects that they expect to have ready for Evergreen 2.5?  even more so if they would be ready for an initial look by the first milestone at the beginning of June?
13:37:24 * bshum assumes that we should put down the new proposed patron interface somewhere on that page?
13:37:37 <jeff_> dbwells++
13:38:26 <gmcharlt> paxed: I've added a heading for i18n
13:38:34 <gmcharlt> bshum: yes
13:39:00 <jeff> i'd like to get added content by record id in 2.5. i was confirming resources before adding it to the roadmap.
13:39:09 <gmcharlt> jeff++
13:39:53 <jeff> initial version of restful api is likely also.
13:40:02 <eby> jeff: is that PALs NCIP same is Mel project
13:40:15 <bshum> I did start to move some bugs over to target the 2.5 series for things in LP that didn't make the cut for 2.4's beta.  But we might want to get some feedback from the people who own those bugs.
13:40:22 <bshum> (it was a long list)
13:40:44 <jeff> eby: good question for Dyrcona -- i know he was looking at the iNCIPit code with an eye toward seeing if it would be suitable.
13:41:03 <gmcharlt> bshum: good idea
13:41:25 <kmlussier> We may have some projects to add in a few weeks, but I'm waiting until we're certain that we're going to fund them. And that they can be done in time for 2.5.
13:41:44 <Dyrcona> The first NCIP line is me, and it has nothing to do with iNCIPit or the MNPALS NCIP project.
13:42:26 * dbs is likely to keep on refining schema.org in tpac, as long as people tolerate it, but unlikely to have anything by June
13:43:01 * bshum wants to work on the new code dbs suggested for mobile catalog.  And mobile in general.
13:43:30 <bshum> But I didn't put it on the track till I get some more feedback.  Been thinking to send out an email about it since it seems a lot of folks have been inquiring.
13:43:32 <jeff> dbwells: will there be a hard cut-off for 2.5 roadmap entries / new features, or if not, do you have an "ideal" time for roadmap entries?
13:43:36 * dbs was holding off on more responsiveness work until gsoc selection was done (hadn't realized that was a gsoc project -- oops!)
13:43:43 <bshum> That too. :)
13:44:00 <gmcharlt> re NCIP, I'm (a) glad there's interest and (b) even happier that we may have more working code to look forward to AND a more open discussion of it
13:44:38 <Dyrcona> re NCIP, it's also a poster child for how NOT to define a standard.
13:44:48 <eeevil> gmcharlt: I'm still sad that "NCIP" is not considered a slur...
13:45:11 * gmcharlt will send out another call for road map entries with a "deadline" of May 15th
13:45:12 <eeevil> Dyrcona: you mean "meh ... throw some XML at each other and work it out" isn't enough for you?
13:45:29 <Dyrcona> Honestly, part of me says implementing NCIP is a waste of time, but the part that likes getting a paycheck, says why not?
13:45:46 <eby> i know the feature that came up at conference over and over was bug #1167626 but looks like no one assigned
13:45:46 <pinesol_green> Launchpad bug 1167626 in Evergreen "FEATUREREQ: drones should reconnect to database on disconnect" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1167626
13:46:12 <gmcharlt> I'm considering starting one up for 2.6 to catch overflow of proejcts that are committed to but which aren't expected to be done in time for 2.5
13:47:08 <dbwells> jeff: I think the only "hard" cutoff will be beta, as has been the case for all previous releases.
13:47:14 <gmcharlt> eby: matter of finding cycles, I suspect; I agree that it might be useful
13:47:43 <eeevil> eby: I am afeared of that. the use case doesn't support the code complexity and danger (spinning reconnect attempts, etc), IMO
13:48:31 <gmcharlt> eeevil: hence my "might" :) -- it certainly isn't just a matter of plugging in a naive "reconnect if I've lost connection"
13:48:34 <dbwells> jeff: That said, if anyone wants their contributions and features highlighted, there is probably no better way that to get in for the first milestone.
13:49:06 <gmcharlt> #action gmcharlt will put out another call for 2.5 road map items and start a 2.6 road map
13:49:15 <gmcharlt> moving on
13:49:21 <gmcharlt> #topic Google Summer of Code update
13:50:13 <bshum> #info Student applications due by this Friday May 3.
13:50:38 <bshum> So far, we've got a few proposals in melange.  I know that Dyrcona and I have looked at a few
13:50:59 <bshum> Some folks have wandered through IRC.  At least one patch has already made it to master from a student looking around.
13:51:14 <dbwells> To echo a concern from the GSoC list, I am concerned at the low number of applicants so far.  Granted, many will come in the next few days.
13:51:36 <bshum> I have to reply to a few inquiries in my inbox, not sure how the others have been getting if any.
13:51:52 <bshum> In my replies, I'm suggesting them to bring ideas/questions forward on the main mailing lists too.
13:51:52 * dbs had one student approach him directly with a proposal today, to which I said "Get your proposal into melange now!"
13:51:54 <bshum> Or via IRC
13:52:20 <dbs> (also directed said student to IRC & mailing list)
13:52:22 <gmcharlt> dbwells: I'm actually happy about there being fewer applications
13:52:28 <bshum> dbwells: It does seem quiet, not that I have experience with volume of applications.
13:52:45 * bshum assumes it to be the lack of that "android" tag that gmcharlt reminded him to remove.
13:53:01 <gmcharlt> some of the ones thus far are just placeholders, but even that aside, compared to last year there is much less spam and the completed applications are better
13:53:21 <gmcharlt> bshum: also, GSoC lowered the number of proposals that students can make
13:53:22 <dbs> "PHP" tag was a great attracter as well, last year. "Oh PHP is easy!" heh.
13:54:13 <gmcharlt> moving on
13:54:20 <gmcharlt> #topic Bug Tracking
13:54:23 * dbs notes there was a question about the gsoc full-text search project on the mailing list that got no replies
13:54:46 <gmcharlt> bshum: (must be brief, sorry) anything to expand on what you said?
13:55:19 <bshum> gmcharlt: What I wrote in the agenda is basically all I needed to say.  I guess I just want to avoid spamming everybody with unnecessary milestone churn
13:55:31 <bshum> For bug reporters though, that means that it's helpful to note versions affected
13:55:39 * gmcharlt bows in the general direction of Connecticut
13:55:41 <bshum> And perhaps mark bugs to nominate them for specific series targets
13:56:06 <jonadab> Supposing I _thought_ I had followed the OpenSRF install instructions completely, including the math test (which works) and ldconfig, but I get the libopensrf not found error when attempting to configure OpenILS...  is there some obvious thing I have probably forgotten?
13:56:23 <bshum> The release team still controls bug series targeting, but it certainly helps when folks mention their affected versions and/or add nomination requests.
13:56:29 <jeff_> jonadab: meeting in progress, but wrapping up shortly. stick around!
13:57:23 <bshum> I suppose I'll also add that I'll announce that via lists
13:57:42 <gmcharlt> #info bshum has been thinking about ways to reduce LP email churn via different use of milestones and series
13:57:57 <gmcharlt> #action bshum to email lists about bug tracking changes
13:58:04 <gmcharlt> #topic Evergreen 2.4 release
13:58:31 <gmcharlt> eeevil: what's the scoop?
13:59:28 <eeevil> well, there's one (low impact, relative to other security bugs) outstanding security bug that I'd like to see tested more broadly, but I'm on the verge of pushing it in
13:59:39 <eeevil> then I'll be cutting the release
14:00:02 <eeevil> thanks to all that have tested the RC, and particularly to Dyrcona for the tpac AC fix
14:00:25 <eeevil> so ... tomorrow
14:01:55 * gmcharlt will write a patch to update the upgrade instructions today
14:02:28 <gmcharlt> also, from last meeting, there was a relevant action item: Dyrcona, bshum, gmcharlt to test and recommend whether XUL 15 should be included in 2.4
14:02:31 <eeevil> gmcharlt: thanks ... in that, we'll need to note the post-db-upgrade shell script and it's proper incantation
14:02:37 <gmcharlt> eeevil: indeed
14:02:54 <eeevil> its, even
14:03:06 * eeevil hides from bob the angry flower
14:03:22 <gmcharlt> eeevil: to invoke it successfully, proper grammar is a must! ;)
14:03:53 <gmcharlt> Dyrcona: bshum: comments on XUL 15?  I have not had time to test it after all
14:03:55 <bshum> gmcharlt: For myself, I'm not ready to commit to using XUL 15 for 2.4.
14:04:06 * Dyrcona agrees with bshum.
14:04:07 <bshum> I think I'd prefer to target that towards 2.5.
14:04:27 <gmcharlt> OK, I think that's definitive
14:04:27 <Dyrcona> What little testing I did, I saw some staff client issues, but should look more.
14:04:45 <phasefx> for giggles, I tried XUL 21 and didn't see immediate breakage
14:04:49 <eeevil> bshum: XUL 15 will require actively enabling E4X, correct?
14:05:07 <dbs> eeevil: no, that's around XUL 19 (IIRC)
14:05:11 <dbs> and then it goes away
14:05:15 <eeevil> dbs: ah, ok, thanks
14:05:17 * phasefx sighs
14:05:37 <eeevil> so sad that E4X didn't take off.... it's FANCY
14:05:43 <dbs> https://developer.mozilla.org/en-US/docs/E4X
14:06:40 <gmcharlt> #info eeevil will cut 2.4.0 tomorrow
14:06:53 <gmcharlt> #agreed 2.4.0 will stick with using XUL 14
14:07:17 <gmcharlt> any last-minute announcements?
14:07:56 <gmcharlt> going once
14:08:09 <gmcharlt> going twice
14:08:16 <gmcharlt> #endmeeting