16:03:10 #startmeeting releaseteam 16:03:11 Meeting started Thu Oct 1 16:03:10 2020 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:03:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:14 The meeting name has been set to 'releaseteam' 16:03:14 Ping list: ttx armstrong sboyron 16:03:20 #link https://etherpad.opendev.org/p/victoria-relmgt-tracking Agenda 16:03:51 #topic Review tasks completion 16:03:54 o/ 16:04:10 So tasks for the week... 16:04:23 Force RCs on Monday - those are all done. 16:04:40 RC1 deadline exceptions - I don't believe we have any left over. 16:04:55 agreed 16:05:23 Missing stable branches - looked like from the paste that there were only the trailing ones, so that's great. 16:05:46 I saw hberaud reminded QA about the various tasks. Another topic later to talk about that some more. 16:06:13 And ttx ran the script to add the release notes links for the projects that have merged their patches for a victoria landing page. 16:06:36 It's not in the process doc, but I've usually run that script randomly over the next several weeks to see if there are more. 16:06:55 Some projects are really good about landing those patches right away. Others can take a long time to get any attention. 16:07:05 So good to run it again occasionally to pick up those late ones. 16:07:40 Next task is really just a note to the team to allow new RCs as needed. 16:07:43 do we want everybody to +1 on this patch or it's more an highlight? 16:08:02 We don't need to get acks from everyone. We can just approve it. 16:08:08 ack 16:08:39 For new RCs, we want to encourage teams to do new ones to pick up things like translations or important bugs. 16:09:08 We just don't want to do them too frequently. It seems to work well to do the RC1, then wait until close to the final RC deadline to pick up those things for a final RC. 16:09:24 But we can allow them to do more as needed depending on each teams situation. 16:10:01 Final task, I will send the countdown email. I'll try harder to do that more timely this time. :) 16:10:15 :) 16:10:19 #topic Review countdown email content 16:10:31 #link https://etherpad.opendev.org/p/relmgmt-weekly-emails 16:10:46 I think I updated the content but not the subject line. Let me double check that. 16:11:25 Yeah, content looks right. Just missed the subject line. 16:11:45 LGTM 16:12:15 Good. Rereading it looks fine to me too. 16:12:18 #topic Assign R-1 tasks 16:12:34 Process remaining stable branch exceptions. 16:12:55 Since everyone had their stable branches, I think that first task is a noop this time around. \o/ 16:13:09 Notify the docs team. Thanks for grabbing that hberaud. 16:13:20 Since we don't actually have a docs team anymore, not sure what we need to do there. 16:13:38 It generally gets taken care of. Kind of like the QA tasks, they know what needs to be done. 16:13:44 ah 16:13:52 IIRC, AJaeger usually updates the docs things, so might be good to check in with him. 16:14:11 ack 16:14:26 I am doing for d-g and grenade 16:14:37 Test the release process. release-test is now c-w-i instead of c-w-rc, but that still works to make sure our jobs all pass. Like it could have caught this current breakage. 16:14:42 gmann: Thanks! 16:14:43 you could say "technical writing sig" instead of "docs team" i guess? 16:15:10 Thomas Bechtold proposed openstack/releases master: pymod2pkg: Release 0.26.0 https://review.opendev.org/755524 16:15:13 Yeah, I guess so. 16:15:37 +1 fungi 16:15:57 Next tasks - on Wednesday we should run tools/list_rc_updates.sh to see if there are any important but not yet released commits. 16:16:02 Thomas Bechtold proposed openstack/releases master: renderspec: Release 2.1.0 https://review.opendev.org/755522 16:16:18 This is a little subjective, but in general we want to look for anything that looks like it might be good to get in the initial coordinated release. 16:16:44 Things can be merged, but it's fine if the team wants to wait until after the coordinated release date to do a stable release. 16:17:12 Anyone want to take that? I can assist with giving feedback on any repos in question. 16:17:28 I am available 16:17:54 if the result is not too difficult to interpret 16:18:06 armstrong: do not hesitate to ask questions if you need help :) 16:18:16 armstrong: Great, thanks. Just let me know if there are any questions with the output. Or I guess just ask this channel in general, then any one of us can help provide input on that. 16:18:22 ok 16:18:36 I will finish out the victoria countdown emails. 16:18:41 The trick is to try to spot things that cannot be added after release as stable updates 16:18:49 So, I should run the script on Wednesday right? 16:18:49 and that are highly desirable 16:19:02 And I can run the propose-final-releases script to get the final releases. 16:19:03 Like... something that fixes the upgrade from the previous version 16:19:05 armstrong: Yep. 16:19:45 #topic Review process for cycle-automatic deliverables 16:20:09 This came up this week because one of the tasks in the process doc is to propose releases for the cycle-automatic deliverables. 16:20:19 But we don't have cycle-automatic deliverables anymore. :) 16:20:43 So I don't _think_ our process should change, but we should update the doc to be more specific/accurate now. 16:20:59 +1 16:21:00 I wanted to raise it here to see if there are any other thoughts or questions about that. 16:21:19 ttx: You led the charge to get rid of the model, so was also curious if you had any thoughts about it. 16:21:41 let me gather my thoughts 16:22:09 FWIW I agreed with the removal I don't see much value to keep an outdated process in our doc 16:22:47 we should probably doublecheck that nothing fell in the cracks 16:22:48 Hmm, now I am not seeing that model specifically mentioned in the doc. We may have dropped that. 16:23:02 I was reminded by someone asking in-channel when the tempest plugins would be tagged. 16:23:28 basically, cycle-automatic was about us proposing releass at the very last moment for a number of deliverables 16:23:42 but we are supposed to catch them all before, now 16:24:03 so checking that we have a deliverable for everything, including "type:other" cwi things, would be good 16:25:15 We may want to put a reminder in the process docs about tempest plugins and how they need to be tagged but not branched. 16:25:59 What was cycle-auto is now mostly the ones that are cwi with stable-branch-type: none 16:26:12 because afaict those tempest-plugins have been falling through the cracks 16:27:13 We tagged them all last cycle at the end. But then this cycle, I'm guessing they may have been excluded from the normal checking for proposing releases since they need to tag at the end, not during any of the milestones. 16:27:45 barbican-tempest-plugin 16:27:47 designate-tempest-plugin 16:27:49 freezer-tempest-plugin 16:27:51 heat-tempest-plugin 16:27:53 keystone-tempest-plugin 16:27:55 mistral-tempest-plugin 16:27:56 https://github.com/openstack/releases/commit/309e95eaad04f76c260e8645967f2d58f85dc7d9 16:27:57 monasca-tempest-plugin 16:27:59 murano-tempest-plugin 16:28:01 requirements 16:28:03 sahara-tests 16:28:05 solum-tempest-plugin 16:28:07 telemetry-tempest-plugin 16:28:09 requirements is probably off 16:28:11 but sahara-tests probably in 16:29:12 hberaud: maybe we catch "type:other" explicitly but not "type:tempest-plugin" 16:29:24 anyway that means we need to do it now :) 16:29:32 #link https://review.opendev.org/#/q/project:openstack/releases+branch:master+topic:victoria-c-a 16:29:36 Just a few outstanding. 16:30:08 ah, so you covered those 16:30:27 nice 16:30:45 Yeah, after the ping in the channel, I noticed we didn't call those out anywhere so I ran the handy script to get them proposed. 16:31:13 But I wanted to make sure we captured this in the process doc somehow so we didn't rely on someone asking about it again next cycle. 16:31:16 the other missing ones are all trailing 16:31:18 I was wondering why I didn't find victoria-c-a in our schedule 16:31:26 ;) 16:31:52 so could be worth to add it to the wallaby schedule too 16:32:18 Not necessarily in the schedule, but it should be in process doc to make sure we don't skip the step. 16:32:29 at least yes 16:32:30 Anyone want to take that as an action to do? 16:32:38 fire 16:32:55 (now multiplexing with another meeting, may answer slowly) 16:33:15 #action hberaud to add step for tagging cwi branchless (tempest) deliverables to process doc 16:33:34 That's probably good enough for now. 16:33:42 #topic Discuss about QA release steps 16:34:12 I think it's useful to have at least something in our process doc, at least as a safety to remind QA. 16:34:23 I added this topic to discuss a bit about https://wiki.openstack.org/wiki/QA/releases 16:34:42 I agreed we should keep a track about this 16:34:45 All of those tasks could probably be similified though, and just have a single note in the process stating "Remind QA team about end of cycle tasks" 16:34:54 but I don't think we need all these steps 16:35:03 hberaud: Since you are updating the process doc aleardy, want to also take care of that? 16:35:17 let's go 16:35:47 #action hberaud to simplify process doc steps to just remind QA about end of cycle steps 16:36:08 #topic Open floor 16:36:24 nothing on my end 16:36:33 Nothing else from me. 16:36:42 ttx is in another meeting now. 16:36:49 nothing else 16:36:54 Anyone else have anything for the meeting? 16:36:58 nothing 16:37:08 Great, we can wrap up then. 16:37:11 smcginnis: ah just one think 16:37:11 Thanks everyone! 16:37:15 Ok 16:37:15 thanks 16:37:49 I started to initialize an etherpad for wallaby, I will surely ping you soon to double check this one if you are ok with that 16:37:53 Oh, I should quickly point out, we've been the de facto maintainers for reno. There is a bug out there that could use some attenion if anyone has some time: 16:37:56 #link https://storyboard.openstack.org/#!/story/2008139 16:38:06 btw, the ensure-twine role should work again as of a few minutes ago, if someone has a concise list of failures i'm happy to reenqueue where possible 16:38:07 hberaud: I'd like to understand a bit more your tasks, will it be possible to explain me more ? 16:38:14 hberaud: Sounds good. Hopefully you've seen the script to help create that etherpad. 16:38:26 fungi: Awesome! 16:38:39 smcginnis: oh snap no... 16:38:42 i can also just go through the failures ml archive if there's no list yet 16:38:45 fungi: The failures all happened after the tag was pushed. Are we going to need to do some manual steps? 16:38:52 smcginnis: I did that at manually 16:39:00 fungi: They are all listed in the tracking etherpad. 16:39:02 smcginnis: we shouldn't, it would be reenqueuing of the tag ref 16:39:17 so specifically the things which happen after the tag has been pushed 16:39:19 fungi: Line 440 in the etherpad. 16:39:23 thanks 16:39:24 https://etherpad.opendev.org/p/victoria-relmgt-tracking lines 440+ 16:39:27 sboyron: sure, I'll ping you on monday to discuss a bit about that 16:40:13 hberaud: See bullet 4 under https://releases.openstack.org/reference/process.html#week-after-previous-release 16:40:47 fungi: Let us know if you need anything from us on those. Otherwise I will assume you've got the failures covered? 16:41:14 yeah, i'll report in here once they're all reenqueued 16:41:20 i'll try one first just to make sure 16:41:29 fungi: Thanks! 16:41:44 OK, that was a lot of stuff after saying there wasn't anything else to talk about. :D 16:41:47 Anything else? 16:42:11 * fungi refrains from doing his columbo impersonation 16:42:25 Only if we had video. 16:42:26 smcginnis: thanks 16:43:01 OK, thanks everyone! Almost time to hand the reigns over to our new fearless leader. We're getting close to the end of victoria. Thank you all for a good cycle! 16:43:19 #endmeeting