16:00:08 <smcginnis> #startmeeting releaseteam
16:00:09 <openstack> Meeting started Thu Apr  9 16:00:08 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'releaseteam'
16:00:15 <smcginnis> Ping list: ttx armstrong diablo_rojo, diablo_rojo_phon
16:00:19 <diablo_rojo> o/
16:00:21 <smcginnis> #link https://etherpad.openstack.org/p/ussuri-relmgt-tracking Agenda
16:00:26 <armstrong> o/
16:00:34 <elod> o/
16:00:52 <ttx> o/
16:01:11 <smcginnis> We are at R-5 in the tracking etherpad.
16:01:29 <smcginnis> #topic Review week tasks completion
16:01:40 <smcginnis> Processing remaining lib freeze patches
16:01:53 <smcginnis> That went surprisingly well. I think I did the last one on Sunday.
16:02:06 <ttx> niiice
16:02:19 <smcginnis> Email ML for cycle-highlights.
16:02:29 <smcginnis> I saw diablo_rojo got that out and patches have been coming in.
16:02:44 <smcginnis> Propose autoreleases for cycle-with-intermediary client libraries which had commits that have not been included in a release
16:02:49 <smcginnis> I did that one.
16:02:58 <smcginnis> I did leave out stable branching with the plan to follow up later.
16:03:28 <smcginnis> I wanted to get in the branching job updates to propose the victoria job template updates.
16:03:44 <smcginnis> That is now mostly working, one small update just proposed before this meeting.
16:03:55 <smcginnis> I will follow up with patches to do the branching now that that is in place.
16:04:18 <smcginnis> Any help getting those patches through once we get PTL ack is appreciated.
16:04:39 <smcginnis> At least nova has already communicated that it may not be until Monday due to waiting on patches to make their way through the gate.
16:04:44 <ttx> been working through them
16:04:52 <smcginnis> Thanks!
16:04:59 <smcginnis> Next item -
16:05:00 <smcginnis> Evaluate any libraries that did not have any change merged over the cycle to see if it is time to transition them to the independent release model.
16:05:02 <ttx> where i didn't approve immediately that was because I would welcome second opinion
16:05:12 <openstackgerrit> Merged openstack/releases master: Release final python-ironic-inspector-client for ussuri  https://review.opendev.org/718249
16:05:18 <ttx> smcginnis: in some cases because the patch was modified and I want to make sure you still are ok with it
16:05:20 <smcginnis> OK, I will try to take a look through if no one else gets to it by then.
16:05:40 <ttx> so feel free to +2a your own patches if they have a +2 from me
16:05:48 <smcginnis> Doesn't hurt to have more eyes on these patches now that we are getting to the freeze.
16:06:13 <smcginnis> I did not check which libs didn't have any releases this cycle yet.
16:06:40 <smcginnis> Been waiting to get some of the final releases through first. Actually seems like maybe we should move this step in the process to the next week
16:07:04 <smcginnis> Though I suppose we want to do it now to make sure the communication happens with the team and they are able to quickly do a release if they need to?
16:07:33 <ttx> hmm
16:08:13 <ttx> let's see what that email said
16:08:55 <smcginnis> I think actually with our proposing releases for everyone, most should not have gone this far without any releases.
16:08:58 <ttx> it's not just libs
16:09:04 <smcginnis> True.
16:09:10 <ttx> It's actually not libs
16:09:27 <ttx> The goal is to warn people with enough lead time befroe RC1 week yes
16:09:40 <ttx> So on this week we warn those that haven't done any release
16:09:41 <smcginnis> OK, I will make sure to look at that later today or in the morning tomorrow.
16:09:57 <ttx> Then next week we warn those who did not make a *recetn* release
16:09:59 <ttx> recent
16:10:06 <ttx> that's why it's staged
16:10:06 <openstackgerrit> Merged openstack/releases master: Release final python-blazarclient for ussuri  https://review.opendev.org/718241
16:10:13 <smcginnis> OK, makes sense.
16:10:38 <smcginnis> Next - list c-w-i deliverables that have not been released.
16:10:52 <ttx> I mean, we could totally skip this one, they would get caught next week. But it acts as a good reminder
16:10:53 <smcginnis> hberaud put together that list and tagged each team on the ML.
16:11:10 <smcginnis> Yeah, good to have as much warning as possible so they have time.
16:11:13 <ttx> Oh I'm confused
16:11:30 <ttx> You mean the lib release model change
16:11:37 <ttx> line 539
16:11:53 <smcginnis> Yeah
16:12:11 <ttx> yeah that could be moved to next week
16:12:37 <smcginnis> I'll still plan on taking a look before then just to make sure I understand where things are with those.
16:12:38 <ttx> but usually they are caught this week
16:12:48 <ttx> as the leftover of those we autoreleased
16:13:07 <ttx> I mean, they will still be around next week :)
16:13:12 <smcginnis> The only ones I can think of would be anything that hadn't merged any changes at all this cycle. That should be very rare, but it's possible.
16:13:24 <ttx> yes rare with python2 changes
16:13:32 <ttx> like probably none
16:13:38 <smcginnis> I hope so.
16:13:57 <smcginnis> OK, Friday, remind requirements team to freeze changes.
16:14:05 <smcginnis> I will make sure to sync with prometheanfire on that.
16:14:34 <smcginnis> And last task, send out the weekly email. On my todo list for tomorrow morning.
16:14:44 <ttx> model at https://releases.openstack.org/reference/process.html#r-5-week-milestone-3
16:15:03 <smcginnis> #topic Assign next weeks tasks
16:15:37 <smcginnis> Process remaining client releases. I think that can be all of ours.
16:15:51 <ttx> +
16:15:54 <ttx> 1
16:16:02 <smcginnis> Freeze all cycle-based lib releases.
16:16:33 <smcginnis> After the current batch, we should have FFE requests going to the ML with the requirements PTL OK before we process any new lib releases.
16:16:54 <smcginnis> So I guess this is a task for everyone again. If you see any of those, please direct the requestor to follow that process.
16:17:14 <smcginnis> Propose stable/$series branch creation for all client and non-client libraries that had not requested it at freeze time.
16:17:17 <elod> note,
16:17:23 <smcginnis> I will take that one.
16:17:28 <elod> this patch is not yet merged: https://review.opendev.org/#/c/715272/
16:17:29 <ttx> yep, no more lib releases -- check
16:17:40 <elod> I guess that is needed for this task
16:18:06 <elod> (set up ussuri)
16:18:09 <smcginnis> I think it must default to master or something.
16:18:18 <smcginnis> But might be good to ping the QA team to get that through now.
16:19:07 <elod> Ok, I'll ping some more cores from devstack-gate :)
16:19:12 <gmann> ack.
16:19:12 <smcginnis> elod: Thanks!
16:19:18 <smcginnis> Haha, and done. :)
16:19:23 <elod> gmann: thanks :D
16:19:36 <smcginnis> Next task - List cycle-with-intermediary deliverables that have not been refreshed in the last 2 months.
16:19:45 <smcginnis> This is the one that picks up services and anything else.
16:20:03 <smcginnis> Anyone want to volunteer for that one?
16:21:22 <smcginnis> OK, I will put my name down, but if anyone ends up with extra free time, feel free to grab it.
16:21:40 <smcginnis> And send weekly email - I've got that one.
16:21:54 <smcginnis> #topic Ironic release model
16:22:16 <smcginnis> I thought I had a link to the mailing list thread in there, but I must have forgotten that.
16:22:23 <smcginnis> Hopefully you've all seen the discussion.
16:22:50 <smcginnis> Wondering ideas from the team on how we can meet that teams needs while still making sure we are able to communicate to downstream what to expect.
16:23:15 <smcginnis> They would like one release at the end of the cycle, but have the option to do more if needed.
16:23:34 <smcginnis> So basically, c-w-i, without being hassled to actually do intermediate releases if they don't want to.
16:23:37 <ttx> I posted options on the etherpad
16:23:56 <ttx> I think we can take two roads
16:24:08 <ttx> One is a minor change -- Evolve cycle-with-intermediary to allow 0+ releases.
16:24:15 <ttx> If none are produced, stable branch at last-available release
16:24:34 <prometheanfire> for the freeze, ya, though given gate's slowness there will likely be some straglers
16:24:42 <ttx> The other is a more dramatic change -- collapse with-rc and with-intermediary
16:24:52 <smcginnis> prometheanfire: Yeah, that's likely. Thanks!
16:25:04 <ttx> I like that it goves flexibility for teams to have a cycle with one release, then another with 4
16:25:19 <ttx> without us having to juggle release model changes
16:25:27 <ttx> which is a waste of time for everyone
16:25:48 <ttx> smcginnis: could you expand on poor communication?
16:26:06 <ttx> (personally I think we need to simplify)
16:26:19 <smcginnis> Well, with the current release models, that commicates what and when to expect new code to be released and potentially packaged.
16:26:34 <ttx> smcginnis: we have that at final release though
16:26:42 <smcginnis> Under this proposal, it makes it harder for anyone creating packages to know whether to expect anything or not.
16:26:48 <ttx> so we guarantee they will have somethign every 6 months
16:26:48 <openstackgerrit> Colleen Murphy proposed openstack/releases master: Add keystone Ussuri cycle highlights  https://review.opendev.org/718748
16:26:54 <ttx> but not more
16:27:06 <ttx> smcginnis: true
16:27:16 <ttx> I'm not sure they anticipate our moves though
16:27:16 <smcginnis> Yeah, probably not a big issue, but something we should be aware of.
16:27:27 <ttx> Basically I think the ship has sailed for those cons
16:27:33 <smcginnis> We would just have to communicate what to expect under the new changes.
16:27:40 <ttx> We do not really drive best practices anymore with cycle-with-i
16:27:53 <ttx> we do not really need test releases anymore
16:28:00 <smcginnis> I'm actually very in favor of simplifying things, especially with resources.
16:28:06 <ttx> and nobody looks at release model before packaging
16:28:20 <ttx> the only thing we need to assess is the risk of drift
16:28:38 <ttx> i.e. bitrot, making sure things actually work
16:28:46 <ttx> before we include them
16:29:06 <ttx> with "0" being an option, there is potential for bitrot
16:29:11 <smcginnis> On our end, we can plan to do release-test releases at each milestone to test our automation.
16:29:23 <smcginnis> But that doesn't address issues on the project's end.
16:30:16 <smcginnis> I'd be a little concerned getting rid of RC releases.
16:30:42 <ttx> yes, to me that's the only potential drawback. With the current process we kinda force minimal activity
16:30:48 <smcginnis> That seems to be good practice to branch and control what then gets backported to the soon-to-be stable branch.
16:31:20 <ttx> Oh we'd keep that
16:31:29 <smcginnis> We could say if no releases by that point, then do an RC. Otherwise if there has been other releases done during the cycle, up to the teams if they just want to do one final release.
16:31:32 <ttx> Just not .0rc1 etc
16:32:03 <ttx> We'd still have an early release and branch stable at that
16:32:12 <ttx> like we do for c-w-i currently
16:32:31 <smcginnis> So lib freeze, client freeze, service freeze dates?
16:32:52 <ttx> that's what we curently have (service freeze being the RC1 deadline really)
16:33:02 <ttx> We'd still advise teams to have a feature freeze and all
16:33:08 <ttx> but not enforce it with a release model
16:33:50 <ttx> That said, i suspect some teams actually like the cycle-with-rc model
16:34:02 <ttx> in which case I guess we could keep it
16:34:09 <smcginnis> If things aren't quite ready, I think it would be good to give teams the option to have that service freeze date release be either an actual full release, or an RC release with the plan to follow up with a final release.
16:34:40 <ttx> allowing 0+ in c-w-i will go a long way to eliminate release model change churn anyway
16:34:50 <ttx> It's really a topic for PTG
16:35:04 <smcginnis> Yeah, this would be a good one to sit down and talk through with a whiteboard.
16:35:12 <ttx> virtually or not
16:35:19 <smcginnis> I don't think we can properly do it here in this meeting.
16:35:23 <ttx> But yes, good to statr thinking about it
16:35:28 <smcginnis> This is a good start though.
16:35:46 <smcginnis> Definitely something we should ponder for a little while before making any changes.
16:36:13 <diablo_rojo> agreed
16:36:22 <smcginnis> Let's revisit this topic later. I think this has been a good start to get everyone thinking.
16:36:58 <smcginnis> Anything else to say before I move along?
16:37:37 <ttx> nope
16:38:04 <smcginnis> #topic Stable branch name enforcement for independent deliverables
16:38:11 <smcginnis> #link https://review.opendev.org/718144
16:38:22 <smcginnis> ttx: I might need your historical perspective on this.
16:38:29 <smcginnis> But to recap.
16:38:44 <smcginnis> We currently enforce branches need to have feature/ or stable/ prefixes.
16:39:03 <smcginnis> And even in independent, we require that stable/X be the name of a series.
16:39:14 <smcginnis> Which seems odd to me for independent deliverables.
16:40:01 <ttx> yes that is odd
16:40:08 <ttx> since they don;t have to have stable branches
16:40:48 <smcginnis> So for the ones that would like it, I think it makes sense to have them named stable/X, but I don't think we should enforce that X = a series name.
16:42:00 <openstackgerrit> Michał Dulko proposed openstack/releases master: Add kuryr-kubernetes cycle-highlights for Ussuri  https://review.opendev.org/718753
16:42:05 <smcginnis> If there isn't a historical reason that we wanted that, I can put it on my list to someday look at changing that validation code to allow independent to have more flexibility on those branch names.
16:42:23 <openstackgerrit> Michał Dulko proposed openstack/releases master: Add kuryr-kubernetes cycle-highlights for Ussuri  https://review.opendev.org/718753
16:42:39 <smcginnis> In the meantime, we do have the option to do what was done there and add specific deliverables to the list that are ignored.
16:43:03 <smcginnis> Any other thoughts?
16:43:22 <ttx> I'm surprised taht we do
16:43:32 <ttx> swift has stable/2.0 things iirc
16:43:52 <fungi> ceilometer also did it before it was cool
16:44:08 <fungi> or that may have been gnocchi
16:44:20 <ttx> smcginnis: would be good to check why that check was added
16:44:56 <smcginnis> It looks like things have been refactored multiple times since it was added, so it will just take some digging to get to where and why it was added.
16:45:26 <smcginnis> My guess is multiple unrelated changes accidentally ended up making it being enforced for independent, when that was not the orginal intent.
16:45:32 <smcginnis> But I can try to figure that out.
16:46:36 <smcginnis> I'll let everyone know if I find out more.
16:46:39 <smcginnis> #topic Review countdown email
16:46:49 <smcginnis> #link https://etherpad.openstack.org/p/relmgmt-weekly-emails Countdown draft
16:48:29 <smcginnis> Re-reading the draft, nothing stands out to me.
16:48:51 <openstackgerrit> Slawek Kaplonski proposed openstack/releases master: Add Ussuri cycle highlights for Neutron  https://review.opendev.org/718382
16:48:55 <smcginnis> If anyone finds anything wrong, please update in the next ~18 hours or so.
16:49:01 <smcginnis> I will send it out tomorrow.
16:49:26 <diablo_rojo> Will do.
16:49:47 <smcginnis> #topic AOB
16:50:25 <ttx> hmm
16:50:37 <ttx> that's the wrong email
16:51:09 <ttx> The right one starts with "We just passed feature freeze!"
16:51:16 <smcginnis> Shoot, you are right.
16:51:25 <ttx> https://releases.openstack.org/reference/process.html#r-5-week-milestone-3
16:51:29 <ttx> not teh week after
16:55:55 <ttx> lgtm
16:56:02 <smcginnis> OK, updated. Please take a look at the new content.
16:56:28 <smcginnis> That's all I had. Anything else before we close?
16:57:24 <smcginnis> OK, thanks everyone for all your help and work on the release team.
16:57:28 <smcginnis> #endmeeting