16:00:01 <smcginnis> #startmeeting releaseteam
16:00:02 <openstack> Meeting started Thu Apr 30 16:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'releaseteam'
16:00:06 <hberaud> o/
16:00:12 <smcginnis> #link https://etherpad.opendev.org/p/ussuri-relmgt-tracking Agenda
16:00:16 <smcginnis> Ping list: ttx armstrong diablo_rojo, diablo_rojo_phon
16:00:21 <armstrong> o/
16:00:42 <diablo_rojo_phon> o/
16:01:08 <smcginnis> #topic Review week tasks completion
16:01:26 <smcginnis> We got all of the RC1 deadline exceptions through.
16:01:54 <evrardjp> :)
16:02:00 <ttx> ohai
16:02:03 <smcginnis> generate stable branches for all cycle deliverables that are still missing one
16:02:18 <smcginnis> We have a few pending patches for this, but most have been done now.
16:02:32 <smcginnis> https://review.opendev.org/#/q/project:openstack/releases+branch:master+topic:ussuri-branch
16:02:38 <ttx> yes os-vif pycadf, karbor
16:02:48 <ttx> karbor-dashboard
16:03:03 <smcginnis> I did note in the commit messages that we would merge by tomorrow if no response.
16:03:29 <smcginnis> I can probably take a little time later today to see if anything else has merged or is in flight, but I would be surprised if that was the case.
16:03:39 <ttx> let me see if we can ping PTLs in this channel
16:04:23 <ttx> gibi, bauzas: see https://review.opendev.org/#/c/723687/
16:04:39 <ttx> knikolla: see https://review.opendev.org/#/c/723689/
16:05:25 <smcginnis> I don't see jiaopengju around for karbor.
16:05:43 <ttx> yes, but he was not CCed on the patch
16:05:46 <ttx> adding now
16:05:58 <ttx> done
16:06:15 <smcginnis> Was he assigned by the TC? I wonder why he didn't get added.
16:06:27 <ttx> no, he applied normally
16:06:34 <ttx> I think
16:06:42 <diablo_rojo_phon> He did.
16:06:43 <smcginnis> Hmm, my script log shows he was added by email address.
16:07:17 <ttx> or not
16:07:39 <ttx> anyway, would be good to give him until Monday
16:07:47 <smcginnis> Sure, we can wait.
16:07:56 <smcginnis> I can check if there is any reason to wait though.
16:08:02 <ttx> good idea
16:08:08 <smcginnis> If there are no patches out there and nothing merged, then we might as well get it done.
16:08:13 <ttx> ++
16:08:19 <smcginnis> "After all the projects enabled in devstack by default have been branched, we can engage with the QA, I18n and Requirements PTLs to finalize the stable branch setup"
16:08:28 <smcginnis> Thanks hberaud for getting those steps done.
16:08:37 <hberaud> smcginnis: you're welcome
16:08:48 <smcginnis> And "Ensure that all projects that are publishing release notes have the notes link included in their deliverable file"
16:09:03 <gibi> ttx: I'm on the nova meeting in parallel, I will chack back later
16:09:22 <smcginnis> I usually run that script again a couple times since some teams take awhile to merge the bot proposed patches to add the release note landing pages.
16:09:27 <ttx> gibi: thanks! It's the stable branch for os-vif.
16:09:35 <gibi> ttx: ack
16:09:45 <smcginnis> Thanks gibi
16:10:02 <smcginnis> Last thing is just about letting teams iterate on RCs.
16:10:03 <gmann> two meeting in parallel. QA stuff for ussuri devstack, grenade, d-g is all merged now.
16:10:15 <smcginnis> Thanks gmann
16:10:35 <smcginnis> I've seen at least one RC2, so that is happening. Countdown email will have a reminder about final RC deadline.
16:10:46 <smcginnis> #topic Assign next week tasks
16:10:56 <smcginnis> "Process any remaining stable branching exception" - one for all of us.
16:11:05 <smcginnis> Please review if and when you can.
16:11:19 <smcginnis> "Notify the documentation team that it should be safe to apply their process to create the new release series landing pages"
16:11:33 <smcginnis> This had always already been done by the team when I had checked in with them.
16:11:46 <smcginnis> But now that there isn't a docs team, I guess we notify sig chairs?
16:12:16 <evrardjp> yes
16:12:20 <evrardjp> let's see how that goes
16:12:23 <evrardjp> it's the trial by fire
16:12:24 <ttx> yes, can be an email to openstack-discuss
16:12:47 <ttx> so that someone else can pick it up
16:12:55 <smcginnis> Anyone want to sign up for that email?
16:13:17 <evrardjp> it probably should be sending to stephenfin and asettle
16:13:44 <smcginnis> Or we can just make sure stephenfin has a bunch of IRC pings in here. :)
16:14:02 <evrardjp> that's what I secretly thought doing
16:14:11 <smcginnis> OK, thanks hberaud for already signing up for the release-test.
16:14:13 <smcginnis> evrardjp: ;)
16:14:15 <evrardjp> but maybe stephenfin is not having pings in here
16:14:25 <smcginnis> And the check for last minute RCs.
16:14:31 <evrardjp> tbh I am not really sure what this entails, else I would take the action item
16:14:44 * stephenfin shakes fist at evrardjp
16:14:52 <evrardjp> you're welcome.
16:14:53 <smcginnis> Hehe, three times and he appears.
16:14:57 * evrardjp hands stephenfin a beer
16:15:25 <smcginnis> Last task is the normal countdown email, which I will do.
16:15:30 <evrardjp> smcginnis: yeah, I wonder why. Probably out of a Tim Burton movie?
16:15:30 <stephenfin> I _think_ AJaeger already handled the creation of the series landing pages
16:15:52 <evrardjp> ok I am taking the action item to follow up on that then
16:15:57 <smcginnis> See, always so proactive that I don't think we've ever had to initiate the process.
16:15:57 <stephenfin> cool
16:16:03 <smcginnis> Thanks!
16:16:06 <evrardjp> I will sync with stephenfin and AJaeger
16:16:46 <smcginnis> Oops :)
16:16:54 <smcginnis> #topic Review countdown email
16:17:08 <smcginnis> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails draft
16:17:55 <ttx> lgtm!
16:18:01 <smcginnis> Looks fairly straight forward. Not as much to say this close to the end other than be ready.
16:18:03 <hberaud> +1
16:18:07 <smcginnis> Dates check out I think.
16:18:22 <smcginnis> #topic Python runtime validation and automation
16:18:36 <smcginnis> This idea came up last week, so I made a note here to make sure the idea was brought up.
16:18:59 <smcginnis> We have automation now to switch over job templates like ussuri=>victoria.
16:19:08 <smcginnis> Thanks evrardjp for getting most of that started.
16:19:40 <evrardjp> pinging the wrong person there, I didn't do nothing
16:19:42 <smcginnis> I then manually (well, semi-manually) proposed patches to repos that had merged those job changes to add the py38 metadata to their package info.
16:19:48 <smcginnis> evrardjp: You started it at least.
16:20:03 <evrardjp> ok if you say so ! :)
16:20:14 <smcginnis> So the question came up as to whether that can be automated.
16:20:14 <evrardjp> haha
16:20:20 <smcginnis> The change itself isn't too hard.
16:20:39 <smcginnis> The tricky part would be to have the awareness programatically to know what python version to add.
16:20:52 <smcginnis> Python runtimes are decided by the TC.
16:21:15 <smcginnis> It's all in rst right now, but was thinking we could get that into data/runtimes.yaml or something.
16:21:39 <smcginnis> Then we would be able to script figuring out what runtimes were needed for a cycle and be able to propose patches to do the updates.
16:21:39 <hberaud> if it's in a script then TC could store this info in this script and update it if needed for current cycle
16:22:03 <smcginnis> There could be a sphinx extension that pulls the info into the governance docs even.
16:22:10 <evrardjp> mmm
16:22:22 <evrardjp> while the idea is very simple and noble, the text on each page of the PTI changes
16:22:22 <hberaud> I mean I suppose we will have a script to run...
16:22:30 <smcginnis> But the other tricky part would be that right now our branching automation only knows and cares about series names.
16:22:38 <smcginnis> So really just a couple string passed along.
16:22:49 <evrardjp> though I suppose we could have a support matrix, and restructure our docs.
16:22:51 <smcginnis> We would need to include more data to be able to do this.
16:23:25 <smcginnis> evrardjp: I was thinking it would just be an rst directive that would generate a bullet list of the runtimes or something.
16:23:37 <evrardjp> yeah I understood that part
16:24:03 <evrardjp> I think it's fine
16:24:12 <smcginnis> Anyway, not looking to solve this here. I just wanted to raise the idea up to the group to get people thinking about it in case there were any better ideas. Or strong motivation to try something out.
16:24:26 <evrardjp> I don't foresee anyone complaining about this kind of structured data
16:24:30 <smcginnis> Otherwise any time we add a new python runtime, we will just have to know to add that to the package metadata.
16:24:56 <smcginnis> Which, given how we've been changing runtimes often, I do wonder if this will not really be needed much for a bit.
16:25:13 <smcginnis> Depends on how soon distros decide to pick up py39 once that is out.
16:25:26 <smcginnis> I would guess we might have a few cycles before that happens.
16:25:47 <smcginnis> So trade off if it's worth putting a bunch of automation in place at this point or not.
16:25:58 <smcginnis> Might be easier to just stick a note somewhere saying it needs to be done.
16:26:16 <hberaud> I agree
16:26:26 <smcginnis> Not even really a release team issue to deal with, just that we have the automation for the bot proposed patches that do other cycle-based updates.
16:26:31 <evrardjp> because it's a multiple teams effort, I think it's better coordinated by human
16:26:55 <smcginnis> Anyway, I can check it off the list as having raised the idea and putting it out there. ;)
16:26:59 <smcginnis> #topic Open discussion
16:27:11 <evrardjp> or allow me to rephrase: It's good that we have someone kicking the TC to have the runtimes done as soon as possible, so that the rest of the chain can consume this
16:27:15 <ttx> sorry catching up
16:27:31 <evrardjp> and if that's done manually it's probably not much effort to just edit things
16:27:41 <ttx> yes Python runtimes could be defined in a YAML that would end up generating a governance webpage
16:27:49 <ttx> and then we could programmatically read that
16:28:03 <evrardjp> ttx: the problem is that we recently had conversations about justifications of versions in PTI
16:28:13 <ttx> ah ok
16:28:23 <evrardjp> but I guess we could have a "description"/explanation field next to the "version" :)
16:28:38 <evrardjp> https://governance.openstack.org/tc/reference/runtimes/victoria.html compared to https://governance.openstack.org/tc/reference/runtimes/ussuri.html for example
16:29:07 <evrardjp> but I don't think the data there will be much of a big deal, it's maybe a lot of automation for a two liner.
16:29:13 <smcginnis> evrardjp: What was this discussion about? Not defining versions?
16:29:22 <evrardjp> https://xkcd.com/1205/
16:30:27 <evrardjp> smcginnis: IIRC, it was not so easy to have consensus on what needed to be there. But the problem was that this _changed_ over time
16:31:03 <evrardjp> so when should the automation pickup this?
16:31:15 <smcginnis> I thought it wasn't really a consensus thing. What distros are shipping at the start of the cycle, what runtimes do they ship by default = what runtimes we need to support.
16:31:16 <evrardjp> when do we assume "final"
16:31:25 <evrardjp> smcginnis: that's the idea
16:31:35 <evrardjp> but wording wasn't very simple IIRC
16:31:41 <evrardjp> it's all fuzzy in my head
16:31:45 <smcginnis> :/
16:31:47 <smcginnis> Oh well.
16:32:16 <evrardjp> https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html is the policy, it's more than a few lines :)
16:32:21 <fungi> as to when 3.9 is likely to be added, ubuntu has been tending to add packages for each new minor python version to their most recent lts pretty much as soon as the python community releases them
16:32:37 <smcginnis> I did add notes to our process doc to ping the TC on these runtimes at least, so we can make sure a job template is defined in time for the automation to work of switching from one cycle template to the next.
16:32:48 <smcginnis> fungi: OK, so maybe we will see that sooner than I thought.
16:33:02 <fungi> python 3.9 final is scheduled for october
16:33:16 <fungi> so likely our "w" cycle
16:33:19 <evrardjp> oh I think I remember now. I think it's fine if we just use a data file.
16:33:46 <evrardjp> I don't think it has changed on merging, my bad.
16:33:51 <evrardjp> after first merge*
16:34:01 <smcginnis> Well, we can think about it for a bit. Not a big rush right now
16:34:17 <smcginnis> Nothing else from me. Wrap up early?
16:34:37 <fungi> yeah, python 3.9 is scheduled to release the week before openstack victoria, so very likely in focal (20.04 lts) by the start of w
16:34:42 <evrardjp> confirmed
16:34:57 <evrardjp> (my part, not what fungi said)
16:35:14 <evrardjp> we can wrap up, sorry for the long rant in my head
16:35:19 <smcginnis> :)
16:35:29 <evrardjp> tl;dr: we can automate just fine!
16:35:31 <evrardjp> :D
16:35:40 <smcginnis> OK, thanks all. I appreciate the time spent on release management.
16:35:44 <ttx> need to run...
16:35:48 <smcginnis> #endmeeting