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