14:01:53 <hberaud> #startmeeting releaseteam
14:01:53 <opendevmeet> Meeting 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 http://wiki.debian.org/MeetBot.
14:01:53 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:53 <opendevmeet> The meeting name has been set to 'releaseteam'
14:02:01 <hberaud> Ping list: hberaud armstrong elodilles
14:02:04 <elodilles> o/
14:02:06 <ttx> o/
14:02:12 <hberaud> #link https://etherpad.opendev.org/p/antelope-relmgt-tracking
14:02:21 <lajoskatona> o/
14:02:22 <ralonsoh> hi
14:02:38 <elodilles> hi ralonsoh
14:02:54 <hberaud> We're way down on line 100 now
14:03:21 <hberaud> #topic Review task completion
14:03:50 <hberaud> So the first one was to propose patch for trailing projects https://review.opendev.org/q/topic:zed-trailing-branch-cut
14:04:58 <elodilles> as I see we got -1s for all but one patch. at least we know that teams are planning to do the release there :)
14:05:22 <hberaud> yeah
14:05:34 <hberaud> we won't forgot them
14:05:35 <elodilles> though it would be good not to leave the releses to the deadline
14:05:56 <hberaud> yeah
14:06:28 <hberaud> I'll add a reminder to the next weeks
14:06:44 <hberaud> or at least to R-15
14:06:45 <elodilles> hberaud: ++, thanks!
14:07:31 <hberaud> done
14:08:11 <hberaud> ok, the next task was to propose autorelease for the CWI projects https://review.opendev.org/q/topic:antelope-milestone-1
14:08:27 <hberaud> let's check them
14:09:08 <hberaud> elodilles: so you propose to force those without response?
14:09:17 <elodilles> i've +2'd those that i think can be processed
14:09:33 <hberaud> IIRC during the previous series we prefered to abandon those without response
14:09:57 <hberaud> forcing them WFM, ttx any opinion?
14:10:20 <ttx> yeah, ok to force those without answer
14:10:26 <hberaud> ok
14:11:32 <hberaud> I'll force them after the meeting
14:11:38 <elodilles> ++
14:11:59 <hberaud> so, the next task was "    Catch if there are acl issues in newly created repositories"
14:12:14 <hberaud> and elodilles said  no acl issues were discovered with latest state of project-config + governance repositories
14:12:25 <hberaud> so it seems good
14:12:33 <elodilles> yepp, empty result, looked good
14:13:08 <hberaud> and 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:16 <hberaud> ttx: any update?
14:13:37 <ttx> yes, I started the process internally
14:13:45 <hberaud> ok
14:13:56 <hberaud> so things are ok
14:14:00 <ttx> we should have B by deadline, and C a bit later
14:14:26 <hberaud> ok
14:14:39 <hberaud> so we won't have to manage this point during B?
14:14:58 <hberaud> (if C come just after B)
14:15:41 <ttx> we should still have the action point
14:15:43 <elodilles> then we just need to keep in mind that we'll have a C already :)
14:15:54 <ttx> it's just that we migth start the process internally earlier
14:15:56 <hberaud> ok
14:16:20 <hberaud> (I prefer to ask just to be sure to understand correctly)
14:16:34 <elodilles> the sooner it is decided the better for us, for our processes :]
14:16:39 <hberaud> sure
14:17:21 <hberaud> anything else concerning the tasks, before I move to the next topic?
14:17:31 <elodilles> -
14:18:05 <hberaud> #topic Assign next week tasks
14:18:22 <hberaud> so next week is a free week
14:18:36 <hberaud> so let's assign R-16 now
14:18:55 <ttx> also no task there
14:19:07 <ttx> \o/
14:19:13 <elodilles> :)
14:19:15 <hberaud> elodilles: do you want to handle this one? Approve 'Set Wallaby status to Extended Maintenance' patch
14:19:29 <ttx> I think we do that during the meeting
14:19:33 <hberaud> we could approve it early and let you push the final button
14:19:55 <elodilles> yepp, i think we are almost there, by the way
14:20:17 <hberaud> ttx: ah yes indded
14:20:21 <hberaud> my bad
14:20:35 <hberaud> so... moving to the next topic
14:20:43 <opendevreview> Merged openstack/releases master: Release os-win for Antelope-1 milestone  https://review.opendev.org/c/openstack/releases/+/864528
14:20:51 <hberaud> #topic Review countdown email
14:21:05 <hberaud> I'm sorry I missed to fulfil the template
14:21:07 <elodilles> only Puppet Openstack and OpenStack Ansible wallaby-em patches are missing a +1, but final releases are out for them,
14:21:15 <elodilles> so it should be just formality
14:21:44 <hberaud> thanks to the person who wrote the weekly email
14:22:13 <elodilles> hberaud: no hurry then, I'll be available after the meeting for the review if you want
14:22:20 <hberaud> ok
14:22:42 <hberaud> I'll update the template
14:22:51 <hberaud> after the meeting
14:22:57 <hberaud> thanks elodilles
14:22:59 <ttx> I'll do taht async now
14:23:24 <ttx> while you chair the rest of the meeting :)
14:23:28 <opendevreview> Merged openstack/releases master: Release python-venusclient for Antelope-1 milestone  https://review.opendev.org/c/openstack/releases/+/864541
14:23:31 <opendevreview> Merged openstack/releases master: Release cliff for Antelope-1 milestone  https://review.opendev.org/c/openstack/releases/+/864521
14:23:34 <opendevreview> Merged openstack/releases master: Release tosca-parser for Antelope-1 milestone  https://review.opendev.org/c/openstack/releases/+/864539
14:23:48 <hberaud> ttx: ack, see you later
14:25:58 <hberaud> LGTM
14:26:05 <ttx> looks like the goal link does not work
14:26:28 <elodilles> yepp, not even with 2023.1 if i'm not mistaken
14:26:30 <hberaud> sae thing for zed
14:26:45 <hberaud> and yoga
14:27:08 <ttx> hmm maybe https://governance.openstack.org/tc/goals/selected/ insteda
14:27:09 <hberaud> not sure this error is related to the naming of the series
14:27:21 <ttx> no, it's that they kind of abandoned per-cycle goals I think
14:27:39 <elodilles> https://governance.openstack.org/tc/goals/selected/index.html
14:27:41 <elodilles> yepp
14:27:50 <elodilles> 'active' goals only
14:28:10 <ttx> email lgtm
14:28:10 <fungi> yes, goals are no longer tied to specific release cycles
14:28:24 <fungi> they just start and end whenever is convenient now
14:28:27 <elodilles> LGTM, too
14:28:33 <hberaud> ok
14:28:54 <hberaud> so I'll send the email
14:29:02 <hberaud> fungi: thanks for your confirmation
14:29:06 <elodilles> thanks o/
14:30:01 <fungi> in my opinion it was a bit of a chesterton's fence situation, but i gave up arguing
14:30:31 <hberaud> sent
14:30:56 <hberaud> #topic Reminder skipping meeting next week
14:31:11 <ttx> done :)
14:31:16 <hberaud> :)
14:31:29 <hberaud> #topic Open Discussion
14:31:47 <lajoskatona> Hi, I added a topic there
14:31:51 <hberaud> So our next chair will be ttx at R-16
14:31:56 <ttx> woohoo!
14:32:07 <hberaud> lajoskatona: the floor is yours
14:32:10 <lajoskatona> thanks
14:32:20 <lajoskatona> So the title should be: future (past?) of old branches of tap-as-a-service
14:33:00 <lajoskatona> Since Yoga taas is back to Neutron stadium, but beofre that it has no yaml files under releases repo as it was under x/ namespace
14:33:29 <lajoskatona> and so the old branches like Ocata, Pike, Queens can only deleted manually if I understand well
14:33:51 <lajoskatona> another perspective is that some of the zuul cfg errors are related to these branches
14:34:08 <lajoskatona> and I would like to ask your help here to delete those branches
14:34:27 <hberaud> taas have ocata, pike, and queens branches even if it wasn't an openstack deliverables at this time?
14:34:30 <lajoskatona> perhaps the problem is more general as we have some flapping projects (even in networking can happen)
14:34:41 <hberaud> I understood correctly?
14:34:41 <lajoskatona> yes
14:34:57 <elodilles> hberaud: that could be a side effect of the migration from x/ to openstack/
14:35:04 <ttx> iirc we can create branches but not remove them
14:35:13 <ttx> fungi: do I remember correctly?
14:35:24 <ttx> we = release team
14:35:29 <elodilles> ttx: actually, we have the right to delete them
14:35:40 <ttx> ah, ok
14:35:43 <elodilles> i've deleted some in the past
14:35:53 <fungi> we can do both
14:36:15 <fungi> gerrit 3.3 added an acl permission for branch deletion
14:36:16 <elodilles> unfortunately we have more lingering old-old-stable branches...
14:36:29 <elodilles> some have the same situation as tap-as-a-service
14:36:44 <fungi> and we refactored the openstack acls to have a central inherited acl which grants branch deletion (and other similar permissions) to the release managers group
14:37:27 <fungi> and there's a rest api method for branch deletion, so it's accessible to scripts/automation
14:37:40 <hberaud> good to know
14:38:06 <fungi> and elodilles wrote a script to semi-automate it
14:38:25 <elodilles> fungi: that is for the 'general' case
14:38:50 <elodilles> fungi: when the EOL'ing is done in the usual manner :)
14:39:21 <hberaud> In this case I think we have to do it manually
14:39:35 <fungi> but yeah, what's not there (yet) is fully automatic deletion of branches when changes merge to remove them
14:39:36 <hberaud> maybe through gerrit
14:39:37 <elodilles> fungi: 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 them
14:39:38 <lajoskatona> by usual you men changing the yaml under releases?
14:40:47 <hberaud> lajoskatona: yeah we propose automated releases for the latest series
14:41:15 <fungi> it sounds like the challenge is that some projects have older branches not tracked in the deliverables files, from before they were officially part of openstack
14:41:17 <lajoskatona> hberaud: thanks
14:41:50 <elodilles> fungi: yes, for example branch was created, but no track in relmgmt's yamls
14:42:33 <fungi> in 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 process
14:42:36 <elodilles> fungi: or the other case is when somehow branches were recreated accidentally (during openstack.org -> opendev.org migration)
14:43:12 <fungi> also cases like ironic's where extra semi-stable branches were created manually by the project maintainers
14:43:23 <elodilles> fungi: yes, and probably needs some EOL(-like?) tagging as well
14:43:38 <fungi> and some projects have stale feature development branches too which were left around after they merged stuff back into master
14:44:01 <elodilles> fungi: yepp, ironic's branches are also one of the non-usual cases (for now :))
14:44:14 <fungi> and cinder's driverfixes branches
14:44:32 <elodilles> i guess feature branches are out of relmgmt team's responsibility?
14:44:40 <hberaud> yeah
14:45:08 <hberaud> we don't know the state of the development on these branches
14:45:23 <fungi> however, only openstack release managers (and gerrit admins) have permission to delete branches currently
14:46:18 <fungi> so unless that's changed, there's nobody else able to clean them up
14:46:45 <elodilles> and create the 'eol' tag
14:47:17 <elodilles> (i guess those are needed, except maybe for the feature branches)
14:47:41 <hberaud> elodilles: do you propose to create eol tag for those TAAS old branches?
14:47:53 <fungi> i 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 rot
14:48:57 <hberaud> (a) could be dangerous on the long term
14:49:28 <fungi> and (b) could lead to taking on more work, and (c) can potentially cause problems for stale job configuraiton and such
14:50:06 <fungi> so there's no clear win, it's a tough decision
14:50:30 <fungi> (c) is essentially status quo at the moment
14:50:52 <elodilles> in my opinion, if we choose (b), then it should be handled outside of deliverables/ at least...
14:51:57 <hberaud> from my POV (b) seems feasible, and the workload shouldn't be horrible
14:52:20 <fungi> from 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:53:41 <fungi> for 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 that
14:54:01 <hberaud> make sense
14:54:20 <fungi> so 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 services
14:55:32 <whoami-rajat> elodilles, hey, I've left a comment on this release patch describing a past concern: https://review.opendev.org/c/openstack/releases/+/864531
14:57:05 <hberaud> So, 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:41 <elodilles> hberaud lajoskatona : do we need to tag the branches before the deletion?
14:57:56 <hberaud> I don't think
14:58:06 <lajoskatona> hmmm, good question
14:58:08 <ttx> wfm
14:58:31 <lajoskatona> I have to chekc if we have any tag on them now
14:59:24 <lajoskatona> but ,thanks for the help and discussion
14:59:35 <elodilles> whoami-rajat: answered on the patch :)
14:59:53 <hberaud> lajoskatona: 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 branches
15:00:08 <hberaud> s/and when/and then/
15:00:15 <fungi> note 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 tag
15:00:44 <lajoskatona> hberaud:  ack
15:00:51 <elodilles> yepp, hence we have the *-eol tags in general
15:00:53 <fungi> also all open changes have to be abandoned before the branch can be deleted
15:01:16 <hberaud> ack
15:01:33 <hberaud> lajoskatona: ^
15:02:48 <lajoskatona> ack, I will double-check check
15:03:03 <hberaud> well, we have exceeded our time, anything else before I close the meeting?
15:03:12 <hberaud> lajoskatona: thanks
15:04:00 <hberaud> OK, thanks everyone. Let's wrap up.
15:04:05 <hberaud> #endmeeting