13:30:09 #startmeeting releaseteam 13:30:10 Meeting started Fri Sep 4 13:30:09 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:30:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:30:15 The meeting name has been set to 'releaseteam' 13:30:18 dhellmann, dims: o/ 13:30:19 o/ 13:31:50 #topic liberty-3 postmortem 13:32:03 let's wait a second for doug 13:32:44 ack 13:34:42 o/ 13:34:46 o/ 13:34:52 #link https://etherpad.openstack.org/p/liberty-3 13:34:55 * dhellmann apologizes for the delay 13:34:58 lists a bit of our postmortem 13:35:04 anything that I missed ? 13:35:33 I think those are the highlights 13:35:53 ok cool, let's talk next steps then 13:36:00 #topic Next steps in Liberty release 13:36:08 dhellmann: you had an etherpad listing some 13:36:29 #link https://etherpad.openstack.org/p/liberty-end-of-release-requirements-checklist 13:36:44 So there are two sides I want to discuss 13:36:44 "Some PTLs just don't show up" << sad! 13:36:46 those are the dance steps for handling the branching sequencing 13:36:56 Dance around requirements 13:37:06 and what we need to push everyone toward 13:37:15 Let's talk about the latter first 13:37:31 The goal over the next weeks is to push everyone towards publication of their first RC 13:37:44 we need at least one that we can fallback to for the release branch 13:38:15 so we need RC1s for everyone in cycle-with-milestones 13:38:35 (and at least one intermediary for everyone in cycle-with-intermediary, but I thin that's covered already) 13:39:10 There is no "date" for RC1, i would say it should definitely happen before end of month so that we don't eat our security margin 13:39:38 So this part of the release management is mostly about giving advice to PTLs 13:39:48 should we give a specific date as a goal, just to have it in people's minds? 13:40:13 encourage them to stop adding features ASAP (only accept FFEs with an end in sight, stop accepting those asap) 13:40:31 I think the week of Sept 21 should be the target dat 13:40:38 all good if that's done before 13:40:48 I had the impression from most of the discussions I had with PTLs that they were going to be pretty strict with FFEs 13:40:54 I like the 21st 13:41:08 yeah, I think they understand that it's not a stupid rule, it's actually the only sane way 13:41:36 RC1's are cut from the stable/ branch? 13:41:52 Once FFEs are out of the way, the issue is RC bugs. They usually have more than they will fix, so at some point they need to get real and prioritize real release blockers 13:42:08 dims: stable is cut before or at RC1 13:42:16 ack thx 13:42:28 * ttx finds graphs 13:43:14 http://ttx.re/getting-to-havana.html has one 13:43:29 ttx: how much of the stable branch stuff is automated? I have a script that works for libs, but it assumes a tag and milestone both exist already 13:43:44 http://old-wiki.openstack.org/rc/ has the one we did for kilo but it's now a bit compressed 13:44:10 it shows that things are mostly stable until they start cutting deep in the RC1 bug nominations and defer things 13:44:43 dhellmann: we have scripts for cutting the branch, and scripts to tag the rc1 13:44:49 rccut / rcdelivery 13:44:55 ah 13:45:01 I updated them recently 13:45:35 oh, right, I reviewed those changes 13:45:41 * dhellmann hasn't had much tea yet today 13:46:00 so for the next week we should focus on FFEs. The week after we should start focusing on limiting RC bugs 13:46:38 I rewrite the FF page so that we are no longer on the hook for them, the PTL is the sole decider 13:46:43 rewrote 13:46:56 but I hope they will ask us when in doubt 13:47:02 and we can provide random advice 13:47:08 haha 13:47:14 ripping out a DB layer for example doesn't make a great FFE 13:47:22 :-) 13:47:47 questions on that part ? 13:47:55 sounds good 13:48:08 I think that's all clear 13:48:15 so now, the requirements dance part 13:48:16 https://etherpad.openstack.org/p/liberty-end-of-release-requirements-checklist 13:48:32 the cross-check jobs are now running 13:48:51 since we don't have any stable branch cut yet it's mostly testing master->master twice 13:49:02 but it will soon start being useful 13:49:28 I wanted to discuss the three steps we have left for this week in thoery 13:49:33 release "final" versions of Oslo libs 13:49:33 release "final" versions of Python clients 13:49:33 Softfreeze requirements 13:49:33 we don't list creating branches for the libs, should we do that as part of tagging what we think is the final version, or delay that? 13:49:55 there is "Cut Library stable branches" under FF+1 13:50:21 oh, I missed that because I expected it to be done with the tags, but I guess a short delay makes sense 13:50:27 So... release "final" versions of Oslo libs -- how are we doing on that so far , 13:50:28 ? 13:50:39 after 'release "final" versions of Oslo libs' we need to update g-r, before 'release "final" versions of Python clients' 13:51:11 dims: we just need to bump contraints, right 13:51:12 we are doing good, last check only things unreleased were g-r updates and translation updates 13:51:33 ttx: y 13:52:19 dims: should we plan a last round for Tuesday ? 13:52:30 ttx: sounds great! 13:52:37 * ttx check status for python clients real quick 13:53:33 openstack/releases makes that pretty easy 13:53:47 ++ :) 13:54:08 though there is no date 13:54:33 no zaqarclient yet 13:55:04 I'm building a report of all of the unreleased changes for the clients, but it's going to take a little bit 13:56:34 swiftclient is 7 weeks old 13:56:58 troveclient 3 months old 13:57:38 ttx: dhellmann: will read scrollback as i have a hard stop 13:57:46 dims: ack 13:57:54 manilaclient is 3 months old too 13:58:13 ttx: encouraging client releases is another thing we need to do more directly next cycle, I guess 13:58:17 keystoneclient 2 months old 13:58:40 this report is taking ages 13:59:01 cinderclient 6 weeks old 13:59:08 the others are relatively recent 13:59:16 (less than a month) 13:59:52 these are all pretty risky to release, though 14:00:01 since every one ends up being used in the gate 14:00:34 right, I'm just unsure we can cut stable/liberty from a 3months-old release and discard what was pushed after that 14:00:42 true 14:00:50 so we might need to push a bit 14:01:38 #info need to push for library releases (client in particular) before we cut stable branches 14:01:58 my report script is hanging on ganttclient, so I'll fiddle with that today and send email to the -dev list encouraging releases 14:02:22 dhellmann: about softfreezing requirements, we might want to schedule a requirements +2/-2 party 14:02:39 i.e. pair-review the backlog there 14:02:44 good idea 14:02:50 early tuesday? 14:02:55 or later today? 14:02:58 your call 14:03:06 better today all things considered 14:03:08 I'm up for doing it today 14:03:17 since that's when the freeze is supposed to take 14:03:24 maybe we can pull sdague in 14:03:32 what's up? 14:03:40 we might want to schedule a requirements +2/-2 party 14:03:43 we're thinking of doing a join requirements freeze review 14:03:45 i.e. pair-review the backlog there 14:03:57 approve last minute things and -2 the others 14:03:57 sure 14:04:10 yeh, fwiw, there is a novaclient one coming 14:04:11 IIRC we did something similar last cycle 14:04:15 yep 14:04:38 sdague: releases don't have to be final, they just need to be recent so that we can cut the stable branch from them 14:04:40 are you thinking today, or early next week? 14:04:50 ttx: here's some raw data on unreleased clients 14:04:51 #link http://paste.openstack.org/show/445440/ 14:04:57 sdague: we weree thinking today, sinc ethe freeze does in theory take effect today 14:06:10 gotcha 14:06:43 dhellmann: ok, anything else we need to discuss before we do the requirements review party? 14:06:57 I don't think so. Do you want to go ahead and do that now? 14:07:35 yes, but back on our channel 14:07:38 k 14:07:44 let's close this 14:07:48 #endmeeting