16:00:10 #startmeeting releaseteam 16:00:11 Meeting started Thu Apr 2 16:00: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:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:14 The meeting name has been set to 'releaseteam' 16:00:15 Ping list: ttx armstrong diablo_rojo, diablo_rojo_phon 16:00:25 o/ 16:00:26 o/ 16:00:26 #link https://etherpad.openstack.org/p/ussuri-relmgt-tracking Agenda 16:00:45 o/ 16:00:54 o/ 16:00:58 * evrardjp lurks 16:01:04 #topic Review week tasks completion 16:01:16 o/ 16:01:20 We're starting to get to the point in the cycle where we get a little busier with tasks. 16:01:35 First one - non-client lib patches. 16:01:35 hey \o 16:01:42 #link https://review.opendev.org/#/q/topic:u-final-lib+(status:open+OR+status:merged) 16:01:59 We've gotten a few through already. 16:02:11 At least one has at least responded with needing a little more time. 16:02:25 So overall I think we're pretty good there. 16:02:42 Any questions, comments, or concerns about those before I move on? 16:02:48 nope 16:02:59 Next - Update the feature list and allowed stable branch names in devstack-gate for the new stable branch. 16:03:05 elod: I think you covered that? 16:03:30 yes, the patch is there 16:03:46 Happen to have a link to that handy? 16:03:58 with a +1, https://review.opendev.org/#/c/715272/ 16:04:11 Awesome, thanks elod 16:04:28 Countdown email - I will get that sent tomorrow. 16:04:35 Post porcess update for R-7 16:04:41 #link https://review.opendev.org/#/c/716635/ 16:04:46 *process 16:05:04 ttx: Looks like hberaud just had a question on there. 16:05:21 Can probably answer that here, but yes, these are just a template to base things on. 16:05:24 ack 16:05:40 smcginnis: ack thanks 16:06:04 One minor typo caught (good eyes hberaud!) but I think we can pick that up in a follow up. 16:06:19 smcginnis: sure 16:06:52 fixing it up now 16:06:57 OK, perfect. 16:07:05 this is my major concern so if it's ok for a follow up fix then I +2 too 16:07:20 sound goods for you? 16:08:15 I think ttx is updating it, so we can wait for that. 16:08:31 #topic Adding new deliverables to TripleO train release 16:08:36 yes running tests 16:08:49 This has since been resolved with the team, but wanted to still bring it up for awareness. 16:08:52 #link https://review.opendev.org/#/c/715967/ 16:09:09 ttx has a well written comment in there as to why we don't want to do that. 16:09:22 So if you haven't seen that, very worth reading. 16:09:43 ack 16:09:59 Unless there are any questions, that's all from me. Just wanted to point that out to make sure everyone understood why we don't want to do that generally. 16:10:12 #topic Adding ovn-octavia-provider 16:10:19 #link https://review.opendev.org/#/c/710200/ 16:10:20 thanks for the highlight smcginnis . 16:10:35 This one is for ussuri. 16:10:44 Technically we are past the membership freeze. 16:11:00 it's a code split though 16:11:06 Hey. We would like to ask you to add it to ussuri. It is one of the last parts of this neutron RFE: https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge 16:11:09 The main issue is to trap distributions 16:11:23 like they would realize they have to package that very late 16:11:25 However, this was part of a different deliverable before, and it's a driver (I think) that is not a big deal.. 16:11:41 We were unable to fit the date. This driver was a part of networking-ovn in stable/train 16:11:43 I think it's strategic too for the team 16:11:48 If it's missed, it would only be applicable to a very certain configuration, right? 16:12:24 So I think we can approve it, but I'd like that the change is aggressively communicated to distributions and our deployment mechanisms to make sure they are not surprised 16:12:38 ttx: +1 16:13:02 like a openstack-discuss thread +CC to people we know are in charge of maintaining those things at SUSE, Ubuntu, Fedroa etc 16:13:22 The membershipFreeze is there to protect them, it's not just for funz 16:13:46 we do have RDO packaging ongoing downstream 16:14:00 I agree that in this case the it's unlikely to generate unsolvable issues for them 16:14:03 maciejjozefczyk: Can you post something to the mailing list tagging [packaging] (I think?) explaining the situation so anyone working on distro packaging gets a fair warning about it? 16:14:12 which is why I'm ok for the late exception :) 16:14:12 smcginnis, sure 16:14:56 fnordahl: ^ 16:15:13 And since I feel likes it's my duty to say it - don't be late next time [shakes finger at team] :D 16:15:31 :) 16:15:42 ttx, smcginnis evrardjp Thank you! 16:17:02 OK, release managers, please vote on that patch if you are good with this. Or if you are not, I suppose. 16:17:12 Thierry Carrez proposed openstack/releases master: Update milestone2-to-milestone3 process https://review.opendev.org/716635 16:17:13 But if you are not, please raise concerns here now so we can discuss. 16:20:19 #topic Assign next week tasks 16:20:35 Process any remaining library freeze exception 16:20:50 I can do that, but since I submitted them it would be good to have someone else do that. 16:21:11 Any volunteers? 16:21:41 that's more of an interactive process anyway 16:22:03 like we discuss on the channel to make final calls on everything 16:22:10 (and on the reviews themselves) 16:22:15 Yeah 16:22:21 We can leave that open to the team. 16:22:36 "Early in the week, email openstack-discuss list to remind PTLs that cycle-highlights are due this week so that they can be included in release marketing preparations." 16:22:45 diablo_rojo: Do you want to take care of that? ^ 16:23:41 No response, so now your name is down for it. :) 16:23:47 all the remaining tasks are around the same thing 16:24:07 I cannot type today. 16:24:16 Yeah, I will get things proposed. 16:24:17 well, i guess someone else could take line 542 16:24:38 but it does not hurt if it's all done by the same person 16:24:50 to make sure all areas are covered 16:24:51 I can try to do that 16:25:16 That's a good one to pick up. Let me know if there are any questions. 16:25:19 Thanks for volunteering. 16:25:24 Sorry I am doing like 5 conversations at once, its like whack-a-mole. 16:25:25 the -2 on requirements is good coming from the RelMgt PTL 16:25:30 Happy to send that email though. 16:25:37 smcginnis: sure, you are welcome 16:25:38 about the cycle highlights 16:25:40 diablo_rojo: ++ 16:25:59 And I will send the countdown email, per usual. 16:26:05 OK, that's all the tasks then. 16:26:29 #topic Review countdown email 16:26:54 We're now into the process doc instead of the etherpad on those, right? 16:27:02 yes, in theory 16:27:06 Haven't checked :) 16:27:23 #link https://releases.openstack.org/reference/process.html#r-5-week-milestone-3 16:27:26 should not be much different but meh 16:27:34 Please review the content of bullet 7 there. 16:27:47 na it's the one just above 16:28:09 The R-5 email sent at the end of R-6 16:28:14 #undo 16:28:15 Removing item from minutes: #link https://releases.openstack.org/reference/process.html#r-5-week-milestone-3 16:28:24 #link https://releases.openstack.org/reference/process.html#r-6-week-final-library-release-deadline 16:28:28 Bullet 3. 16:28:32 That makes more sense. :D 16:28:48 So a few placeholder variables to update, but looks good. 16:28:58 smcginnis: so my suggestion would be to copy it to a new etherpad and crowdsource the replacemeent of all $values 16:29:06 that way we can approve it in-meeting 16:29:24 Maybe we should just stick to using https://etherpad.openstack.org/p/relmgmt-weekly-emails? 16:29:43 smcginnis: that etherpad is confusing 16:30:08 would rather only have one source of truth 16:30:27 if possible not an etherpad 16:30:29 How about I repurpose that etherpad as the weekly scratchpad. 16:30:44 sure that works.. unless you want to keep old data 16:30:48 Then each week after the countdown is sent, I can replace all content with the next countdown draft. 16:30:56 works for me 16:31:04 +1 16:31:06 We have something we can all update and tweak before sending the next one. 16:31:07 usage will probably show what's best 16:31:38 kill it kill it 16:31:38 (which means that we might need to keep older versions easily available on the etherpad to shape the content) 16:31:51 haha 16:32:24 I like the idea of the weekly scratchpad though , don't get me wrong :) 16:32:38 just that sometimes I need a little bit of context of the past 16:32:58 * evrardjp goes back to silence 16:33:08 lol 16:33:19 Wait, the deadlines just got overwritten. 16:33:54 yes I fixed them 16:34:06 Did we send the wrong ones last week? 16:34:15 well, they evolve 16:34:23 taht's why they are in process 16:34:36 for this week we need to start mentioning RC1 and all 16:34:54 see template :) 16:35:28 Yeah, we just had to drop the non-lib and RC. 16:35:30 lgtm 16:35:38 Looks good, just got worried we messed up something last week. 16:35:51 OK, I will send this tomorrow, my morning. 16:36:03 #topic Open discussion 16:36:30 I feel like I had something for open discussion, but now I can't remember. 16:36:35 I'm sure I will remember later. 16:36:59 notepads aren't too bad for that 16:37:07 Right!? 16:37:20 Maybe it was to point out rocky-em should be wrapped up now. 16:37:33 Doug and Stephen helped out with some of the reno issues we've been hitting. 16:37:48 Which makes me feel a lot better, because I'm sure we would have hit more issues with that as we get to RC. 16:38:07 So heat made it through, now we can process the change to update the series status. 16:38:41 ;) 16:39:27 If someone else can take a look at https://review.opendev.org/#/c/713926/1 and approve that. 16:40:16 OK, I don't have anything else. 16:40:29 Thanks for everyone's help with releases. 16:41:36 Thanks smcginnis! 16:41:40 thanks 16:41:43 #endmeeting