14:13:44 <bshum> #startmeeting Developer Meeting 2013-06-12
14:13:44 <pinesol_green> Meeting started Wed Jun 12 14:13:44 2013 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:13:44 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:13:44 <pinesol_green> The meeting name has been set to 'developer_meeting_2013_06_12'
14:13:52 <bshum> #topic Introductions
14:14:07 <bshum> #info bshum = Ben Shum, Bibliomation
14:14:35 <phasefx> #info phasefx = Jason Etheridge, Equinox
14:14:37 <jeff_> #info jeff = Jeff Godin, TADL
14:14:55 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
14:14:55 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
14:15:04 <eeevil> #info eeevil = Mike Rylander, ESI
14:15:16 <senator> #info senator = Lebbeous Fogle-Weekley, ESI
14:15:48 <bshum> As folks arrive, feel free to announce yourselves.  Sorry we'll try and make this meeting quick and helpful.
14:16:51 <bshum> #topic Action items from the last meeting
14:17:17 <bshum> #info 1. gmcharlt will put out another call for 2.5 road map items and start a 2.6 road map
14:17:33 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
14:17:35 <bshum> He didn't speak up, but I think that occurred to add more road map items.
14:17:50 <csharp> #info csharp = Chris Sharp, GPLS
14:17:54 <bshum> Though I'm unsure about the 2.6 roadmap.
14:17:58 <tsbere> #info tsbere = Thomas Berezansky, MVLC
14:18:09 <gmcharlt> #info gmcharlt = Galen Charlton, ESI
14:18:14 <bshum> gmcharlt: Deferred to the next meeting I guess on the 2.6 part at least?
14:18:26 <gmcharlt> bshum: yeah
14:18:51 <DPearl> #info DPearl = Dan Pearl, C/W MARS
14:18:59 <bshum> #action Start on the 2.6 development road map page
14:19:10 <bshum> #info 2. bshum to email lists about bug tracking changes
14:19:26 <paxed> #info paxed = Pasi Kallinen, Regional Library of Joensuu
14:19:31 <bshum> #action bshum to summarize bug tracking based on feedback from developers
14:19:50 <bshum> I'm deferring this as well, since we just put that to summary just yesterday thanks to dbwells.
14:20:03 <bshum> #topic GSOC reports
14:20:39 <bshum> #info laque (Dmitry Nechai) was accepted as the student for this year's GSOC.  He'll be working on a library dashboard with stats, etc.
14:21:18 <csharp> nice
14:21:26 <bshum> #info Dyrcona and bshum are primary mentors and will be involved in mentoring the student as the summer progresses.
14:21:50 <bshum> Not sure if Dyrcona has more to add at this time.  We've sent an email welcoming them and will hopefully start getting some active communication going.
14:22:22 <kmlussier> Dyrcona isn't around right now.
14:22:29 <bshum> Moving on for now then.
14:22:38 <bshum> #topic OpenSRF release
14:22:45 <bshum> Anything for this?
14:22:51 <bshum> Other than [placeholder] :)
14:23:53 <bshum> Alright
14:24:04 <bshum> #topic Evergreen releases
14:24:15 * bshum turns over to dbwells for 2.5 news
14:24:16 <dbs> #info dbs = Dan Scott, Laurentian University
14:24:50 <dbwells> Sure.  I sent out a wrap-up email for m1 this morning, so I am not sure how many have seen that yet.
14:25:00 <dbs> 0.5++
14:25:08 <bshum> #link Wrapup email on 2.5-m1 - http://markmail.org/message/u6fgf2zqicuaskra
14:25:18 <bshum> dbwells++
14:25:38 <eeevil> huh ... never saw that
14:26:07 <dbwells> In essence, with a few extra days and extra pleas, we met the initial (non dreamy) goal of cutting the list in half.
14:26:44 <eeevil> dbwells++ #pleas
14:26:52 <dbwells> I haven't heard anything along the lines of "master is totally broken" yet, so I think it was a success.
14:27:55 <dbwells> One thing I wanted to bring up is that I deferred on the big whitespace push due in part to lack of feedback.  Anyone have anything to add on that topic?
14:28:20 <eeevil> I'm a-feared, but not for any logical reason I can point to
14:28:30 <kayals> How do reports work against multiple databases? How can I configure the same under reporter section in the opensrf.xml file.
14:28:33 <dbwells> Yeah, same here :)
14:28:34 <phasefx> the diff -b thing gmcharlt pointed out was reassuring
14:29:01 <bshum> kayals: Bear with us for a moment, there's a developer meeting happening for the next little while.  We'll be done soonish.
14:29:08 <kayals> sure.
14:29:27 <gmcharlt> dbwells: one thing I didn't specifically test was that code using heredocs remained unbroken
14:29:38 <gmcharlt> (or at least in its current state of brokeness or not ;)
14:30:01 <eeevil> gmcharlt: that's where my fear lies, but dbwells' logic seems sound in first analysis
14:30:19 <gmcharlt> agreed, the logic seems sound
14:30:28 <dbwells> At a few stages I ran a recursive 'perl -c' over the whole set, and at this point the output from those is identical.
14:30:28 <eeevil> the centroid of my fear, if you will
14:30:37 <dbwells> FWIW
14:30:45 <eeevil> dbwells: one question
14:30:58 <dbwells> So, at least all the HEREDOCs find their ends.
14:31:32 <eeevil> had you considered setting up a more complex perltidy config instead of sed+expand? (curious about methodology more than requesting an alternate approach)
14:32:24 <paxed> dbwells: one small breakage in master, bug 1158211
14:32:24 <pinesol_green> Launchpad bug 1158211 in Evergreen "Empty translatable string in 950.data.seed-values.sql" (affected: 1, heat: 6) [Low,Triaged] https://launchpad.net/bugs/1158211
14:34:33 <bshum> So, for the notes
14:34:43 <eeevil> paxed: that's not related to the whitespace expansion, though, is it?
14:34:51 <paxed> eeevil: no
14:34:55 <eeevil> oh, you just mean breakages in general, nevermind me
14:35:23 <dbwells> eeevil: I did try a number of different perltidy configs, but almost every option seemed a little to aggressive to be run over every file.  Basically, I am thinking we should concentrate on taking the smallest step which makes the biggest difference.
14:36:07 <gmcharlt> agreed -- settling on a perltidy config would be nice, IMO, but would definitely entail more than just whitespace
14:36:39 <eeevil> certainly ... thanks!
14:38:50 <dbwells> so... who wants to sign off?
14:39:17 <bshum> On the small steps first?  +1 to small steps
14:39:19 <gmcharlt> my view -- I'm comfortable with pushing the whitespace change provided somebody explicitly tests the heredocs; alas, I doubt I have any tuits for that this week
14:39:44 <gmcharlt> and in any event, I'd rather that it be done, if done at all, sooner rather than later
14:41:32 <eeevil> dbwells: is it only perl modules (*.pm), or all perl-type files?
14:41:33 <dbwells> Well, let's not hold up the meeting.  I'll run a few more tests, make sure the branch is up-to-date, then see if I can round up a volunteer to jump with me.
14:42:00 <bshum> Adding some dates to the notes
14:42:17 <bshum> Does anyone have anything about Dan's suggested dates for the next round of commit action?
14:42:21 <berick> heh, dbwells and louise, flying over the cliff
14:42:36 <bshum> They seemed reasonable to me.
14:43:15 <bshum> #info 7/1 - suggested last day for targetting bugs/features at 2.5-m2
14:43:27 <bshum> #info 7/2-7/12 - Suggested period to focus energy on reviewing/committing m2
14:43:27 <bshum> bugs/features
14:44:02 <bshum> #info dbwells working on whitespace cleanup; will do more tests and find others
14:44:22 <dbwells> eeevil: The command as written is limited to the *.pm.  I looked briefly for other common file patterns, and came up empty.  I also grepped for tabs in the whole perlmods dir after running the commands, and found just one in a test file, so I figured that was close enough.
14:44:40 <bshum> Anything else about 2.5 before we move on?  I'd like to have a short word on the next maintenance releases.
14:44:52 <eeevil> (one last thing re whitespace ... it's really just HEREDOCs with space in front. for those that want to test, it looks like circ, actor, cat, search and resolver-resolver services, and added content, exporter, tpac and supercat web stuff could all break .... if they're not broken, things are looking good)
14:45:43 <eeevil> I found that using `ack '<<"' --type=perl|grep \.pm|cut -f1 -d:|sort -u`
14:46:22 <dbwells> eeevil: Thanks for the list.  In my testing, I believe every service at least started, but it never hurts to triple-check.
14:46:24 <eeevil> and `ack "<<'" --type=perl|grep \.pm|cut -f1 -d:|sort -u` adds booking and bib batch update to the list to test
14:47:12 <dbwells> bshum: nothing from me
14:47:21 <bshum> Cool, eeevil++ showing us the things to check :D
14:47:30 <bshum> So next
14:47:32 <bshum> #info Maintenance releases are scheduled for June 19
14:48:04 <bshum> While I was cleaning up bugs from 2.2/2.3 the last round, I marked a bunch of things with specific targets to the next milestones, 2.3.8 and 2.2.10.
14:48:14 <bshum> Specifically these were bugs with backport requests, but had yet to be done.
14:48:25 <bshum> Otherwise, I left other bugs untargeted for now.
14:48:56 <bshum> #link Link to 2.3.8 targeted bugs: https://launchpad.net/evergreen/+milestone/2.3.8
14:49:10 <bshum> #link Link to 2.2.10 targeted bugs: https://launchpad.net/evergreen/+milestone/2.2.10
14:49:26 <eeevil> for those following along with bug 1187433, there are now 2 branches on that, both for testing, both to repair 2.4-era regressions. one's been tested and one is new as of this morning. That's the most important outstanding 2.4/master bug I would like to appeal for eyes on for the june 2.4 release
14:49:26 <pinesol_green> Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1187433
14:49:26 <bshum> I assigned them to the maintainers, but that's something we can help out with.
14:49:48 <eeevil> (since were talkin' maint releases)
14:49:56 <bshum> Oh right.
14:50:10 <bshum> #link Link to 2.4.1 targeted bugs: https://launchpad.net/evergreen/+milestone/2.4.1
14:50:15 <dbs> We should get a 2.4.0 release announcement out some time
14:50:21 <bshum> I forgot we're doing maintenance on that too :(
14:50:32 <eeevil> dbs: touche'
14:52:30 <bshum> So, general request to help merge bugs for the maintenance releases too.  Thanks all.
14:53:11 <bshum> Which leads us to the bug squashing agenda item...
14:53:18 <bshum> #topic Bug squashing
14:53:25 * bshum pokes kmlussier
14:53:57 <dbwells> Can somebody remind me when 2.2 support is supposed to end?  (or, where that information exists?)
14:54:11 <kmlussier> I added this to the agenda before a lot of the backlog was pushed into master.
14:54:14 * senator would like to be reminded too
14:54:14 <rfrasur> not before December 2013?
14:54:40 <bshum> It's 15 months of support (two 6-month release cycles and 3 months of security fixes)
14:54:41 <kmlussier> I thought it might be useful to return to those pullrequest meetings we used to do a year or two ago. To help keep on top of the bugs.
14:55:12 <csharp> released last June, right?
14:55:25 <kmlussier> And then I had also seen the bug squashing day that Koha did last month, and I thought that might be another good way to attack the bug backlog.
14:55:25 <senator> yes
14:55:30 <kmlussier> So I'm just throwing those ideas out there for feedback.
14:55:32 <bshum> 2.2.0 was June 13, 2012.
14:55:41 <bshum> So... September?
14:55:45 <csharp> yeah
14:55:55 <senator> so the 2.2 series is out of general bugfix releases, and gets security releases through september
14:55:59 <bshum> Well actually this is the last release with general backports.
14:56:00 <rfrasur> (foiled)
14:56:04 <bshum> It'll be security releases after that.
14:56:08 <mrpeters> lets remind people....2.2 is not going to STOP working
14:56:14 <rfrasur> of course not
14:56:38 <rfrasur> But, does that mean that bug reports will lower priority or no priority?
14:56:49 <rfrasur> other than security issues?
14:56:55 <mrpeters> i dont think they will be valid unless they impact later versions
14:57:00 <csharp> rfrasur: pretty much, yeah
14:57:02 <mrpeters> but they wont get backported to 2.2
14:57:09 <rfrasur> k
14:57:10 <mrpeters> unless someone takes pity
14:57:24 <rfrasur> meh...no need for pity.
14:57:25 <csharp> (or unless your support vendor can do it)
14:57:48 <mrpeters> you'll be on a  new version soon enough rfrasur
14:57:49 <phasefx> someone can always volunteer to maintain an otherwise defunct branch
14:57:51 <rfrasur> yup
14:58:07 <bshum> kmlussier: So to try being on track... the suggestion is that outside of 2.5 merging, maintenance releases, we try setting aside a specific time/day to work on miscellaneous bugs that have not had much love yet?
14:58:08 <rfrasur> I'll just make it more of a priority to get in on some testing
14:59:03 <kmlussier> bshum: Yes, that's what I'm suggesting. If others think it's a good idea.
14:59:55 <mrpeters> i like that idea
15:00:17 <kmlussier> When we used to have those pullrequest meetings, I loved seeing all the unloved patches finally getting merged in.
15:00:52 <kmlussier> Of course, I wasn't do much testing then, but would be able to help out now. :)
15:03:24 <bshum> For myself, I feel that bug squashing tends to happen best in conjunction with the maintenance releases.
15:03:41 <bshum> Maybe we should designate a particular day prior to the cutting date where we try to focus a bit more on it?
15:04:11 <bshum> Since bug squashing and getting fixes in would lead ultimately to being part of a maintenance release anyways for others to take.
15:05:21 <bshum> Maybe we should table this topic and bring it to the lists for some more feedback / refinement?
15:05:44 <kmlussier> That sounds good. Do you want to give it to me as an action item since I raised the topic?
15:05:54 <bshum> Sure.
15:06:26 <bshum> #action kmlussier to raise bug squashing day to the lists for further discussion/feedback
15:06:47 <bshum> Alright, anything else we need to discuss today?  (that's the end of the agenda)
15:07:03 <bshum> kmlussier++ # keeping our eyes on the prize with bug squashing :)
15:07:25 <dbwells> Re: bug squash days, my main concern is simple fatigue.  If I am going to poking people to push for the 2.5 timeline, I am not sure how much more we can wring out of the group.  That's all.
15:08:22 <kmlussier> dbwells: Sure, but if it's something that has to wait until after 2.5 is out, I think that's fine too.
15:08:36 <bshum> Well there's always going to be Evergreen-next
15:08:39 <kmlussier> Of course, with a six-month release schedule, it doesn't give much time between releases to focus on bug squashing.
15:08:54 <bshum> We have to figure out how to try balancing it.
15:09:14 <bshum> For myself, I think it really helps me when I get signoffs from others (anybody) to say whether a thing is good or not for them.
15:09:35 <bshum> Even if they say in the comment something works, that's fine because we still try it.  But I always feel better with more signoffs :)
15:09:47 <dbwells> I do think it is sort of built into the 2.5 goals to keep cutting the backlog, so it does make some sense to see where we are at when the cycle is over.
15:09:51 <bshum> (and it doesn't have to be core committer signoffs, I love seeing the sys admins step up)
15:10:00 <bshum> Or non-devs...
15:11:17 <dbwells> My biggest concern would be for bugs which *only* affect older versions.  Those tend to be fairly rare, though.
15:11:50 <kmlussier> dbwells: I agree. The recent reduction in the backlog was very encouraging. :)
15:12:10 <rfrasur> When the time comes, can we talk re: the hackaway?
15:12:49 <bshum> Alright, going to end the meeting notes, but since dbwells is around, I imagine he could help with hackaway questions post-meeting ;)
15:13:10 <bshum> Thanks everybody for coming, we'll try to be more on-time with things.
15:13:42 <bshum> #endmeeting