| elodilles | special reminder: we'll have the regular weekly meeting in 40 mins! | 13:20 |
|---|---|---|
| elodilles | (winter time :S) | 13:21 |
| rpittau | hi all! semi-noob questions, how would I go and create a tag in one of the opendev repos? specifically one where I have core rights :) | 13:28 |
| rpittau | standard git push doesn't work and I get a scary "forbidden" in the web ui | 13:28 |
| elodilles | rpittau: what kind of tag do you want to add? rights are stored in project-config repository under gerrit ACLs | 13:43 |
| elodilles | rpittau: but tags are mainly added by release tools | 13:43 |
| rpittau | elodilles: this is related to what JayF was saying yesterday, we need to add eol tags to bugfix branches in the ironic projects | 13:44 |
| elodilles | rpittau: via deliverables/$series/$project.yaml | 13:44 |
| elodilles | rpittau: oh, i see | 13:44 |
| elodilles | let me check the project-config repo | 13:45 |
| rpittau | we don't really need branches and we don't want to pollute the yaml with a bunch of eol entries, we want to remove old branches and we just need the eol tags for that | 13:45 |
| rpittau | thanks elodilles :) | 13:45 |
| elodilles | rpittau: there it is: https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/ironic.config#L47-L48 | 13:47 |
| rpittau | ah! | 13:47 |
| rpittau | thanks a lot | 13:47 |
| elodilles | rpittau: so there is an ironic-release group defined and the member of that group can push tags | 13:47 |
| rpittau | yeah, I see now | 13:48 |
| rpittau | I guess only few of us have that, need to doublecheck | 13:48 |
| rpittau | mmmm I do have that | 13:48 |
| rpittau | that's odd, I get forbidden when trying to create a tag | 13:49 |
| fungi | 0 | 13:50 |
| fungi | rpittau: signed tag? | 13:51 |
| rpittau | fungi: I'm just trying from the web ui, I'm getting Error 403 (Forbidden): Cannot create annotated tag "refs/tags/bugfix/8.1-eol" | 13:51 |
| fungi | annotated tags are something completely different | 13:51 |
| fungi | https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#tagging-a-release | 13:51 |
| rpittau | oh! that's great, thanks, I'll give it a try | 13:52 |
| fungi | git has several kinds of tags (light, annotated, signed) | 13:52 |
| elodilles | #startmeeting releaseteam | 14:01 |
| opendevmeet | Meeting started Fri Nov 10 14:01:30 2023 UTC and is due to finish in 60 minutes. The chair is elodilles. 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 | o/ | 14:01 |
| elodilles | Ping list: elod | 14:01 |
| elodilles | o/ | 14:01 |
| elodilles | #link https://etherpad.opendev.org/p/caracal-relmgt-tracking | 14:01 |
| elodilles | we are @ L53 | 14:02 |
| elodilles | and ttx is travelling, so let's start! | 14:02 |
| elodilles | #topic Review task completion | 14:02 |
| elodilles | 1st task: | 14:02 |
| elodilles | 'Review cycle-trailing projects to check which haven’t released yet. Ask them to prepare their releases, if they haven’t already. (elod)' | 14:02 |
| elodilles | mail is on ML: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/RPTPVHSFSK6PXJGRV775EFVZ4Y4DX2SM/ | 14:03 |
| hberaud | \o/ | 14:03 |
| elodilles | to be honest i forgot about the task and sent it only today morning :S | 14:03 |
| hberaud | np | 14:03 |
| elodilles | anyway, we still have ~1 month so hopefully trailing projects will propose their releases ;) | 14:04 |
| elodilles | and that was the only task for this week (1 week before Caracal-1) | 14:04 |
| elodilles | #topic Assign R-20 week tasks | 14:04 |
| elodilles | oh, hberaud i see you were quick and added your name to the tasks :-o | 14:05 |
| elodilles | thanks for that! | 14:05 |
| hberaud | np | 14:05 |
| elodilles | #topic Review countdown email | 14:05 |
| elodilles | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:05 |
| elodilles | please review ^^^ | 14:05 |
| hberaud | weeks ago I completed a couple of coming empty weeks in our agenda | 14:06 |
| hberaud | and I took some tasks in the same time | 14:06 |
| elodilles | thanks for doing that! | 14:06 |
| hberaud | lgtm | 14:06 |
| elodilles | thanks! \o/ | 14:07 |
| elodilles | will send it after the meeting | 14:07 |
| elodilles | #topic Open Discussion | 14:07 |
| elodilles | anything to mention here? | 14:07 |
| hberaud | nope | 14:07 |
| rosmaita | hello | 14:07 |
| rosmaita | yes | 14:07 |
| elodilles | hello rosmaita o/ | 14:07 |
| rosmaita | \o | 14:07 |
| rosmaita | i was reading through your comments on https://etherpad.opendev.org/p/early-caracal-unmaintained-transition | 14:08 |
| rosmaita | sounds like the consensus of the release team is to put stable/yoga directly to Unmaintained? | 14:09 |
| hberaud | yes | 14:09 |
| elodilles | yepp | 14:09 |
| rosmaita | ok, then it would be helpful if you could review https://review.opendev.org/c/openstack/project-team-guide/+/897505 | 14:09 |
| rosmaita | i think there may be a missing step | 14:09 |
| rosmaita | what i mean is | 14:10 |
| rosmaita | do we need to tag the stable branch before deleting it? | 14:10 |
| rosmaita | or just recreate it from the hash at HEAD? | 14:10 |
| elodilles | my understanding is that we could cut unmaintained/* branches based on a tag | 14:11 |
| rosmaita | yeah, but i don't think the proposal includes that? or what the tag would be called? | 14:12 |
| fungi | technically you could create unmaintained/yoga from the git ref which represents the current stable/yoga branch state, and then delete stable/yoga. but i agree that having a tag indicate the point in history where that transition occurred would be preferable | 14:12 |
| elodilles | and we need a tag for the stable/$series branches anyway that marks their last patch, to not to delete history of the branch | 14:12 |
| elodilles | fungi: ++ | 14:13 |
| fungi | you wouldn't lose the history of stable/yoga since it will be the history of unmaintained/yoga | 14:13 |
| rosmaita | anyone have a snappy name for such a tag? | 14:13 |
| fungi | um... um? | 14:13 |
| elodilles | fungi: ah, right | 14:13 |
| elodilles | :) | 14:13 |
| rosmaita | yoga-end-of-maintenance <-- seems a bit too long, possibly misleading | 14:13 |
| rosmaita | yoga-goodbye | 14:13 |
| rosmaita | yoga-transition | 14:14 |
| elodilles | we had so far like *-em and *-eol | 14:14 |
| fungi | eom is a relatively common abbreviation for end of maintenance | 14:14 |
| rosmaita | yoga-eom works for me | 14:14 |
| fungi | though my acronym dictionary only returns "end of message" | 14:15 |
| elodilles | we could keep *-em (End of Maintenance) but that would be confusing, though that would be the less extra work for us :D anyway, maybe *-eom is OK | 14:15 |
| rosmaita | ok, then for yoga, it sounds like you can use the current tooling, except instead of proposing yoga-em it will propose yoga-eom, and instead of adding the branch 'stable/yoga' we would add the branch 'unmaintained/yoga' | 14:15 |
| rosmaita | the new thing would be deleting stable/yoga | 14:15 |
| fungi | actually i like the idea of reusing "em" since it was supposed to mean the same thing (it signalled the transition from being officially maintained to the unofficial "extended maintenance" state) | 14:16 |
| rosmaita | elodilles: i agree that "em" would be nicer, but since we've already used it, i think we need a new one | 14:16 |
| rosmaita | or, what fungi said | 14:16 |
| elodilles | well, the new thing will be to handle properly *-eom and cut branches from it (as we didn't cut branches from *-em so far) | 14:17 |
| rosmaita | oh right, stable branches are cut by specifying a hash that just happened to be the hash of whatever-em | 14:17 |
| fungi | i understand the reasons for wanting to have a different abbreviation in order to make it clear that the policy has changed somewhat, but in my opinion the policy change is more of a clarification and doesn't actually need a different abbreviation | 14:17 |
| rosmaita | i'm willing to go with the majority on that one if y'all think it won't be confusing | 14:18 |
| fungi | the biggest user-facing change is that the stable branch goes away at -em and an unmaintained branch appears, so they need to switch their branch tracking if they want to consume it directly | 14:18 |
| elodilles | maybe 1 extra point for using a new tag (*-eom) is because we added *-em to the latest / last / final stable release of a deliverable, but now we need to tag the HEAD of the given stable branch instead | 14:19 |
| fungi | i'm not sure there's a difference between those | 14:20 |
| fungi | won't it still ideally be the latest / last / final stable release? | 14:20 |
| rosmaita | well, sometimes there is, like if there were no functional changes to the branch | 14:20 |
| elodilles | so however keeping *-em would be easier maybe, i'd rather use *-eom if we can do the necessary changes relatively fast | 14:20 |
| fungi | there won't be any releases after the -em tag either way | 14:21 |
| fungi | or after the -eom tag, whichever you pick | 14:21 |
| elodilles | fungi: yepp, but that would mean to ask every team to do a release on yoga... which i don't really want | 14:22 |
| fungi | so a final stable point release can (should?) still be made at that transition point if there are commits on the stable branch since the last stable point release | 14:22 |
| rosmaita | well, we traditionally haven't if it's only changes to zuul.yaml or other "bookkeeping" kind of changes | 14:23 |
| elodilles | fungi: a release should be ACK'd by the teams, hence it has more work and sync with teams :S | 14:23 |
| fungi | or you could create unmaintained/yoga from the current state of stable/yoga but tag yoga-e(o)m on the same commit that the last yoga stable point release used | 14:23 |
| fungi | so the last stable point release still signals the transition to e(o)m, and no branch history is lost as everything that merged after the point release is in the history of the unmaintained branch | 14:24 |
| fungi | that would allow you to make yoga consistent with a future process which does equate the last stable point release with the transition to unmaintained | 14:25 |
| fungi | without needing ptls to agree to new point releases on stable/yoga | 14:26 |
| elodilles | i think it's more simple and better to just mark the HEAD (and don't do extra releases) with *-eom and cut the unstable/* branch with a post-release job based on the *-eom tag | 14:27 |
| rosmaita | i guess that would also work for stable/x and stable/w (and stable/v for elodilles) | 14:28 |
| elodilles | maybe we can ask PTLs + release liaisons to push their final releases anyway, IF they need one, before the unmaintained/* transition, which should not be many as most of the active teams have released recently | 14:29 |
| elodilles | but that will also give us sime time before the transition | 14:30 |
| elodilles | rosmaita: yeah, i think so | 14:30 |
| rosmaita | i want to add some notes to the agenda ... is this the R-21 or R-20 meeting? | 14:31 |
| elodilles | as with e.g. wallaby we have wallaby-em so far, and then we mark current stable/wallaby HEAD with wallaby *-eom | 14:31 |
| elodilles | rosmaita: R-21 | 14:31 |
| rosmaita | elodilles: yes, i think that makes sense and would be consistent | 14:31 |
| elodilles | (a bit of a jungle with these tags: *-em *-eom *-eol :D but probably that's just fine :)) | 14:32 |
| elodilles | rosmaita: i can add agreements to meeting logs as well :) | 14:33 |
| elodilles | #info handling the transition to Unmaintained branches | 14:33 |
| elodilles | #agreed strategy is: tag the HEAD of stable/whatever with whatever-eom | 14:33 |
| elodilles | #agreed the stable branch will be deleted and an unmaintainted/whatever branch will be created | 14:34 |
| elodilles | #action send an email to [ptl] telling them to push their final yoga releases | 14:34 |
| elodilles | and a can take that action point ^^^ | 14:35 |
| frickler | wasn't the unmaintained state to be opt-in only and not automatic? | 14:35 |
| rosmaita | well, that's a good point | 14:36 |
| elodilles | frickler: isn't it opt-in for the newer branches? or is it opt-in already starting from yoga? | 14:36 |
| frickler | in my understanding that is the concept of unmaintained branches in general | 14:37 |
| frickler | we only want to have them when there is a clear assignment of who cares about them | 14:37 |
| rosmaita | https://review.opendev.org/c/openstack/project-team-guide/+/897505/6/doc/source/stable-branches.rst#76 | 14:37 |
| rosmaita | current proposal is that the latest eligible Unmaintained is kept open; opt in is for any existing older ones | 14:38 |
| elodilles | frickler: in general, yes, but that will be the future process, and for the existing EM (and Yoga?) branches we should simply create unmaintained/* branches? | 14:38 |
| elodilles | which one is the latest eligible unmaintained? | 14:39 |
| rosmaita | sounds like the idea (in the proposal) is that unmaintained/whatever is always cut, and then there is a grace period, after wihch unmaintained/whatever is tagged -eol and deleted unless the opt-in is exercised | 14:39 |
| rosmaita | well, we are in the transition phase | 14:40 |
| elodilles | sound OK to me ^^^ | 14:40 |
| rosmaita | so the transition proposal was to keep 3 | 14:40 |
| rosmaita | (which wouldn't include victoria) | 14:40 |
| frickler | I was assuming that the eol proposal would happen on the stable branch. and only if there is a -1 on that, we move to unmaintained | 14:40 |
| elodilles | at least it's easier to prepare the tooling to cut unmaintained/* anyway and the EOL'ing is another story then... | 14:40 |
| rosmaita | frickler: at the speed things move in openstack, it's better to do eol on the unmaintained, i think | 14:41 |
| frickler | hmm, o.k., so I think this needs more discussion on the p-t-g review, then | 14:42 |
| rosmaita | frickler: ++ | 14:43 |
| elodilles | though what frickler says that is also possible: if a team does not want to have unmaintained/* than simply tag *-eol and skip *-eom tagging... hmmmm... | 14:43 |
| rosmaita | well, it's not a team-only decision | 14:43 |
| rosmaita | i think there will need to be time for more of a community discussion about keeping the branch and who will maintain it | 14:44 |
| elodilles | that's also true | 14:44 |
| rosmaita | so from my perspective, i want an expired branch moved to 'unmaintained' as soon as possible so it's out of my life | 14:44 |
| frickler | that's what the 1 month grace period suggested by JayF was meant to be for | 14:44 |
| frickler | from my perspective, I don't want to create a branch that is by default deleted again a month later without being of any use | 14:45 |
| rosmaita | i don't know that the openstack community can get *anything* done in one month | 14:45 |
| elodilles | anyway, as a 1st action i'll send a mail to ML about the final stable/yoga release, and start working on patches regarding the *-eom tag + unstable/* branch cutting meanwhile | 14:46 |
| elodilles | maybe this can be done parallel with the discussion on the project-teams-guide patch reviewing | 14:47 |
| rosmaita | elodilles: i think you should also send an email announcing your willingness to maintain unmaintained/victoria (when it exists) | 14:47 |
| rosmaita | otherwise, you'll have to -1 EOL patches | 14:47 |
| rosmaita | also, final question from me | 14:48 |
| rosmaita | aobut the EOL patches | 14:48 |
| rosmaita | fungi suggested one big patch for each project | 14:48 |
| rosmaita | or would you prefer them as patches for project&single seriew | 14:49 |
| rosmaita | *series | 14:49 |
| fungi | i assumed the fewer patches the release team needs to review, the less work it will be overall | 14:49 |
| fungi | as opposed to individual patches for each deliverable+branch combination | 14:49 |
| elodilles | that sounds OK to me, though as I said, let's start with train+ussuri (where those exist, because some projects already EOL'd their train and even ussuri) | 14:49 |
| fungi | usually there will only be one branch transitioning at a time anyway, so the suggestion was to try to transition that branch for multiple deliverables together in one patch | 14:50 |
| elodilles | given that i'll be the one who propose the patches anyway, i can do that in that way | 14:51 |
| fungi | in that case yes. the concern was when/if team leaders are proposing the transition patches in the future | 14:51 |
| elodilles | fungi: i usually group EOL'ing of deliverables by teams anyway | 14:51 |
| fungi | trying to avoid separate teams overwhelming the release team with too many changes | 14:52 |
| rosmaita | right ... we can tell PTLs to wait for the auto-generated patches for EOLing train and ussuri? | 14:52 |
| elodilles | fungi: usually PTLs propose EOL patches, but when we did mass-EOL'ing (e.g. with, pike, queens, rocky, etc) then i created the EOL patches for all remaining deliverables | 14:53 |
| fungi | makes sense | 14:53 |
| elodilles | #action elod to propose train+ussuri EOL patches | 14:54 |
| elodilles | is this OK? ^^^ | 14:54 |
| rosmaita | elodilles: which would you prefer ? i've had cinder patches ready for train through xena for about 6 months now | 14:54 |
| fungi | just wanted to make sure that if individual teams are going to propose eom transition patches, we offer them guidance to do so in whatever way will be most convenient for the release managers | 14:54 |
| rosmaita | fungi++, though that guidance could be "wait for the release team to generate the patches for you" | 14:54 |
| fungi | completely, yes | 14:54 |
| elodilles | rosmaita: we can track cinder's EOL'ing in those patches then, i'll try to remember to skip those deliverables then :) | 14:55 |
| rosmaita | well, i don't mind abandoning them ... whatever is better for you | 14:55 |
| elodilles | fungi: (you mean eol transition, right?) for EOL, for now i can mass-generate the patches, and of course the process can be the same: when a team wants to EOL newer branches, then simply propose their EOL patches for those branches | 14:57 |
| fungi | i mean for either one. in the tc meeting, people were asking how soon the projects can start proposing their transition changes to switch to unmaintained | 14:58 |
| fungi | the goal is to avoid having eager ptls overloading the release managers with too many changes | 14:58 |
| rosmaita | right | 14:58 |
| elodilles | +1 | 14:58 |
| elodilles | OK | 14:59 |
| elodilles | and we are at the end of the meeting time frame | 14:59 |
| elodilles | anything else before i end the meeting? :) | 14:59 |
| rosmaita | nope, we made a lot of progress, thanks! | 14:59 |
| elodilles | note: we can discuss things after ending the meeting of course | 15:00 |
| elodilles | #endmeeting | 15:00 |
| opendevmeet | Meeting ended Fri Nov 10 15:00:11 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2023/releaseteam.2023-11-10-14.01.html | 15:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2023/releaseteam.2023-11-10-14.01.txt | 15:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2023/releaseteam.2023-11-10-14.01.log.html | 15:00 |
| hberaud | thanks elodilles | 15:00 |
| elodilles | thanks everyone for participating o/ | 15:00 |
| elodilles | thanks rosmaita for the bringing the topic up | 15:01 |
| elodilles | i hope that the process will be more clear sooner than later :) | 15:02 |
| *** ykarel is now known as ykarel|away | 15:51 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!