16:00:01 <smcginnis> #startmeeting releaseteam
16:00:02 <openstack> Meeting started Thu Jul  9 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <openstack> The meeting name has been set to 'releaseteam'
16:00:13 <smcginnis> Lonely ping list: ttx
16:00:22 <smcginnis> #link https://etherpad.opendev.org/p/victoria-relmgt-tracking Agenda
16:00:23 <fungi> it makes him feel special
16:00:29 <smcginnis> :)
16:00:31 <diablo_rojo> o/
16:00:35 <evrardjp> he is always special
16:00:39 <armstrong> o/
16:00:44 <smcginnis> Hey, it's evrardjp! :)
16:00:46 <hberaud> o/
16:00:56 <diablo_rojo> I guess I should read myself to the ping list
16:01:43 <smcginnis> #topic Review email contents
16:01:52 <smcginnis> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails Email draft
16:02:07 <smcginnis> Please take a look and make any corrections you see fit.
16:02:16 <smcginnis> I will send it out tomorrow.
16:02:35 <ttx> o/
16:02:40 <smcginnis> Basically just covers the need to do releases for c-w-i for the upcoming milestone-2.
16:03:01 <smcginnis> Unless there are any comments on that, we can move ahead.
16:03:21 <ttx> smcginnis: hmm
16:03:33 <ttx> "Other non-library deliverables that follow the cycle-with-intermediary
16:03:34 <ttx> release model should have an intermediary release before milestone-2.
16:03:36 <ttx> Those who haven't will be proposed to switch to the cycle-with-rc model,
16:03:38 <ttx> which is more suited to deliverables that are released only once per cycle."
16:03:40 <ttx> I don;t think we do that anymore
16:03:47 <ttx> do we?
16:03:51 <smcginnis> Did we decide we weren't going to?
16:04:11 <ttx> checking process
16:04:13 <smcginnis> I am fine not. I think it was confusing for some.'
16:04:33 <ttx> istr we no longer do it
16:04:35 <evrardjp> Interesting, I am definitely outdated, I thought this was still valid
16:04:58 <ttx> it's still valid
16:05:03 <ttx> sorry for the noise
16:05:03 <smcginnis> I don't remember changing that, but am fine either way.
16:05:24 <ttx> https://releases.openstack.org/reference/process.html#between-milestone-2-and-milestone-3
16:05:40 <ttx> so ignore me
16:05:54 <smcginnis> We can see how it goes this cycle and revisit that if needed.
16:05:59 <ttx> +1
16:06:04 <smcginnis> #topic Assign tasks for R-12 week
16:06:23 <smcginnis> That's in two weeks, but we are skipping next weeks meeting, so good to address it now.
16:06:35 <ttx> I'll run the governance check
16:06:44 <smcginnis> And I'll send the countdown.
16:06:45 <ttx> If only to check it's actually working as expected
16:06:51 <smcginnis> That was easy.
16:07:02 <smcginnis> #topic Stuck reviews
16:07:04 <ttx> Also I'm off on the V2 week :)
16:07:12 <smcginnis> Is that allowed?
16:07:29 <smcginnis> I thought you only took holidays on deadline weeks? :P
16:07:36 <diablo_rojo> LOL
16:07:49 <smcginnis> #link https://review.opendev.org/#/c/730570/
16:07:51 <ttx> Obviously
16:08:03 <smcginnis> Release of os-collect-config for victoria.
16:08:13 <smcginnis> But it's a cycle-trailing deliverable.
16:08:26 <smcginnis> I think it was actually meant for ussuri, but no response from ricolin.
16:08:39 <smcginnis> So if I keep saying ricolin, maybe ricolin will notice it and take a look.
16:08:49 <evrardjp> ricolin: ^
16:08:50 <hberaud> lol
16:08:58 <smcginnis> The cycle-trailing deadline is coming up so ricolin might want to take a look soon.
16:08:58 <diablo_rojo> Lol
16:08:59 <evrardjp> beetlejuice
16:09:10 <evrardjp> woops sorry
16:09:12 <hberaud> lol
16:09:13 <smcginnis> #link https://review.opendev.org/#/c/734955/
16:09:16 <diablo_rojo> ricolin ^
16:09:27 <ttx> I would just abandon it
16:09:28 <smcginnis> openstacksdk stable release for train.
16:09:36 <evrardjp> diablo_rojo: you mean to ping him on every single review? That also works to get him to release team.
16:09:36 <ttx> (the ricolin one)
16:09:47 <smcginnis> I can probably just abandon this one since it was just the stable releases I was trying to help get out.
16:09:59 <smcginnis> Just an issue that a backport was merged to train before it merged to ussuri.
16:10:07 <ttx> or we could say smcginnis 10 times and see... err.. wait
16:10:11 <smcginnis> I will check on that again and see if it has landed in the newer branch.
16:10:14 <smcginnis> :)
16:10:41 <smcginnis> If it's good, I will remove the -W, if there's still an issue, I will abandon for now.
16:10:57 <smcginnis> #link https://review.opendev.org/#/c/729420/
16:11:07 <smcginnis> ovb release
16:11:26 <evrardjp> I love the PTL approved +1
16:11:39 <smcginnis> I have not looked at this one yet. Anyone know anything about it. weshay_ruck maybe?
16:11:52 <smcginnis> It's from May.
16:12:30 <ttx> logs lost
16:12:35 <smcginnis> Left a comment on there. We'll see if there are any updates.
16:12:58 <ttx> I'd also just abandon it
16:12:58 <smcginnis> Running tox -e validate locally on that to see what's going on.
16:12:59 <evrardjp> if not, we should just abandon those, and if necessary, ppl will show up :)
16:13:17 <evrardjp> ttx: right
16:13:17 <ttx> sounds like an abandoned  draft
16:13:29 <smcginnis> Yeah, if no response we can just abandon.
16:13:44 <smcginnis> #link
16:13:49 <smcginnis> #link https://review.opendev.org/#/c/691442/
16:14:21 <smcginnis> This is kind of a WIP. I have local updates. I will abandon though, since it's changed quite a bit and we don't really need the history from this for that one.
16:14:43 <smcginnis> #link https://review.opendev.org/#/c/733644/
16:14:47 <smcginnis> Reno update.
16:15:18 <smcginnis> I have not seen an issue that this would be addressing, but it could be from something outside of our community.
16:15:30 <evrardjp> utf-8 everywhere?
16:16:05 <ttx> I would not mind but I don;t care enough to fix it if mtreinish does not finalize it
16:16:12 <smcginnis> I would have thought it would be fine. Maybe we can get an update from mtrienish.
16:16:30 <smcginnis> Unfortunately he's not in the channel, so we can't ping him repeatedly. :)
16:16:34 <evrardjp> well that is a risk to have ppl come back to ISO8859-1
16:16:36 <smcginnis> Comment on the patch though.
16:16:41 <diablo_rojo> Darn
16:16:47 <ttx> Yes we can, mtreinish
16:17:08 <smcginnis> We can shout into the void.
16:17:15 <ttx> it's just not very efficient
16:17:34 <smcginnis> #topic Ironic bugfix/* releases
16:17:43 <smcginnis> Recap for those not following along at home...
16:18:12 <smcginnis> Ironic wanted to have more flexibility with their releases and the ability to do multiple "stable" releases within a series.
16:18:27 <smcginnis> So we now support creation of bugfix/X.Y branching.
16:18:52 <smcginnis> That appears to be working fine. One small issue with proposing update constraints URL for these new branches, but that shouldn't be too hard to sort out.
16:19:01 <ttx> great news!
16:19:23 <evrardjp> yes that's interesting news
16:19:30 <smcginnis> The big issue I see yet is that our automation and our safetly checks would/will require a lot of refactoring to allow creating new releases off of these bugfix branches.
16:20:16 <smcginnis> So after looking at a few options, and considering these semi-stable releases aren't *really* official releases, I wonder if we should give a small group of Ironic cores the ability to tag bugfix releases themselves.
16:20:22 <smcginnis> Any thoughts?
16:20:40 <ttx> it's hard to allow one but not the other
16:21:11 <ttx> definitely can allow while we figure it out though
16:21:21 <smcginnis> Right. Part of that plan would be having trust in the people in that ACL knowing and following what they should be doing.
16:21:37 <ttx> but every time we said "you can keep tagging rights for foo but should use openstack/releases for bar... ended up with inconsistency
16:21:57 <ttx> It's not a question of trust, everybody is human
16:22:07 <smcginnis> True. It is a little risky.
16:22:11 <ttx> and errors are painful to spot
16:22:13 <diablo_rojo> This sounds.. risky.
16:22:21 <hberaud> I agree
16:22:26 <smcginnis> I just don't think I have the bandwidth to rewrite all our validations.
16:22:30 <ttx> The risk is limited, but:
16:22:31 <diablo_rojo> Hence the tooling we have in place to help.
16:22:52 <ttx> - in almost all projects that had ACLs that allowed tagging, we got discrepancies
16:23:04 <ttx> - we had to create specific tooling to ensure cohesion (acl manager)
16:23:35 <ttx> so I would be very surprised if over time you would not have people tagging stable/x.y.z by accident
16:23:55 <ttx> since direct taggingis not tested not reviewed
16:24:03 <smcginnis> Another option is to create a release machanism separate from our normal deliverables to handle these differently.
16:24:30 <evrardjp> I agree with the risk evaluation of ttx, we had wrong acls in osa before, and that happened.
16:24:31 <ttx> I think we can work it out while we get the validation aligned
16:24:53 <ttx> like they can ask for those and we would create them manually
16:25:07 <ttx> reduces human error but does not eliminate it completely
16:25:20 <ttx> (*we can still get it wrong)
16:25:46 <smcginnis> That's probably better. Us doing it manually is maybe slightly less risky than delegating that to someone else.
16:26:11 <fungi> not tested, not reviewed, and effectively irreversible
16:26:11 <ttx> looking at tag history for some older projects will show you all the ways you can get this wrong manually :)
16:26:24 <smcginnis> We still need to figure out how those requests will happen.
16:26:41 <smcginnis> We can't add a release in the middle of the list as it is today.
16:27:00 <smcginnis> Since normally we require new releases are always the last entry, since that makes sense in normal cases.
16:27:20 <ttx> they can ask here on the channel
16:27:37 <ttx> and we would not have them in the releases repo at all
16:28:03 <smcginnis> Which is probably good, since we don't really want these listed on releases.o.o either.
16:28:21 <diablo_rojo> Yeah that makes sense.
16:29:46 <smcginnis> So ironic team just requests here, one of us takes the action to manually do the tagging, we carefully check that we are tagging the right commit and using an appropriate tag, then we manually push it up.
16:29:56 <smcginnis> ttx: Do all release-managers have rights for that?
16:30:13 <ttx> checking
16:30:40 <ttx> https://review.opendev.org/#/admin/groups/11,members
16:32:00 <fungi> yeah, it's defined globally in gerrit's all-projects acl
16:32:08 <fungi> which is something we likely need to revisit at some point
16:32:12 <smcginnis> OK, great.
16:32:21 <smcginnis> So at least for now, we should be set to do this.
16:32:25 <ttx> so for now that works :)
16:32:30 <fungi> might be better to have an openstack parent acl all official openstack deliverable repos inherit from
16:32:37 <smcginnis> We should still be cautious and double check what we're doing.
16:32:45 <fungi> yep
16:32:49 <ttx> yeah probably, but not urgent to fix
16:33:05 <fungi> at the moment you can push commits directly into any project in opendev, so... please do be careful
16:33:16 <ttx> maybe we should wait until there is two of us around to agree, minutemen like
16:33:18 <smcginnis> }:)
16:33:37 <ttx> that would not significantly reduce processing time compared to "usual releases"
16:34:03 <ttx> like "hey smcginnis, I'm about to run this command in response to that request"
16:34:09 <ttx> please confirm
16:34:15 <fungi> er, actually you can just push signed tags, not other arbitrary objects, but still yes please take care
16:34:40 <smcginnis> ttx: That seems like a good practice for us to follow.
16:34:57 <ttx> ok let's document that in the etherpad
16:35:45 <smcginnis> dtantsur: Doesn't need immediate attention, but see log above for info on doing releases from those bugfix/ branches.
16:35:55 <smcginnis> TheJulia: too ^
16:36:18 * dtantsur will check a bit later, in a hurry now
16:36:29 <ttx> so summary
16:36:31 <smcginnis> Summary on line 166 of https://etherpad.opendev.org/p/victoria-relmgt-tracking too
16:36:38 <smcginnis> ttx: Thanks for getting that written down.
16:36:52 <ttx> #info Ironic bugfix releases: will take time to get validation scripts and the releases repo to accept those
16:36:58 <ttx> #info In the mean time ironic team should just ask for those in the #openstack-release channel
16:37:08 <ttx> #info request will be processed by a team of two release managers confirming command to be sent
16:37:55 <dtantsur> honestly, I hope to nearly never release from bugfix branches :) they're our precaution mostly
16:38:02 <dtantsur> but thanks for the update!
16:38:03 <smcginnis> ++
16:38:25 <smcginnis> All the more reason this is probably better than us redoing a lot of the tooling to support it. That's great.
16:38:53 <smcginnis> #topic Open Discussion
16:38:58 <smcginnis> Anything else?
16:39:09 <ttx> nope
16:39:11 <evrardjp> nothing on my side
16:39:13 <hberaud> nope
16:39:33 <smcginnis> Excellent. We can wrap up then. Thanks everyone!
16:39:47 <smcginnis> #endmeeting