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