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