Friday, 2022-11-18

*** amoralej|off is now known as amoralej07:31
opendevreviewMerged openstack/releases master: [manila-tempest-plugin] Tag ussuri-last & victoria-last
opendevreviewMerged openstack/releases master: [neutron-tempest-plugin] Tag ussuri-last & victoria-last
opendevreviewMerged openstack/releases master: [octavia-tempest-plugin] Tag ussuri-last & victoria-last
opendevreviewMerged openstack/releases master: [trove-tempest-plugin] Tag ussuri-last & victoria-last
opendevreviewMerged openstack/releases master: [neutron] Transition Queens, Rocky & Stein to EOL
*** dviroel|out is now known as dviroel11:21
*** dviroel_ is now known as dviroel12:57
*** amoralej is now known as amoralej|lunch13:11
ttxelodilles: hberaud: meeting?14:01
hberaud#startmeeting releaseteam14:01
opendevmeetMeeting started Fri Nov 18 14:01:53 2022 UTC and is due to finish in 60 minutes.  The chair is hberaud. Information about MeetBot at
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:01
opendevmeetThe meeting name has been set to 'releaseteam'14:01
hberaudPing list: hberaud armstrong elodilles14:02
elodilleshi ralonsoh 14:02
hberaudWe're way down on line 100 now14:02
hberaud#topic Review task completion14:03
hberaudSo the first one was to propose patch for trailing projects
elodillesas I see we got -1s for all but one patch. at least we know that teams are planning to do the release there :)14:04
hberaudwe won't forgot them14:05
elodillesthough it would be good not to leave the releses to the deadline14:05
hberaudI'll add a reminder to the next weeks14:06
hberaudor at least to R-1514:06
elodilleshberaud: ++, thanks!14:06
hberaudok, the next task was to propose autorelease for the CWI projects
hberaudlet's check them14:08
hberaudelodilles: so you propose to force those without response?14:09
elodillesi've +2'd those that i think can be processed14:09
hberaudIIRC during the previous series we prefered to abandon those without response14:09
hberaudforcing them WFM, ttx any opinion?14:09
ttxyeah, ok to force those without answer14:10
hberaudI'll force them after the meeting14:11
hberaudso, the next task was "    Catch if there are acl issues in newly created repositories"14:11
hberaudand elodilles said  no acl issues were discovered with latest state of project-config + governance repositories14:12
hberaudso it seems good14:12
elodillesyepp, empty result, looked good14:12
hberaudand the last task was "Remind the Foundation that the next Release Name selection process should be started. Release name should be available by R-11"14:13
hberaudttx: any update?14:13
ttxyes, I started the process internally14:13
hberaudso things are ok14:13
ttxwe should have B by deadline, and C a bit later14:14
hberaudso we won't have to manage this point during B?14:14
hberaud(if C come just after B)14:14
ttxwe should still have the action point14:15
elodillesthen we just need to keep in mind that we'll have a C already :)14:15
ttxit's just that we migth start the process internally earlier14:15
hberaud(I prefer to ask just to be sure to understand correctly)14:16
elodillesthe sooner it is decided the better for us, for our processes :]14:16
hberaudanything else concerning the tasks, before I move to the next topic?14:17
*** amoralej|lunch is now known as amoralej14:18
hberaud#topic Assign next week tasks14:18
hberaudso next week is a free week14:18
hberaudso let's assign R-16 now14:18
ttxalso no task there14:18
hberaudelodilles: do you want to handle this one? Approve 'Set Wallaby status to Extended Maintenance' patch14:19
ttxI think we do that during the meeting14:19
hberaudwe could approve it early and let you push the final button14:19
elodillesyepp, i think we are almost there, by the way14:19
hberaudttx: ah yes indded14:20
hberaudmy bad14:20
hberaudso... moving to the next topic14:20
opendevreviewMerged openstack/releases master: Release os-win for Antelope-1 milestone
hberaud#topic Review countdown email14:20
hberaudI'm sorry I missed to fulfil the template14:21
elodillesonly Puppet Openstack and OpenStack Ansible wallaby-em patches are missing a +1, but final releases are out for them,14:21
elodillesso it should be just formality14:21
hberaudthanks to the person who wrote the weekly email14:21
elodilleshberaud: no hurry then, I'll be available after the meeting for the review if you want14:22
hberaudI'll update the template14:22
hberaudafter the meeting14:22
hberaudthanks elodilles 14:22
ttxI'll do taht async now14:22
ttxwhile you chair the rest of the meeting :)14:23
opendevreviewMerged openstack/releases master: Release python-venusclient for Antelope-1 milestone
opendevreviewMerged openstack/releases master: Release cliff for Antelope-1 milestone
opendevreviewMerged openstack/releases master: Release tosca-parser for Antelope-1 milestone
hberaudttx: ack, see you later14:23
ttxlooks like the goal link does not work14:26
elodillesyepp, not even with 2023.1 if i'm not mistaken14:26
hberaudsae thing for zed14:26
hberaudand yoga14:26
ttxhmm maybe insteda14:27
hberaudnot sure this error is related to the naming of the series14:27
ttxno, it's that they kind of abandoned per-cycle goals I think14:27
elodilles'active' goals only14:27
ttxemail lgtm14:28
fungiyes, goals are no longer tied to specific release cycles14:28
fungithey just start and end whenever is convenient now14:28
elodillesLGTM, too14:28
hberaudso I'll send the email14:28
hberaudfungi: thanks for your confirmation14:29
elodillesthanks o/14:29
fungiin my opinion it was a bit of a chesterton's fence situation, but i gave up arguing14:30
hberaud#topic Reminder skipping meeting next week14:30
ttxdone :)14:31
hberaud#topic Open Discussion14:31
lajoskatonaHi, I added a topic there14:31
hberaudSo our next chair will be ttx at R-1614:31
hberaudlajoskatona: the floor is yours14:32
lajoskatonaSo the title should be: future (past?) of old branches of tap-as-a-service14:32
lajoskatonaSince Yoga taas is back to Neutron stadium, but beofre that it has no yaml files under releases repo as it was under x/ namespace14:33
lajoskatonaand so the old branches like Ocata, Pike, Queens can only deleted manually if I understand well14:33
lajoskatonaanother perspective is that some of the zuul cfg errors are related to these branches14:33
lajoskatonaand I would like to ask your help here to delete those branches14:34
hberaudtaas have ocata, pike, and queens branches even if it wasn't an openstack deliverables at this time?14:34
lajoskatonaperhaps the problem is more general as we have some flapping projects (even in networking can happen)14:34
hberaudI understood correctly?14:34
elodilleshberaud: that could be a side effect of the migration from x/ to openstack/14:34
ttxiirc we can create branches but not remove them14:35
ttxfungi: do I remember correctly?14:35
ttxwe = release team14:35
elodillesttx: actually, we have the right to delete them14:35
ttxah, ok14:35
elodillesi've deleted some in the past14:35
fungiwe can do both14:35
fungigerrit 3.3 added an acl permission for branch deletion14:36
elodillesunfortunately we have more lingering old-old-stable branches...14:36
elodillessome have the same situation as tap-as-a-service14:36
fungiand we refactored the openstack acls to have a central inherited acl which grants branch deletion (and other similar permissions) to the release managers group14:36
fungiand there's a rest api method for branch deletion, so it's accessible to scripts/automation14:37
hberaudgood to know14:37
fungiand elodilles wrote a script to semi-automate it14:38
elodillesfungi: that is for the 'general' case14:38
elodillesfungi: when the EOL'ing is done in the usual manner :)14:38
hberaudIn this case I think we have to do it manually14:39
fungibut yeah, what's not there (yet) is fully automatic deletion of branches when changes merge to remove them14:39
hberaudmaybe through gerrit14:39
elodillesfungi: probably a similar can be done for the other cases as well, but there are different cases, and there comes the question where to administer them14:39
lajoskatonaby usual you men changing the yaml under releases?14:39
hberaudlajoskatona: yeah we propose automated releases for the latest series14:40
fungiit sounds like the challenge is that some projects have older branches not tracked in the deliverables files, from before they were officially part of openstack14:41
lajoskatonahberaud: thanks14:41
elodillesfungi: yes, for example branch was created, but no track in relmgmt's yamls14:41
fungiin which case the branch could still be deleted through the rest api or webui by a release manager, but it would be a separate act from the eol process14:42
elodillesfungi: or the other case is when somehow branches were recreated accidentally (during -> migration)14:42
fungialso cases like ironic's where extra semi-stable branches were created manually by the project maintainers14:43
elodillesfungi: yes, and probably needs some EOL(-like?) tagging as well14:43
fungiand some projects have stale feature development branches too which were left around after they merged stuff back into master14:43
elodillesfungi: yepp, ironic's branches are also one of the non-usual cases (for now :))14:44
fungiand cinder's driverfixes branches14:44
elodillesi guess feature branches are out of relmgmt team's responsibility?14:44
hberaudwe don't know the state of the development on these branches14:45
fungihowever, only openstack release managers (and gerrit admins) have permission to delete branches currently14:45
fungiso unless that's changed, there's nobody else able to clean them up14:46
elodillesand create the 'eol' tag14:46
elodilles(i guess those are needed, except maybe for the feature branches)14:47
hberaudelodilles: do you propose to create eol tag for those TAAS old branches?14:47
fungii guess the question is whether (a) the release managers are okay granting branch deletion rights to teams/ptls/tc, (b) the release managers/gerrit admins are willing to do ad hoc branch cleanup on request, or (c) better to just leave those branches to rot14:47
hberaud(a) could be dangerous on the long term14:48
fungiand (b) could lead to taking on more work, and (c) can potentially cause problems for stale job configuraiton and such14:49
fungiso there's no clear win, it's a tough decision14:50
fungi(c) is essentially status quo at the moment14:50
elodillesin my opinion, if we choose (b), then it should be handled outside of deliverables/ at least...14:50
hberaudfrom my POV (b) seems feasible, and the workload shouldn't be horrible14:51
fungifrom the opendev sysadmin perspective, we've generally been willing to perform the occasional manual operation on request, but for anything which is likely to come up more than once we prefer to delegate permission to the project (in openstack's case, the release managers(14:52
fungifor opendev, the real time sink is making sure we've gotten instructions/confirmation from the right people with authority to okay a destructive request like that14:53
hberaudmake sense14:54
fungiso the less often we have to do that research and can rely on an acl, the more time we have to maintain and improve our services14:54
whoami-rajatelodilles, hey, I've left a comment on this release patch describing a past concern:
hberaudSo, for lajoskatona's request I propose that we (the relgmt team), use our rights to remove these branches, is it work for you elodilles and ttx?14:57
elodilleshberaud lajoskatona : do we need to tag the branches before the deletion?14:57
hberaudI don't think14:57
lajoskatonahmmm, good question14:58
lajoskatonaI have to chekc if we have any tag on them now14:58
lajoskatonabut ,thanks for the help and discussion14:59
elodilleswhoami-rajat: answered on the patch :)14:59
hberaudlajoskatona: then we let's you check that point, and when let's you back to us when you have some update, then we will remove and if needed tag those branches14:59
hberauds/and when/and then/15:00
funginote that the changes which merged to that branch won't be lost, but merge commits might get garbage-collected if the final branch state doesn't have a tag15:00
lajoskatonahberaud:  ack15:00
elodillesyepp, hence we have the *-eol tags in general15:00
fungialso all open changes have to be abandoned before the branch can be deleted15:00
hberaudlajoskatona: ^15:01
lajoskatonaack, I will double-check check15:02
hberaudwell, we have exceeded our time, anything else before I close the meeting?15:03
hberaudlajoskatona: thanks15:03
hberaudOK, thanks everyone. Let's wrap up.15:04
opendevmeetMeeting ended Fri Nov 18 15:04:05 2022 UTC.  Information about MeetBot at . (v 0.1.4)15:04
opendevmeetMinutes (text):
elodillesthanks hberaud 15:04
ttxthanks hberaud !15:04
elodillesthanks lajoskatona for bringing this topic up15:06
whoami-rajatelodilles, replied again, I would prefer major bump for cinder project releases thanks15:06
elodillesi'll try to think about the (b) solution if i have time. it would be good if we could handle things like this without any / less manual steps15:07
*** dviroel is now known as dviroel|lunch15:07
elodilleshberaud ttx : i guess it is possible for the teams to bump MAJOR version between cycles for 'cycle-with-intermediary' projects if they want, just to make more room for stable version bumps, right?15:09
hberaudI think if the landed changes doesn't reflect that then we should avoid that15:10
hberaudI think it's doable but not really desirable15:11
elodilleshberaud: hmmm. i thought we had similar cases in the past, but was probably wrong15:11
fungiper my comment, i'm curious when the need to do feature releases on stable branches has actually come up15:11
elodilleswhoami-rajat: it seems i was wrong ^^^15:11
opendevreviewMerged openstack/releases master: Release python-manilaclient for Antelope-1 milestone
hberaudyeah that could leave room to backport features on stable branches, which is against our policy15:12
elodillesfungi: that's a tricky thing, as feature releases should not happen, but there are some cases where config changes or some 'bigger' but still 'stable-compatible' changes are part of the release, where the team usually wants to signal that 'this release has bigger impact than just a normal bugfix release'15:13
elodillesfungi: so we have time-to-time such stable releases15:13
fungiinteresting. also i guess not all projects follow the stable branch policy15:14
fungiso may actually legitimately merge even backward-incompatible changes on stable branches15:14
whoami-rajatdoesn't feature changes require major version bump? also we had cases in past where we change requirements in stable branches and do a patch bump which doesn't seem right15:14
fungiwhoami-rajat: adding features or changing external dependencies (for projects not using our global stable constraints) would imply a "Y" version bump, which may be expected behavior for projects not following stable branch policy15:16
whoami-rajatbut in any case, I don't have much issues if we would like to continue using minor bumps for cycle with intermediary projects15:16
fungi(and if you want to be able to have "Y" version increases on the last stable branch, you need an "X" version increase as the first new tag on master after the branch)15:17
funginot clear on which tag you're referring to when you say major or minor (whether you're talking about potential future tags on stable/zed or the new tag on master)15:18
elodillesyes, this came up at the very first release in the antelope cycle now for python-cinderclient ( )15:20
fungifor projects following stable branch policy, there should in theory only be "Z" version increases needed on stable branches, which is why only a "Y" version increase is strictly required for the first master branch release after the stable branch was initially released, but if you're including a breaking change to the api or some similar backward-incompatibility in that tag on master15:20
fungithen an "X" version increase could be warranted for those reasons15:20
whoami-rajatfungi, I'm referring to this case
fungielodilles: yes, that's the change i left comments on15:22
fungiwell, left a comment on15:22
elodillesfungi: in theory yes, but as I said, there are sometimes backports that however follow stable policy, still requires some attention or possible actions for deployers, so this is quite commonly used even for projects who follows stable policy15:23
elodillesthough i understand, that *in theory*, this could not happen :)15:25
fungiyeah, reading the discussion on 829590 it looks like the dilemma was that the team merged changes which were not compatible with the stable branch policy, but did not leave room for a minor version increase to signal that15:25
elodilleswell, actually, only bugfix backport is mentioned15:28
whoami-rajatwe released xena with a minor version bump and when the os-brick was backported to stable branches, we couldn't do a minor version bump for that stable release15:28
whoami-rajatto avoid similar situation i asked for a major version bump in the antelope cinderclient patch15:28
whoami-rajats/os-brick/os-brick change15:29
*** dviroel|lunch is now known as dviroel16:16
*** marios is now known as marios|out16:35
*** amoralej is now known as amoralej|off17:36
fungiwhich makes sense, but we should be consistent. either we're telling users that they should expect only reasonably backward-compatible changes on stable branches, or we aren't (in which case we should do major version bumps at every cycle boundary because we don't know whether it will be necessary)17:38
fungiit seems very unlikely that cinder's deliverables are the only ones in that situation17:38
*** dviroel is now known as dviroel|out20:13
opendevreviewMichael Johnson proposed openstack/releases master: Release designate-tempest-plugin 0.15.0
opendevreviewMichael Johnson proposed openstack/releases master: Release octavia-tempest-plugin 2.1.0

Generated by 2.17.3 by Marius Gedminas - find it at!