16:00:02 #startmeeting releaseteam 16:00:03 Meeting started Thu Sep 19 16:00:02 2019 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:07 The meeting name has been set to 'releaseteam' 16:00:10 Ping ttx dhellmann diablo_rojo hberaud evrardjp armstrong tonyb 16:00:20 o/ 16:00:32 #link https://etherpad.openstack.org/p/train-relmgt-tracking Agenda 16:00:33 heyhey kids! 16:00:46 o/ 16:01:18 Looks like we're around line 490 in the tracking etherpad. 16:01:29 o/ 16:01:58 o/ 16:02:34 OK, looks like that's probably everyone. 16:02:39 #topic What if anything to do with lib release stragglers 16:03:14 #link https://etherpad.openstack.org/p/train-library-tracking 16:03:29 I haven't rerun that to see if anything has changed, but I don't think so. 16:04:00 Most are probably fine, other than some of these then needing to be backported to stable/train after branching. 16:04:32 smcginnis: at one point we said that every change needs to be released 16:05:15 Some of these are probably minor enough that they could just be considered ussuri changes. 16:05:26 Some not though. 16:06:57 hmm 16:07:37 I think it's too late now, and those should be considered Ussuri 16:07:56 Yeah. :/ 16:08:05 If they want those in Train, follow the FFE procedure 16:08:26 there is only so much we can do to prevent library authors from shooting themselves in the foot 16:08:41 I thought we would autorelease libs though 16:08:51 It's kind of late, but should we send out this list to the ML. 16:09:20 line 469 says so 16:09:35 and line 443 16:09:46 "Generate release requests for all libraries which had changes. " 16:09:50 what did we miss? 16:10:13 Good question. 16:10:34 did those changes land after those releases? 16:10:51 (and our error is that we should have branched earlier) 16:11:05 or did they somehow fall through 16:11:27 Looking at the timestamps, some did merge after. 16:11:47 Some were there, but maybe since they were only one or two they didn't get release requests? 16:11:51 so the issue is that we failed to branch? 16:12:08 But for the freeze, we need to make sure even single commits get released. 16:12:33 smcginnis: alternatively, lets release all of them 16:12:39 but needs to be this week 16:12:47 otherwise that would be pushing it 16:13:19 hmm that would mean a bunch of requirements bumps... probably not a great idea 16:13:30 Yeah 16:13:59 Actually, I was able to remove a few that we did end up doing releases for after I generated that. 16:14:03 but better this week than any closer to release 16:14:21 So most are just trivial changes that probably are OK to count as ussuri changes. 16:14:38 And the ones that are not, those teams can backport to stable/train and do a stable release once the freeze is over. 16:14:40 yeah 16:14:46 Let me cross those out 16:14:52 It's just a matter of a few weeks yet. 16:15:33 So unless something is completely broken, at this point I say let's get that branching patch merged and treat these as normal stable blackport issues. 16:15:44 yeah 16:15:44 If the teams actually feel like they need to backport, that is. 16:16:20 But I'd still check why those were missed in earlier autoreleases 16:16:22 A few are things for the pdf docs. Those are fine just getting picked up with ussuri I think. 16:16:47 like is it all changes that landed after the autorelease 16:17:05 Realizing the timestamps here are the commit timestamps, not the merge timestamps, so it's possible these actually did land after the autorelease. 16:17:17 yes, let's not solve it in-meeting 16:17:37 adding to next week tasks 16:17:43 I am kinda lost in all of that, so I have trouble to follow 16:17:44 For not, let's just all take a mental note to pay close attention to that next time around too. 16:18:06 smcginnis: maybe it's just that we should have branched a deadline time 16:18:12 branched at 16:18:12 evrardjp: Basically the issue is for the autoreleases we do for milestone 1 and 2, if it's only 1 or 2 commits we might skip doing them. 16:18:32 evrardjp: But for the final freeze, we need to make sure all commits are released so stable branch creation includes all work done. 16:18:59 The ones that didn't get included now either have to be part of ussuri, or we would need to do a requirements FFE to get those out now. 16:19:12 got it. 16:19:14 Which carries the risk that it would have a ripple effect of making others have to do releases. 16:19:19 ok task added, let's move on 16:19:22 yeah 16:19:25 ++ thanks 16:19:38 #topic Review accomplished week tasks 16:19:46 1- kayobe 16:19:53 yeah that was fixed and merged 16:20:13 2- old deliverables 16:20:16 Only ironic 16:20:18 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009515.html 16:20:22 Only Ironic fell in that category 16:20:30 PTL warned and acked 16:21:10 3- Countdown email content 16:21:13 Proposed email is down to line ~463 of https://etherpad.openstack.org/p/relmgmt-weekly-emails 16:21:31 I reviewed right before the meeting. Everything looks good to me. 16:21:38 Anyone else have any feedback on it? 16:22:02 there is a subtlety beyond what the process mandates here 16:22:13 If not, I will send this out either later today or tomorrow morning. 16:22:31 basically on RC1 week we do cycle-with-rc's RC1s and branching, as well as force things that did not release at all yet 16:23:14 Which by this point should only include cycle-with-intermediary service deliverables. 16:23:17 But cycle-with-intermediary things that have done a train release (that we can fallback to), we give them an extra week to refresh 16:23:19 Or "other" 16:23:53 before we branch 16:24:15 so next week all RC things and all libs should be branched 16:24:25 and the week after, all intermediary things should be branched 16:24:43 So branch cycle-with-rc. Release cycle-with-intermediary but wait to force a branch until the following week. Sound about right? 16:24:59 They can propose the branch creation if they want to before then of course. 16:25:20 well, intermediary things that have not released any train, I would include the branch creation in the autorelease 16:25:29 (next week) 16:25:54 because it's unlikely that they are following along 16:26:03 Yeah, true. 16:26:13 I mean they can always stop us 16:26:23 I think we should systematically branch in the autorelease 16:26:27 * smcginnis checks if we've captured the gist of this in next weeks tasks 16:26:34 they can -1 it if they object 16:26:43 and it would save us extra work down teh line 16:26:49 if they don;t 16:26:57 yes 16:27:45 Ah, so that original note we want to change. 16:27:55 It said no stable branch creation, but now we are saying yes we should. 16:28:00 yes 16:28:09 I see no reason not to 16:28:19 I mean they can still object to it being cut 16:28:29 But we should propose it by default imho 16:28:33 And if they don't object, that's another indication that they are not playing along. 16:29:03 hmmm what about cycle-automatic 16:29:09 says we should not 16:29:19 Most of those are brachless (tempest plugins) 16:29:23 ah right 16:29:51 "Those do not need a stable branch created" says the definition 16:29:59 ++ 16:30:13 ok let's continue reviewing tasks there 16:30:23 #topic Review and assign next weeks tasks 16:30:53 Really bad timing, but I am at two different conferences on opposite coasts of the US next week. 16:31:03 So if someone else can sign up for these tasks, that would be best. 16:31:15 did you use any script to generate those in the past? 16:31:19 I will catch up and pitch in whenever I'm able to. 16:31:35 This is our first cycle-automatic. 16:32:01 I think Tony had started a script to do batch release proposals, grouping by teams. 16:32:05 Not sure if that's posted or not. 16:32:36 evrardjp: Didn't you have a nice bash script or something you used last time? 16:32:55 mmm 16:33:39 sorry catching up I was in another meeting at the same time 16:34:11 I don't have a script to batch release proposal handy, I probably removed it after use 16:34:37 I can easily generate lists of things we need to release 16:34:38 but I can help 16:34:55 then we can pick up / script them somehow 16:34:56 evrardjp: Would you have the time next week to take the release tasks for next week? 16:35:22 Help from ttx, and me whenever I'm able to get online without too many distractions. 16:35:41 as long as it's before wednesday, as I seem to have an extra travel on Thursday friday. 16:36:06 has to be done early in the week 16:36:12 yeah I see 16:36:28 I wonder if we should not finalize a quick-and-dirty script 16:36:40 I have events and travel on Thursday, but think I should be "butt in seat" on Friday. 16:37:03 ttx: do you mind if we pair along tomorrow to quick-and-dirty the script? 16:37:18 evrardjp: I can try... 16:37:28 lots of things this week 16:37:36 yeah I can start writing and you'll say it's plain wrong 16:37:42 :D 16:37:43 Oh I can do that 16:38:07 yes, let's sync tomorrow 16:38:21 Feels like the number of things to generate justifies it 16:38:57 31 cycle-automatic things 16:39:20 and like 80 cycle-with-rc things 16:39:39 And we'll need to do these cycle-automatic ones every cycle, so having a script will be important. 16:39:40 + the cycle-with-intermediary stragglers... like 10 of them 16:39:54 I just wish we had identified that need sooner 16:40:07 could have worked on that in a plane! 16:41:01 smcginnis: can you take the first task of analyzing why we missed things in libraries? 16:41:19 Yeah, I'll try to take a look through those and see what might have happened. 16:41:31 I'll add notes to that etherpad if I find anything interesting. 16:42:16 OK, so I think we're set on next weeks tasks. 16:42:33 I'm not 100% sure I'll be available at this time next week. 16:42:44 Would one of you be able to run the meeting if I'm a no show? 16:42:47 evrardjp: there are a bunch of scripts to propose releases already (new-release, propose-library-branches) 16:42:53 I am 100% sure I won't smcginnis 16:42:55 so it might just be very close 16:43:07 ttx: yeah, that's what I used last time. 16:43:13 should we move the meetign to Friday so that it's not just me 16:43:26 So option can be we skip the meeting and just catch up asynchronously in channel as we're each available. 16:43:38 Or yeah, as a special one time offer, we can move to Fridya. 16:43:46 I would be available then. 16:43:57 I think it would be good to process the autoreleases that did not get any feedback on Friday 16:44:27 have a hard stop at 16utc on Friday 16:44:32 can do anytime before 16:44:35 Carlos Goncalves proposed openstack/releases master: Releases for Octavia Queens, Rocky and Stein https://review.opendev.org/683202 16:44:44 I think it's a good idea, but I cannot ensure I will be there, probably still in conference or in travel. 16:45:00 ttx: I can do 1500 Friday. 16:45:21 ok deal 16:45:36 Great, updates on my calendar. 16:45:56 I'll post a notice to the ML to let others know in case they care. 16:46:11 ok 16:47:01 #topic Open discussion 16:47:10 Anything else for today then? 16:47:53 http://lists.openstack.org/pipermail/foundation/2019-September/002794.html 16:48:04 now the dats is official 16:48:06 date 16:48:31 Would be good to finalize the U schedule now that we have that. 16:48:40 Does the current proposal align well? 16:50:24 3 empty weeks between release and event 16:50:42 Seems pretty good then. 16:50:44 which is a bit large, but not usual. And that cycle is long already 16:50:51 not unusual I mean 16:50:58 Better than having it the same week. ;) 16:51:07 or the week after 16:51:29 nothing like doing a release and packing luggage at the same time 16:51:37 If we're good with it overall, I can get those nits updated. 16:51:57 I'm sure some folks would appreciate having a schedule to help plan. 16:52:43 yes, please update, then post a new ML post to flag it for final review? 16:52:59 Good plan. 16:53:08 OK, nothing more from me then. 16:53:27 oh, one bit of good infra news... during the last gerrit restart we implemented a configuration change to disable auto-replication at startup, so you no longer need to be wary of approving releases immediately following a gerrit restart now that there's no longer a multi-hour replication backlog to contend with every time we do that 16:53:28 nothing from me 16:53:49 fungi: Great! 16:54:39 so we'll still be wary of restarting the opendev gerrit if there are release jobs in flight so they're not lost, but triggering more right after a restart should be fine 16:54:44 anyway, that's all i had 16:55:06 OK, thanks everyone. 16:55:10 #endmeeting