14:09:06 <bshum> #startmeeting 2012-06-05 - Developer Meeting
14:09:06 <pinesol_green> Meeting started Tue Jun  5 14:09:06 2012 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:09:06 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:09:14 <denials> https://launchpad.net/evergreen/+milestone/2.1.2 is such a nice clean url :)
14:09:25 <moodaepo> bshum++
14:09:35 <senator> bshum: but you're so good at it :-)
14:09:37 <bshum> #topic Releases
14:09:38 <berick> bshum++
14:10:14 <bshum> Looks like we have split agenda pages
14:10:21 <bshum> Some stuff on http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:next
14:10:28 <bshum> And also on http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2012-06-05
14:10:38 <denials> heh
14:10:41 <berick> denials++ release
14:11:29 <bshum> But let's start with OpenSRF and work our way around.
14:11:35 <bshum> #topic OpenSRF Release
14:12:13 <denials> #info OpenSRF 2.1.0 is available for download at http://evergreen-ils.org/opensrf.php as of yesterday
14:12:25 <bshum> I just adjusted the opensrf downloads page to drop the "release candidate 2" part and adjusted the release date to yesterday
14:12:26 <denials> Thanks to everyone for testing & helping out
14:12:35 <denials> bshum++ # more eyes
14:12:45 <bshum> denials++
14:13:39 <senator> denials++
14:13:40 <jeff> denials++
14:13:41 <denials> Not sure there's much more to say on that front
14:13:43 <bshum> Do we have a support policy for OpenSRF?
14:13:57 <bshum> Wondering about OpenSRF 2.0 series and whether we keep that around
14:14:00 <denials> bshum: not really, it's been much looser than Evergreen
14:15:00 <denials> It's a good idea though - maybe try to sync up with Evergreen, but one month ahead or something like that?
14:15:06 <berick> we could do something crazy and have it match Evergreen's
14:15:10 <berick> heh
14:15:21 <berick> +1 to lead time
14:15:39 <denials> Yeah, I think we want the rough edges of OpenSRF to be hammered down before the final RC testing period for Evergreen on top
14:15:51 <denials> (not that there's ever any rough edges!)
14:16:42 <senator> is that it for opensrf? shall we talk eg releases now?
14:16:44 <denials> The super-short release cycle for OpenSRF 2.2 would work out nicely then, as there's only one big feature (cross-origin support) on the horizon at this point, with the possibility of enhancements for Dojo / Java / other GSoC-originating stuff
14:16:54 <denials> Let's talk EG releases!
14:16:58 <bshum> Alrighty
14:17:03 <berick> one sec
14:17:11 <berick> i'll volunteer to look at the CORS patch
14:17:15 <berick> ok, carry on :)
14:17:18 <bshum> #idea Try to sync OpenSRF releases with Evergreen ones, one month ahead or something like that.
14:17:24 <bshum> #topic Evergreen Releases
14:17:40 <senator> #info Evergreen 2.2.0 real soon now, pending help in verifying readiness of i18n stuff
14:17:51 <senator> or does bshum have to say "#info"
14:17:53 <senator> not sure how this works
14:18:04 <denials> berick++ # cool, the only thing I can think of is permissiveness by default or requiring opt-in (for CORS)
14:18:05 <bshum> Anyone can say #info and it gets recorded in the minutes.
14:18:08 <senator> cool
14:18:19 <berick> #info Anyone can say #info and it gets recorded in the minutes.
14:18:20 <berick> sorry :)
14:18:25 <bshum> berick++
14:18:28 <denials> gee, who should look at i18n readiness? :)
14:18:47 * bshum senses an action item!
14:19:39 * denials senses a lack of sleep
14:19:56 <denials> Sure, gimme the action item
14:19:57 <berick> i'm not the man for i18n readiness job, but I can be a lackey
14:19:59 <senator> seriously, someone besides denials knows what to look for, right? so as not to pile one him
14:20:30 <senator> branch is working/user/senator/i18n_rel_2_2
14:21:15 <bshum> #action denials to review i18n branch from senator prior to 2.2.0 release
14:21:31 <bshum> #help Need more eyes on i18n work
14:23:34 <bshum> Any other 2.2 news before we go through any other release-related things?
14:23:50 <senator> not from me
14:25:11 <bshum> Okay then.
14:25:32 <bshum> Some new business
14:25:36 <bshum> #topic Sign-offs for branch merges
14:25:55 <bshum> I think dbwells had that on the agenda page.
14:26:06 <dbwells> Yeah, I added that.
14:26:42 <dbwells> Did I adequately explain the issue?
14:27:05 * denials will note, in his defence, that he was mostly thrown by commit e644726e69 being signed off, while 6e75f6e4bd01 was not signed off (but was via a merge commit)
14:27:27 <bshum> #info See dbwells notes on http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2012-06-05 about sign-offs
14:27:31 <dbwells> Well, no need for defense, it's confusing, I think.
14:27:47 <dbwells> Or at least non-obvious.
14:27:47 <denials> e.g. there was a merge commit signoff for master, but a cherry-picked signoff for rel_2_2. which was discombobulating at that hour of the night :)
14:28:59 <denials> I'll say that my bias is towards cherry-picked signoffs, as it's easy to see directly the signoff relationships for each commit.
14:29:19 <denials> But if the rest of the group says "meh", I can say "meh" too.
14:29:23 <eeevil> mine too, even though it can take forever
14:29:24 <berick> yeah, i can see the confusion.  not sure of a good solution, though
14:29:56 <senator> i guess cherry-picks are better. if that's to be the rule, let's just make it well known
14:30:25 <berick> i favor cherry-pick'ing, but I don't think it should be required for every branch
14:30:26 <senator> someone can perhaps whip up a shell script for cherry-picking all the new commits in a branch
14:30:27 <eeevil> well, seeing overall history is nice too ... which merges give you
14:30:38 <tsbere> For note, I think gitolite currently allows us to disallow merge commits. Not sure how that works with pre-existing ones though.
14:30:49 <denials> via tig, with "C" or whatever aliased to "cherry-pick -s", it's a snap
14:30:50 <eeevil> senator: I have a one-liner, but conflicts cause pain
14:31:21 <berick> <amendment> unless it can be automated
14:31:25 <eeevil> I kinda like option (b), if that can be scripted
14:31:38 <senator> i would think 'cherry-pick || bash' would be a good way to allow dealing with conflicts
14:31:48 <senator> but yeah, we can talk about that stuff later
14:31:49 <senator> and tig
14:31:59 <jeff> tig++
14:32:07 <jeff> (handy sometimes)
14:33:00 <dbwells> It seems like the consensus is to avoid merge commits if reasonably possible.
14:34:02 <dbwells> If we collectively come up with some good techniques to do so, then maybe we can avoid them altogether.
14:34:45 * denials can provide some tips around tig and .tigrc for aliases
14:34:51 <eeevil> should we disallow them to force that, for now?
14:35:03 <eeevil> denials: that'd be sweet
14:35:23 * tsbere has a cherry-picking script he uses
14:35:57 <jeff> tsbere: do you have that in / linked-from dev:git? i think i've seen it somewhere.
14:36:10 * denials will also, randomly, point at http://who-t.blogspot.ca/2012/06/git-branch-info.html - which lead him to learn about git aliases the other day (https://git.wiki.kernel.org/index.php/Aliases)
14:36:34 <tsbere> jeff: http://pastebin.com/QZT3EYUW I think is up to date
14:37:04 <bshum> #agreed Avoid merge commits if reasonably possible, and work collectively to come up with good techniques to do so.
14:37:23 <dbwells> I am in favor of disallowing merges for now as a way of forced learning :) (for myself)
14:37:30 <denials> #action denials to write up "How to set up an alias for cherry-picking w/ signoff in tig"
14:39:52 <dbwells> Sorry, didn't mean to comment after we "agreed", we can ignore me and move on, thanks.
14:39:55 <bshum> Any other opinions / votes on eeevil/dbwells proposal to disallow merges?
14:40:07 <eeevil> +1
14:40:11 <bshum> Can always make a new #agreed :)
14:40:11 <berick> +1 to what was agreed
14:40:29 <bshum> Got jumpy on my part perhaps :S
14:40:44 <eeevil> (only on master, of course)
14:40:52 <eeevil> (disabling merges, I mean)
14:42:16 <bshum> Perhaps we can discuss that further on lists or later then.
14:42:36 <bshum> #idea Disallow merges on master?
14:43:00 <bshum> Anything else to talk about today?  GSOC update?
14:43:14 * berick has a request when gsoc update is done
14:43:14 <denials> 2.1 release? tap tap tap?
14:43:30 * denials would prefer to see GSoC updates first though
14:43:34 <bshum> denials: You missed your shot back during the release topic!
14:43:36 <bshum> But okay
14:43:41 <bshum> #topic GSOC updates
14:45:08 <senator> #info pranjal has working php code for straightforward requests through the translator, working on improvements, blogging & showing a bigger community presence
14:45:21 <eeevil> C-port of db stored procs: I'll be shoving Swenuy out onto the list soon -- today or tomorrow -- with his first round of code (search/naco normalizer)
14:45:23 <denials> pranjal710++
14:45:40 <eeevil> #info C-port of db stored procs: I'll be shoving Swenuy out onto the list soon -- today or tomorrow -- with his first round of code (search/naco normalizer)
14:46:06 <eeevil> it's in working/Evergreen, feel free to poke now, of course
14:46:45 <dbwells> #info danielR is making good progress on the Android project. He has successfully used the relatively recent Java Gateway code to make a basic search and display interface. He has made some progress in integrating the IDL appropriately.
14:46:56 <tsbere> #info Dojo upgrade: Joseph has been making some progress and has run into his first unexpected issues (and started resolving them)
14:48:09 <dbwells> #info first Android app bits are here http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/drizea/android
14:49:03 <denials> yayz
14:49:24 <bshum> Cool!  Any other GSOC news to report?
14:51:01 <bshum> Alrighty then
14:51:09 <bshum> #topic Evergreen 2.1 release
14:51:23 <denials> what I wrote over an hour ago (ahem!) at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:next&#release_info
14:51:48 <denials> the status of bug 788629 is confusing to both senator and me, I believe
14:51:50 <pinesol_green> Launchpad bug 788629 in Evergreen 2.1 "Search loses advanced search limiters after changing sort method or further limiting the search" (affected: 8, heat: 36) [Medium,Confirmed] https://launchpad.net/bugs/788629
14:52:23 <denials> it's linked to bug 979158
14:52:24 <pinesol_green> Launchpad bug 979158 in Evergreen "jspac basic search loses limiters" (affected: 1, heat: 6) [High,Fix committed] https://launchpad.net/bugs/979158
14:53:32 <bshum> Based on what i'm reading from the two bugs
14:54:07 <bshum> It sounds like 788629 is a jspac problem and needs a new solution than the one originally proposed because the fix introduced the bug in 979158
14:57:00 <denials> The thing that confuses me is that dyrcona talks about a commit needing to be reverted, then the status of the bug changes to "Fix committed", but I don't see the revert anywhere?
14:57:30 <bshum> That's odd, I remember talking about it at the conference and thought someone fixed that for him.
14:58:01 <denials> e.g. "git show f4602609ff1577" followed by "git log Open-ILS/web/opac/skin/default/js/search_bar.js" doesn't show any changes after f4602609ff1577 to that file
14:58:17 <denials> (in master, anyway)
14:58:19 <senator> bshum: i think i was /going/ to fix it for him, but have since lost my grip on what needed done
14:59:43 <bshum> Hmm, oops :)
15:00:08 <denials> Apart from that, the only thing that seems to be in the way of a 2.1.2 release is what to do with 0691 appearing in 2.0, 2.1, and 2.2 upgrade scripts
15:00:45 <berick> what's the problem, exaclty?
15:00:52 <denials> (and we want it in each upgrade script, but I guess we want it to fail without rolling back the entire upgrade if it was already applied, so it should live outside the upgrade transaction - to answer my question)
15:01:27 <berick> ah, already-applied indexes
15:01:52 <denials> berick: the exact problem is that if I install EG 2.0.x and run through all of the the 2.0 upgrades, 0691 will be applied. When I upgrade to 2.1 and apply the 2.1.2 upgrade, it tries to get applied again and breaks
15:02:22 <denials> but we need it for people who might have started out with EG at 2.1.0 and never picked it up from 2.0.11. Same for 2.1 vs. 2.2.
15:02:55 <denials> I'm surprised we haven't run into more of the same already, to be honest. Or maybe I'm the only one perplexed by it :)
15:03:16 <denials> Everyone else just moves instances like that quietly out of the transaction and doesn't moan :)
15:03:57 <bshum> Something like that.
15:04:11 <bshum> Or we upgraded out of 2.0 before that happened, or 2.1 before that happened, etc.
15:04:59 <berick> i see
15:05:03 <denials> bshum: right
15:05:07 <tsbere> MVLC avoids those headaches ;)
15:05:20 <berick> so, yeah, moving it out of the main xact makes sense
15:06:09 <denials> schema migrations are hard; that's why David Wheeler isn't finished http://sqitch.org/ yet
15:06:52 <denials> #action denials will stop moaning about schema conflicts and move 0691 out of the main xact for the 2.1.1-2.1.2 upgrade (and senator shall do likewise for 2.1-2.2)
15:07:07 * denials isn't sure his #action items actually take effect :)
15:07:45 <bshum> They should.
15:07:57 <bshum> I'm fairly sure the #action command isn't chair only
15:08:30 <denials> otherwise, tsbere++ # make_release.sh does a lot of heavy-lifting, now that I'm starting to get comfy with it
15:11:50 <bshum> Alrighty then.
15:11:56 <bshum> Anything else to talk about today?
15:12:20 <berick> i have a question, what's the protocol for getting a new milestone added to LP?
15:12:23 <berick> in particular, 2.3
15:12:48 <eeevil> berick: or, series, right?
15:12:56 <bshum> I thought core devs and Dyrcona had access to making new series / milestones
15:13:08 * berick might have access
15:13:10 <berick> i need to check
15:13:10 <bshum> Or maybe it's just gmcharlt, denials, and Dyrcona
15:13:29 <tsbere> "Who has access" and "When are we supposed to do it" are very different questions
15:13:30 <berick> eeevil: series, too.  i'm thinking about code that has been committed to master (but not 2.2, etc.)
15:13:47 <berick> code that is, as of commit date, targeting milestone 2.3
15:13:51 <bshum> berick: You're in the release maintainers group, so I think you should be able to do so.
15:14:21 <berick> thanks bshum, i'll poke around.
15:14:22 <berick> tsbere: true
15:14:25 <denials> berick: you add a series, then a milestone
15:14:44 <denials> I just added a series for 2.3. you want a milestone for 2.3.0-alpha or something to start with?
15:15:33 <bshum> Alright, well, in that case, I'm ending the meetbot notes.  Thanks for attending the meeting and thanks to kmlussier for getting us on track with the polls :)
15:15:41 <bshum> #endmeeting