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