17:00:18 <hberaud> #startmeeting releaseteam
17:00:19 <openstack> Meeting started Thu Jan  7 17:00:18 2021 UTC and is due to finish in 60 minutes.  The chair is hberaud. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:21 <hberaud> #link https://etherpad.opendev.org/p/wallaby-relmgt-tracking Agenda
17:00:21 <ttx> o/
17:00:22 <openstack> The meeting name has been set to 'releaseteam'
17:00:24 <hberaud> Ping list: ttx armstrong elod
17:00:27 <armstrong> o/
17:00:41 <hberaud> We're way down on line 194 now.
17:00:52 <hberaud> Will just wait a couple minutes for folks.
17:01:36 <openstackgerrit> Merged openstack/releases master: Release kolla deliverables for Ussuri  https://review.opendev.org/c/openstack/releases/+/769324
17:01:44 <openstackgerrit> Merged openstack/releases master: Release kolla deliverables for Train  https://review.opendev.org/c/openstack/releases/+/769325
17:01:52 <elod> o/
17:01:58 <diablo_rojo> o/
17:02:16 <hberaud> Let's just start by saying welcome back and happy new year to everyone, I hope you enjoyed your end of the year parties
17:02:32 <ttx> socially-distanced of course
17:02:39 <hberaud> lol
17:02:43 <elod> :)
17:02:47 <fungi> virtuparty
17:03:53 <diablo_rojo> I am so over virtual anything lol
17:04:09 <hberaud> So let's go!
17:04:11 <hberaud> #topic Assign R-13 tasks
17:04:34 <hberaud> So next week will be the Victoria Cycle-Trailing Release Deadline
17:04:56 <hberaud> All projects following the cycle-trailing release model must release their Victoria deliverables by 14 January, 2021.
17:05:00 * ttx checks current status
17:05:11 <hberaud> I think it could be worth to send a friendly reminder
17:05:20 <openstackgerrit> Dmitry Tantsur proposed openstack/releases master: Release ironic-python-agent-builder 2.4.0  https://review.opendev.org/c/openstack/releases/+/769802
17:05:30 <hberaud> Any volunteer?
17:05:47 <ttx> a bunch have RCs already
17:06:19 <ttx> I think it's good if it comes from the release manager. More intimidating and all
17:06:24 <hberaud> I didn't verified but I agree it could be worth to check before
17:06:37 <hberaud> You're right
17:06:50 <hberaud> I'll check and send!
17:07:48 <hberaud> the second thing was "Ahead of MembershipFreeze, run governance_consistency.py" but I see that ttx & armstrong are already on it, thanks!
17:08:06 <ttx> armstrong: we could sync on Monday about that?
17:08:16 <ttx> hmm wait, my schedule is a bit busy
17:08:18 <armstrong> sounds good to me
17:08:37 <ttx> early in the day for you would be good (early afternoon for me)
17:08:38 <armstrong> @ttx anytime next week looks good to me
17:08:58 <ttx> Monday 14UTC?
17:09:08 <armstrong> @ttx Yes
17:09:19 <ttx> ok, meet here if you need help :)
17:09:30 <armstrong> ok
17:09:57 <hberaud> Then I think we can move the next topic
17:10:02 <hberaud> *to
17:10:06 <hberaud> #topic EM for branchless projects
17:10:14 <hberaud> Do we want to continue with EM for branchless projects?
17:10:19 <hberaud> elod voluntary ignored them, and some of us think that this mixing concept that are separated
17:10:32 <ttx> I think gmann made a good rationale about why we should accept them
17:10:59 <elod> actually not just voluntarily but the validator failed if I remember correctly :)
17:11:09 <ttx> I don't have enough brain cells right now to question the status quo
17:11:24 <hberaud> elod: Ah sorry I misunderstood
17:11:44 <hberaud> I'm not against that, it was already did during previous cycle (c.f queens)
17:11:46 <ttx> one issue is that the patch chain looks weird
17:11:53 <ttx> (Indirect ancestor and all)
17:12:01 <hberaud> ah
17:12:12 <ttx> so wondering if approving it will not bork all the others
17:12:34 <hberaud> maybe
17:12:44 <ttx> fungi: what does indirect ancestor mean?
17:12:53 <hberaud> another issue is that some of these patch also face the doc issue
17:13:22 <hberaud> so they need to be rebased on the top of the related patch here => https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open)
17:13:46 <hberaud> but we will speak about that more deeply in the next topics
17:13:55 <ttx> ah, a new patchset was posted for it, and now all the patches that were posted on top of it are potentially a problem
17:14:09 <ttx> they will probably need to be rebased
17:14:21 <hberaud> ok
17:14:23 <elod> fwiw, if this was done for queens, then it should be approved to stein (and rocky?) as well (of course if the ancestor problem doesn't make any breakage)
17:14:27 <hberaud> gmann: FYI ^
17:14:45 <hberaud> elod: yes make sense
17:15:15 <fungi> sorry, which change?
17:15:38 <fungi> is "indirect ancestor" something gerrit is displaying somewhere?
17:15:41 <ttx> fungi: I think I got it. was https://review.opendev.org/c/openstack/releases/+/768566
17:15:52 <hberaud> fungi: https://review.opendev.org/q/topic:%22tempest-plugin-stein-em%22+(status:open%20OR%20status:merged)
17:16:01 <ttx> it's the inverse of "Not current"
17:16:12 <fungi> ahh, neat
17:16:21 <fungi> i don't think i've seen that before
17:16:22 <ttx> Like Change 2 is stacked on top of patchset 1 of Change 1
17:16:31 <ttx> but then you post patchset 2 of Change 1
17:16:52 <ttx> Then change 1 will show as "not current" in change 2
17:17:07 <ttx> and change 2 will be "indirect ancestor" of change 1
17:17:15 <fungi> yep, makes sense, i agree
17:17:17 <ttx> iiuc
17:17:59 <ttx> shoudl be safe, but might force rebases for all the patch 2s
17:18:49 <fungi> gerrit will require them to be rebased anyway, because they have ancestor commits which will never appear in the target branch
17:18:55 <ttx> With the current state of my brain cells I'll trust gmann and just follow his request
17:19:13 <ttx> just posted +2
17:19:37 <hberaud> So if I summarize, we want to continue with these changes, and we should also update some of our machinery =>  https://review.opendev.org/c/openstack/releases/+/768566 , is it make sense for everyone?
17:20:10 <ttx> yeah, avoids validation fail
17:20:13 <gmann> fungi: ttx hberaud i can rebase once it is merged, at least that would not lose hberaud +2 on plugins releases
17:20:31 <fungi> gmann: yep, that should work
17:20:31 <ttx> ok, those need the doc changes before we can process them anyway
17:20:54 <gmann> ttx: which  one?
17:21:07 <hberaud> ttx: before +2 ensure that repo aren't part of https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open)
17:21:29 <ttx> most of the *-tempest-plugin fall into http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html
17:21:30 <gmann> hberaud: I will reply to your comment on 768566, was busy in other things
17:21:35 <hberaud> ok
17:21:53 <hberaud> ttx: yes
17:21:56 <gmann> i see, got it
17:22:06 <hberaud> and patches are only on master for now
17:23:04 <hberaud> We will risk to have to reenqueue lot of jobs
17:23:43 <hberaud> it is problematic...
17:24:45 <hberaud> gmann: Do you think we could deactivate some job on these branches before moving to EOL?
17:24:47 <elod> just one question: if we allow EM tagging for branchless repos, is there any other repo that we have to be careful?
17:25:10 <elod> I mean, e.g. not *tempest-plugin, but other branchless repository
17:25:21 <elod> if there exists such
17:25:21 <hberaud> gmann: docs and releasenotes job AFAIK
17:25:49 <hberaud> gmann: it could solve our issue easily
17:26:19 <hberaud> and it could be done by using a script
17:26:46 <fungi> what is em tagging for branchless repos?
17:26:48 <gmann> hberaud: we had same kind of situation in Ocata time when due to stestr we could not run the unit/integration tests there and then it end up going to EOL
17:27:28 <gmann> fungi: for tempest and tempest plugins, it will be current master has when branch went to EM means this is last compatible version can work against EM branches code
17:27:30 <elod> fungi: allowing to tag with *-em, regarding this patch: https://review.opendev.org/c/openstack/releases/+/768566
17:27:30 <hberaud> else we could simply assume to ignore all the related failing job...
17:28:26 <hberaud> (doc & releasenotes job fails only)
17:28:34 <gmann> hberaud: only issue is we would be backport the doc or releasenotes untested and they are EM so not good.
17:29:24 <gmann> but at same time we can argue these might be less such changes so as long as we test unit/func/integration we can assume these EM are tested
17:30:13 <fungi> gmann: elod: what is the benefit of adding the *-em tags to tempest?
17:30:17 <hberaud> and keep them non-EM?
17:30:21 <hberaud> gmann: ^
17:30:31 <fungi> does tempest extended maintenance differ from when tempest drops support?
17:30:36 <gmann> hberaud: you mean 'unmaintained' ?
17:30:58 <gmann> fungi: it will help to find the last compatible version of Tempest for that stable branch
17:30:59 <hberaud> no I mean not moving to EM
17:31:17 <fungi> gmann: "extended maintenance" seems like a very confusing term in that case
17:31:33 <fungi> tempest is ceasing maintenance for that series, not extending it
17:31:38 <gmann> fungi: i tried to explain these versioning thing for Tempest and plugins here https://docs.openstack.org/tempest/latest/tempest_and_plugins_compatible_version_policy.html
17:32:27 <gmann> fungi: yeah that is faire point, i used -em along with new version number also so that they can be easily understandable with our stable branch -em tag
17:32:50 <fungi> gmann: yeah, the support policy makes sense, but calling what tempest is doing "extended maintenance" doesn't really match what it describes
17:33:30 <hberaud> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#testing
17:33:39 <gmann> hberaud: I think i lost in your comment, 'keep them non-EM?' 'them' you mean current stable branches or EM branches ?
17:33:44 <fungi> anyway, i don't really have a strong opinion on it, i was simply confused because it initially sounded like you were saying tempest was adding an extended maintenance phase
17:34:27 <gmann> fungi: or we can say *-eol which will be right thing for Tempest and plugins
17:34:46 <ttx> AIUI it does not make sense in itself, but is useful to trick the tests to run with the right code
17:35:09 <hberaud> gmann: np I think I misunderstood you when here "but at same time we can argue these might be less such changes so as long as we test unit/func/integration we can assume these EM are tested"
17:35:26 <fungi> -eol or -final or -end or something would make more sense, just from a confused user perspective
17:35:30 <gmann> hberaud: ohk, i mean it for already EM branches.
17:35:47 <elod> I like -final :)
17:36:04 <elod> however, usually final things won't be finals ;)
17:36:20 <hberaud> eol could be an option
17:36:37 <fungi> -final is usually followed by -really-final and then -no-we-mean-it-this-time-final
17:36:46 <hberaud> :)
17:36:47 <elod> that's true :D
17:36:51 <gmann> one more tricky thing  here is other later version of Tempest might work but this tag is last guaranteed working one
17:37:20 <fungi> it's the last one you tested with it, right
17:37:31 <gmann> yeah
17:37:56 <gmann> -last-compatible ? but it is too long
17:38:13 <fungi> or simply -last
17:38:21 <hberaud> +1 -last
17:38:51 <gmann> yeah, that's better
17:38:51 <elod> -last sounds better to me, too
17:38:56 <fungi> anyway, this is devolving into bikeshedding, so i'm violating my personal policy of bikeshedding on names for things
17:39:16 <elod> true, again :)
17:39:35 <gmann> cool, I will update it with rebase once 768566 is merged for easy update
17:40:02 <gmann> hberaud: can you check, i replied to your comment - https://review.opendev.org/c/openstack/releases/+/768566
17:41:07 <hberaud> What do we do if a pip issue appear with these patches and doc/reno, do we assume to ignore them?
17:41:21 * hberaud read
17:42:59 <elod> one more thing: if we are not using the -em tag for this, then we don't need the validator modification patch either, am I right?
17:43:14 <hberaud> gmann: ok I'm fine with that, thanks
17:44:02 <hberaud> elod: I think that yes
17:44:37 <openstackgerrit> Thierry Carrez proposed openstack/releases master: molteniron does not need releases  https://review.opendev.org/c/openstack/releases/+/769597
17:45:23 <hberaud> IMO this patch isn't needed anymore if we use -last
17:46:04 <elod> as 768566 is specially for -em tag
17:46:18 <hberaud> Yes
17:46:43 <hberaud> OK, we can get those out after the meeting then. We've other topics to discuss
17:46:48 <ttx> indeed
17:47:04 <hberaud> #topic moltiron's abandon, what's the exact process to follow?
17:47:04 <elod> hberaud: ok, thanks \o/
17:47:05 <ttx> the wrong reno should be fixed now?
17:47:15 <ttx> OK, I just did work on that
17:47:25 <hberaud> Yes thanks
17:47:29 <gmann> hberaud: thanks
17:47:33 <ttx> So the proper way to express that a deliverable is actually not using releases is...
17:47:46 <ttx> a release-management: none key in the governance projects.yaml file
17:47:58 <hberaud> ok
17:48:02 <ttx> I just proposed it in replacement of this patch
17:48:09 <ttx> That's the occasion to explain one thing
17:48:20 <hberaud> awesome thanks (FYI iurygregory)
17:48:20 <ttx> which is not well documented (I'll fix it)
17:48:22 <hberaud> ^
17:48:32 <hberaud> ack
17:48:34 <ttx> You can read the commit message on https://review.opendev.org/c/openstack/governance/+/613268
17:48:39 <ttx> but basically...
17:48:40 <iurygregory> hberaud, np =)
17:48:57 <ttx> The TC gives us a list of official openstack deliverables
17:49:00 <gmann> hberaud: elod ah yeah, let's discuss 768566  after meeting
17:49:17 <ttx> by default, the Release management team is tasked with doing release management for all of them
17:49:25 <ttx> But some are actually not released
17:49:31 <ttx> and some are released but not by us
17:49:35 <hberaud> Good to know
17:49:40 <gmann> ttx: i think there was some script to validate those releade model or it was just manual finding if any mismatch?
17:49:41 <ttx> those are exceptions that are documented in governance
17:49:53 <ttx> using the release-management: none and release-management: external keys
17:50:00 <gmann> i remember you corrected many in past
17:50:04 <ttx> indeed. We plan to run that script next week
17:50:13 <gmann> k
17:50:13 <ttx> as part of the membershipfreeze
17:50:27 <ttx> Here since the deliverable was never released it's pretty easy
17:50:46 <ttx> just set the key in governance and remove the deliverable file that should never have been created
17:51:05 <ttx> But that shows that those keys are not well documented
17:51:23 <ttx> I'll probably post something to the project-team-guide
17:51:32 <gmann> +1
17:51:44 <hberaud> ack thank
17:51:48 <ttx> that is all!
17:52:12 <hberaud> #topic Wrong reno with (22.0.0.0rc1 is a victoria tag marked as unreleased)
17:52:18 <hberaud> I missed this topic previously
17:52:27 <hberaud> This is just a heads up
17:52:42 <hberaud> the problem have been fixed by https://review.opendev.org/c/openstack/project-config/+/769128
17:52:54 <hberaud> #topic Remove misleading error message on our jobs
17:53:05 <hberaud> Another heads up
17:53:36 <hberaud> ttx proposed some changes in our tools to avoid misleading logs
17:53:55 <hberaud> https://review.opendev.org/c/openstack/project-config/+/769353, so please keep  an eye open in the very unlikely case it creates a regression.
17:54:20 <hberaud> #topic releasenotes/docs jobs issues related to pip's latest resolver,
17:54:33 <hberaud> And the last but not the least...
17:55:24 <hberaud> As you surely seen previously during our discussion and on the ML we faced some issues with docs/release c.f  http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019611.html
17:55:55 <hberaud> I asked you to hold our validations for a while
17:56:32 <fungi> it mostly stems from bugs in projects where they're listing incompatible versions of linters in their test-requirements.txt files
17:56:34 <hberaud> now all identified repos received fixes, https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open+OR+status:merged)
17:57:18 <hberaud> However stable haven't been addressed yet
17:57:29 <hberaud> *branches
17:59:09 <hberaud> I think we can restart patch valiation but we should take care of the list of projects to see if they are sensitive projects
18:00:00 <hberaud> else we will have to reenqueue lot of failed jobs.
18:00:44 <hberaud> we reached the end of the meeting time slot
18:01:04 <hberaud> #topic open discussion
18:01:14 <hberaud> Anything else?
18:01:21 <ttx> nothing from here
18:01:35 <elod> neither from me
18:01:36 <armstrong> nothing from me
18:01:54 <hberaud> Let's discuss about topics that need more time outside of the meeting slot
18:02:12 <hberaud> OK, thanks everyone. Let's wrap up.
18:02:23 <hberaud> #endmeeting