13:03:12 <ttx> #startmeeting
13:03:13 <openstack> Meeting started Thu Jun 14 13:03:12 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:13 <markmc> so, I'm actually prepared for this :)
13:03:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:22 <ttx> <markmc> so, I spent some time this morning getting a handle on 2012.1.1 plans
13:03:24 <ttx> (for logging)
13:03:38 <markmc> everything you say can and will be used against you
13:03:43 <ttx> markmc: always.
13:03:57 <Daviey> ttx: ey
13:04:01 <markmc> ok, so I'll just dump the status as I see it
13:04:04 <ttx> so what is your plan, before I expose the current issues we have ?
13:04:14 <ttx> Daviey: welcome!
13:04:24 <markmc> we've 4 core stable/essex projects now
13:04:28 <markmc> and here's what they've got
13:04:50 <markmc> glance: 5 commits on stable/essex, 0 pending, 5 bugs targetted to essex
13:05:03 <markmc> nova: 34 commits on stable/essex, 6 pending, 31 bugs targetted to essex
13:05:17 <markmc> keystone: 4 commits on stable/essex, 4 pending, 4 bugs targetted to essex
13:05:22 <ttx> on the things that were committed, is there anything high-impact / security-related ?
13:05:32 <markmc> horizon: 8 commits on stable/essex, 1 pending, 7 bugs targetted to essex
13:05:43 <markmc> ttx, good question
13:05:50 <ttx> I know the a,nswer is YES for horizon
13:05:52 <Daviey> keystone
13:05:53 <markmc> pretty sure there are some CVE fixes on the nova side
13:06:08 <markmc> so, the answer is probably yes except for glance
13:06:27 <markmc> https://launchpad.net/keystone/+milestone/2012.1.1
13:06:30 <Daviey> 14:03 < ttx> #startmeeting
13:06:31 <markmc> https://launchpad.net/nova/+milestone/2012.1.1
13:06:36 <markmc> https://launchpad.net/glance/+milestone/2012.1.1
13:06:41 <markmc> https://launchpad.net/horizon/+milestone/2012.1.1
13:06:51 <markmc> oh, wait - I haven't targetted nova/glance bugs to the milestone yet
13:07:02 <markmc> ttx, I don't appear to have permissions for that ... halp!
13:07:16 <ttx> fixing
13:07:33 <ttx> markmc: you could for keystone ?
13:07:47 <markmc> and horizon
13:08:12 <ttx> 404 on those links, missing essex I presume
13:08:26 <markmc> missing 2012.1.1
13:08:32 <markmc> I added those for keystone and horizon
13:08:34 <ttx> oh. I see
13:08:39 <markmc> no perms for glance and nov
13:08:40 <markmc> a
13:09:19 <markmc> ok, while you're fixing that
13:09:21 * ttx looks on how we did it for 2011.3.1
13:09:38 <markmc> basic plan I think should be to release 2012.1.1 for all 4 projects soon
13:10:08 <ttx> ok, the trick is to make stable-maint the release manager for essex series
13:10:12 <markmc> would like us to have candidate tarballs and call for testing by this time next week, say
13:10:18 <markmc> and maybe do the release the week after?
13:10:28 <markmc> ttx, cool
13:10:41 <Daviey> For reference, Ubuntu has just uploaded this week of snapshots to our proposed archive.
13:11:14 <markmc> Daviey, yeah, we've been tracking stable/essex too
13:11:16 <ttx> markmc (and Daviey): you're now relmgr for essex on Glance and Nova, so that whould be unblocked
13:11:19 <Daviey> We'll be undergoing significant verification of these snapshots.
13:11:31 <markmc> hmm, I'm away the week after next
13:11:39 <markmc> well, at Red Hat Summit
13:11:49 <markmc> could we possibly release this time next week ttx?
13:11:53 <ttx> sounds like plenty of free time ahead.
13:12:27 <Daviey> well, we probably don't have to rush it in for next week.
13:12:27 <markmc> free time in what sense?
13:12:28 <ttx> markmc: if we get candidates out before the end of the week, we could target next Thursday
13:12:39 <markmc> ttx, cool
13:12:49 <markmc> ttx, I figure I can get to step 4 of http://wiki.openstack.org/StableBranchRelease today
13:13:09 <ttx> Daviey: could we sync candidates ?
13:13:22 <ttx> Daviey: have the same things undergo testing on Ubuntu and upstream ?
13:13:27 <Daviey> I'd quite like the verification we are doing on the snapshots to be useful for the point release.  If we rush out a release next week, the results could uncover regressions, making our verification independent.
13:13:28 <markmc> would like to look over the projects launchpad and history for serious issues which we haven't backported fixes for, though
13:13:42 <markmc> would need to be conservative getting any more in before a release next week, though
13:13:54 <ttx> markmc: I see a benefit in waiting a bit more though
13:14:01 <markmc> ok, well
13:14:11 <markmc> it turns out I'm away for 3 weeks from the end of next week
13:14:13 <ttx> markmc: we could announce we'll be doing a 2012.1.1 "soon" and let extra fixes pour in
13:14:26 <markmc> someone else could cut the release, though
13:14:33 <ttx> Daviey: to sync with you, should we rush, or delay ?
13:14:55 <Daviey> From my POV, a point release isn't in a huge hurry.. If we schedule a point release to be released say, 4 weeks from now.. (when markmc returns?).. that would work kinda well?
13:15:07 <Daviey> allows us to have extended candidate baking ?
13:15:18 <markmc> don't see the point, myself
13:15:22 <Daviey> ttx: I'm in no hurry for us to rush
13:15:28 <ttx> Daviey: thought you were already testing candidates ?
13:15:30 <markmc> with both Fedora and Ubuntu tracking stable/essex
13:15:35 <markmc> the chances of surprises are low
13:15:41 <markmc> certainly not worth waiting 4 weeks
13:15:52 <ttx> I know Horizon wants a point release sooner than that
13:15:58 <Daviey> ttx: we are, but the results of our snapshots will serve no help if we squeeze this out fast.
13:16:19 <ttx> they can wait 2 weeks, but will bitch about waiting 4+weeks
13:16:34 <markmc> Daviey, release candidate tarballs tomorrow, you can't validate before next thursday?
13:16:43 <Daviey> markmc: Are you going to have any availability whilst at your summit?
13:16:58 <markmc> not enough to do this, no
13:17:26 <Daviey> ok, if you are confident we can do this in a week.. i certainly won't try to slow it down.
13:17:27 <ttx> Hmm. If we do final baking during that away week, we can release early the week after.
13:17:47 <ttx> So two options...
13:17:59 <ttx> 1. RC soon, release by Thursday next week
13:18:14 <ttx> 2. Announce, RC late next week, release early week+2
13:18:22 <ttx> err.. +3
13:18:38 <markmc> ttx, hmm, if you think waiting a week helps ... didn't you see me say I'm away for 3 weeks?
13:18:58 <markmc> (holidaying in france after RH summit)
13:19:02 <ttx> Oh, you're away for three weeks ?
13:19:10 <markmc> yeah, just realized
13:19:14 <Daviey> markmc: Ah, you can Sprint with ttx :)
13:19:15 <ttx> I understood "just one week"
13:19:21 <markmc> so if it's me cutting it, then (1)
13:19:22 <ttx> yay
13:19:25 <markmc> otherwise
13:19:26 <ttx> Where in France ?
13:19:40 <markmc> 2. 2. Announce, RC late next week, release early week after
13:19:50 <markmc> ttx, near lake annecy
13:19:53 <ttx> OK, before we finalize the date, I'd like to expose the issues we currently have
13:19:57 <ttx> cool.
13:20:37 <ttx> a. We need to fix the versioning. stable/essex should have been versioned 2012.1.1 / Final=False at branch creation
13:20:49 <ttx> currently it builds badly-versioned tarballs
13:21:01 <Daviey> right
13:21:03 <ttx> I fixed it for Horizon, we need to fix it for the others
13:21:17 <ttx> b. CI currently doesn't publish tarballs
13:21:17 <markmc> ttx, I've queued up patches for that
13:21:19 <markmc> in gerrit
13:21:23 <markmc> yeah, I noticed (b)
13:21:30 <ttx> which makes it difficult to get candidates right now
13:21:37 <ttx> but that could be solved by tomorrow
13:21:39 <markmc> seems like the tarball generation stopped around the time the pep8 issues happened
13:21:43 <Daviey> markmc: I'll take a gander at them after this, should be trivial.
13:21:53 <markmc> latest one was May 18
13:23:12 <ttx> markmc: apparently it's a zuul thing
13:23:29 <ttx> https://bugs.launchpad.net/openstack-ci/+bug/1013091
13:23:30 <uvirtbot> Launchpad bug 1013091 in openstack-ci "Zuul isn't triggering tarball jobs" [Critical,New]
13:23:35 <markmc> ah, ok
13:23:46 <markmc> well, I have the utmost confidence in james and co. fixing it quickly :)
13:24:06 <ttx> So technically we could have candidate tarballs up before the weekend
13:24:23 <markmc> ttx, yep
13:24:27 <ttx> markmc: have enough bandwidth to make it happen ?
13:24:32 <markmc> ttx, yep
13:24:48 <Daviey> markmc: If we shoot for stable release next Thursday, you have high level of confidence they will be solid?
13:25:01 <markmc> ttx, with the slight caveat that I think it would be good to look back over git and launchpad to make sure we've missed nothing major
13:25:03 <ttx> Daviey: should be solid, at least at tarball level
13:25:23 <ttx> markmc: yes, that's my major issue with the "rushed" timeline:
13:25:24 <markmc> ttx, I will do that, but it means there's potential for more fixes to land early next week
13:25:32 <markmc> ttx, yeah
13:25:37 <Daviey> markmc: Okay.. how should we split this up?
13:25:39 <markmc> ttx, we'd have to be conservative
13:25:46 <ttx> markmc: It would have been good to approach PTLs and ask them if there is anything more they want in before we cut
13:25:49 <markmc> ttx, and we can do another point release soon after if needed
13:25:56 <markmc> ttx, good point
13:25:57 <ttx> but there is no time for that in that timeframe
13:26:10 <markmc> Daviey, yes, re: confidence
13:26:16 <ttx> after all, point releases are definitely something they have a say on, content-wise
13:26:19 <markmc> Daviey, split what part up?
13:26:30 <markmc> Daviey, the "let's make sure we haven't missed anything" thing?
13:26:41 <Daviey> markmc: Tasks to do.. http://wiki.openstack.org/StableBranchRelease ..
13:26:45 <ttx> so basically we can definitely do Horizon in the timeframe proposed... the others, maybe less so
13:27:02 <ttx> markmc: do you see strong benefit in correlation ?
13:27:02 <markmc> Daviey, well, I figure I'm doing all that otherwise there's no reason to rush
13:27:19 <Daviey> markmc: Do you want to do it all yourself, or split the burden?
13:27:45 <markmc> Daviey, if you want to cut the release, we can push the release out to the following week
13:27:52 * markmc doesn't *want* to do anything :)
13:28:16 <Daviey> heh
13:28:19 <markmc> ttx, as in, releasing them all at the same time?
13:28:23 <ttx> markmc: yes
13:28:36 <markmc> ttx, I see a strong benefit in releasing e.g. nova/keystone soon, certainly sooner than 4 weeks
13:28:55 <Daviey> markmc: what bonus are you seeing specifically ?
13:29:02 <markmc> ttx, don't see from the list of changes why horizon would warrant a particular rush over the other too
13:29:08 <markmc> Daviey, what bonus what?
13:29:14 <ttx> markmc: I think you need to talk to PTLs before making a final decision on the timeframe. If they all say "please go ahead with current state" it's doable.
13:29:27 <Daviey> markmc: nova/keystone soon.. what are the benefits of doing them sooner?
13:29:27 <markmc> ttx, ok, will do
13:29:41 <markmc> Daviey, sooner than 4 weeks?
13:29:55 <markmc> Daviey, well, put it this way what's the benefit in doing horizon sooner than 4 weeks?
13:29:56 <ttx> markmc: I think that's because the Horizon devs pushed all the fixes they wanted in... and there is a couple of security issues that should definitely see the light of tarball release
13:30:03 <Daviey> markmc: no, generally - why them two as a priority ?
13:30:09 <markmc> Daviey, whatever the benefit is applies to nova/keystone too :)
13:30:13 * markmc takes a shortcut in answering
13:30:14 <ttx> so for them, it makes sense...
13:30:31 <markmc> ttx, same goes for nova, for sure
13:30:50 <markmc> ttx, keystone less so, maybe - but there are some serious fixes that would be good to release
13:30:51 <ttx> markmc: except vishy didn't ask you to cut a point release, yet :)
13:30:56 <Daviey> so the priority is because they contain sec fixes?
13:31:12 <ttx> The difference with Horizon is that the PTL explicitely blessed the current state
13:31:12 <markmc> ttx, ok, I'll ask him to ask me
13:31:20 <markmc> ttx, I'm sure he'll oblige
13:31:30 <markmc> ok, look
13:31:32 <markmc> point taken
13:31:34 <ttx> (though I think he mentioned an extra fix that still needs to go in)
13:31:35 <markmc> "talk to the PTLs"
13:31:36 <markmc> :)
13:32:04 <Daviey> I assume vishy isn't around?
13:32:16 <ttx> markmc: ok, so action is for you to talk to PTLs and see the remaining issues with 2012.1.1 tarballs resolved...
13:32:40 <markmc> ttx, yep
13:32:41 <ttx> markmc: and then post your proposed plan to ML and see if it hurts anyone'sfeelings
13:32:51 <ttx> markmc: and then go ahead and do it anyway.
13:32:55 <Daviey> lol
13:33:01 <markmc> ttx, and create nova/glance 2012.1.1 milestone and target bugs to them
13:33:13 <ttx> markmc: awesome
13:33:14 <markmc> ttx, and have the pending fixes in gerrit flushed
13:33:29 <ttx> Would like to use a few minutes to talk about the ODS session outcomes and action plan
13:33:31 <markmc> ttx, and look back for serious issues which need to be backported
13:33:41 <ttx> if we are clear with the way forward
13:33:55 <markmc> cool
13:34:01 <ttx> so...
13:34:13 <ttx> At ODS we discussed having separate stable-maint teams
13:34:23 <ttx> openstack-stable-maint focused on release -1
13:34:27 <Daviey> markmc: Sorry, can i clarify.. You want to drive the work for this, or would you prefer it was split up a bit more?
13:34:47 <ttx> Daviey: depends on the timing, which depends on PTL's reactions
13:35:13 <ttx> then diablo-stable-maint team for anyone who cares about diablo (as long as anyone cares about diablo)
13:35:17 <Daviey> Okay, because currently it feels like it will default to markmc.. which seems a little unfair to him.
13:35:30 <ttx> with some page that blesses those teams
13:35:35 <markmc> Daviey, what would you like to help with? very happy for you to do so
13:35:52 <ttx> old-series teams  can lose their blessing by being obnoxious to the security team
13:36:01 <ttx> or if the PTL hates them
13:36:12 <Daviey> markmc: this is what i am trying to determine :)
13:36:29 <markmc> Daviey, well, I listed my action items - which do you want to take off me?
13:36:37 <Daviey> markmc: splitting at task level, or project level.. i'm happy to do..  or just leave it all to you :)
13:36:59 <Daviey> markmc: Honestly, if you are happy doing it.. i won't rip anything off you, it just seemed unfair to you.
13:37:01 <ttx> Daviey: markmc will need fast reviews on stable/* to complete his plan, that's one way to help, be on them quickly
13:37:16 <markmc> yep, absolutely
13:37:18 <markmc> good point ttx
13:37:23 <markmc> fast, but thorough :)
13:37:47 <ttx> Talking from experience, relmgt is not a job that is easy to split
13:37:57 <ttx> but you need support from people to validate your reviews/choices
13:38:09 <ttx> i.e. getting unblocked fast
13:38:21 <markmc> so, the diablo-stable-maint team thing
13:38:33 <markmc> ttx, I guess I'm fine with the idea in principle
13:38:51 <ttx> So I'd say Mark handles 2012.1.1 but the rest of the team is on hands-on-deck ready to help him with reviews and stuff
13:38:54 <markmc> ttx, but not seeing enough in terms of volunteers etc. to be worth the effort of setting up the infrastructure
13:39:26 <Daviey> I don't think there has been a call for volunteers, really.
13:40:15 <ttx> right. My impression was that Dave & Canonical would maintain diablo for 18 months ?
13:40:29 <ttx> and then anyone would be free to help them
13:40:39 <Daviey> aggressively looking for trunk, or essex patches to backport interests me less for diablo.. but supporting specific issues targetted and reviewing others patches is more interesting (to me).
13:41:01 <Daviey> ttx: Yep
13:41:24 <markmc> ok, cool
13:41:26 <ttx> markmc: it's a bit of chicken-and-egg. I think the team should be set
13:41:29 <Daviey> I'm not expecting the need for a diablo point release.
13:41:42 <markmc> if diablo-stable-maint is going to be Daviey and zul, that's cool
13:41:49 <ttx> and we need some reference page to explain the status of maintenance for old releases
13:42:02 <zul> ergh
13:42:05 <ttx> to set expectations right
13:42:09 <Daviey> hello zul :)
13:42:26 <ttx> i.e. if diablo-stable-maint team says they will just do security backports, I'm cool with that
13:42:35 <ttx> but that needs to be documented on a reference page
13:42:48 <Daviey> and at least data loss.
13:42:57 <ttx> http://wiki.openstack.org/Releases sounds like a good pick
13:43:17 <ttx> markmc: any issue with that plan ?
13:43:35 <ttx> Daviey: does that reflect what you can do ?
13:43:44 <Daviey> but generally, i want Ubuntu to be pushing patches into upstream, rather than carrying locally.. Which is why i'm keen on longevity whilst interest is in a branch
13:43:53 <Daviey> ttx: wfm
13:44:24 <markmc> ttx, yep, totally cool with Daviey and zul continuing diablo maintenance
13:44:42 <markmc> ttx, assuming the criteria for inclusion is the same as now, except maybe more constrained
13:44:54 <markmc> i.e. continues to be "safe source of fixes for high-impact issues"
13:45:00 <markmc> but that's my understanding of the plan
13:45:02 <markmc> just being clear
13:45:06 <markmc> so, yeah - I'm cool
13:45:22 <Daviey> yep, but also less aggression in seeking fixes to backport.. A per-issue basis
13:45:38 <markmc> yep, cool
13:45:46 <ttx> Daviey: agreed that the criteria for inclusion for series-specific stable teams has to be at least the stable-team rules ?
13:45:55 <Daviey> at least
13:46:06 <ttx> Subsidiary question: for security fixes
13:46:26 <ttx> doe sthat mean the security team can ping the diablo-stable-maint team to help with backport of security issues ?
13:46:52 <Daviey> track, support & help.. but only a maybe commitment on 'do'.
13:48:08 <Daviey> that sounds a little weaker than i intended :)
13:49:26 <ttx> Daviey: looks like the first task of  diablo-stable-maint will be to ensure we can merge stuff to stable/diablo again
13:49:34 <Daviey> for the 18 months since release, we will make sure security issues are addressed.
13:49:59 <Daviey> ttx: Are there issues you know of?
13:50:02 <ttx> Daviey: put that in the description of diablo-stable-maint when you go to create it in LP
13:50:21 <Daviey> ttx: you want it documented here: http://wiki.openstack.org/Releases ?
13:50:23 <ttx> Daviey: I know there are security changes that are blocked
13:50:42 <Daviey> Ok, i'll dig into that.
13:50:44 <ttx> Daviey: I want it to be documented on lp:~diablo-stable-maint
13:50:50 <Daviey> ok, cool
13:50:59 <ttx> then an announce on the ML, then i'll update Releases
13:51:11 <Daviey> ttx: Having said that, the structure allows other contributors to go further than i am able to commit to at the moment.
13:51:15 <ttx> to designate the team as the keeper of Diablo.
13:51:50 <ttx> Daviey: team description can change. That's just a description of the team's commitment
13:51:56 <Daviey> ok, winner
13:52:15 <ttx> Daviey: action on you to set up team and announce it on ML
13:52:24 <ttx> see if anyone joins :)
13:52:34 <Daviey> wilco
13:53:10 <ttx> markmc, Daviey: anything else ? Looks like we can followup through those actions using ML ?
13:53:25 <markmc> ttx, yep, sounds good
13:53:40 <markmc> ttx, you could do a bunch of #action for us could you?
13:53:48 <markmc> just so I don't forget what I said I'd do
13:53:54 <ttx> sure
13:54:37 <ttx> #action markmc to talk to PTLs to discuss 2012.1.1 timeline
13:55:08 <ttx> #action markmc to make sure versioning on stable/essex is 2012.1.1/Final=False
13:55:22 <ttx> #action markmc to see that tarball posting job is fixed
13:55:41 <ttx> #action markmc to follow-up on ML with proposed 2012.1.1 timeline
13:56:06 <ttx> #action Daviey to set up lp:~diablo-stable-maint with commitments in the description
13:56:33 <ttx> #action Daviey to announce ~diablo-stable-maint on ML to encourage joins
13:56:58 <ttx> #action ttx to rework wiki/Releases to reflect openstack-stable-maint and <series>-stable-maint commitments
13:57:09 <ttx> all captured ?
13:57:31 <Daviey> markmc: You are happy with that weighting ?
13:57:46 <markmc> sounds like a plan
13:58:02 <Daviey> ok, lets go home then \o/
13:58:13 <ttx> #action Daviey/zul to be reactive to any reviews that markmc raises on stable/* over the next days :)
13:58:29 <ttx> awesome
13:58:36 <ttx> #endmeeting