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