14:01:30 <elodilles> #startmeeting releaseteam
14:01:30 <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:30 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:30 <opendevmeet> The meeting name has been set to 'releaseteam'
14:01:36 <hberaud> o/
14:01:37 <elodilles> Ping list: elod
14:01:39 <elodilles> o/
14:01:52 <elodilles> #link https://etherpad.opendev.org/p/caracal-relmgt-tracking
14:02:09 <elodilles> we are @ L53
14:02:21 <elodilles> and ttx is travelling, so let's start!
14:02:33 <elodilles> #topic Review task completion
14:02:41 <elodilles> 1st task:
14:02:47 <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:03:00 <elodilles> mail is on ML: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/RPTPVHSFSK6PXJGRV775EFVZ4Y4DX2SM/
14:03:05 <hberaud> \o/
14:03:29 <elodilles> to be honest i forgot about the task and sent it only today morning :S
14:03:39 <hberaud> np
14:04:04 <elodilles> anyway, we still have ~1 month so hopefully trailing projects will propose their releases ;)
14:04:31 <elodilles> and that was the only task for this week (1 week before Caracal-1)
14:04:45 <elodilles> #topic Assign R-20 week tasks
14:05:16 <elodilles> oh, hberaud i see you were quick and added your name to the tasks :-o
14:05:16 <elodilles> thanks for that!
14:05:30 <hberaud> np
14:05:37 <elodilles> #topic Review countdown email
14:05:49 <elodilles> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails
14:05:55 <elodilles> please review ^^^
14:06:04 <hberaud> weeks ago I completed a couple of coming empty weeks in our agenda
14:06:22 <hberaud> and I took some tasks in the same time
14:06:33 <elodilles> thanks for doing that!
14:06:57 <hberaud> lgtm
14:07:05 <elodilles> thanks! \o/
14:07:12 <elodilles> will send it after the meeting
14:07:21 <elodilles> #topic Open Discussion
14:07:29 <elodilles> anything to mention here?
14:07:37 <hberaud> nope
14:07:38 <rosmaita> hello
14:07:39 <rosmaita> yes
14:07:48 <elodilles> hello rosmaita o/
14:07:55 <rosmaita> \o
14:08:09 <rosmaita> i was reading through your comments on https://etherpad.opendev.org/p/early-caracal-unmaintained-transition
14:09:02 <rosmaita> sounds like the consensus of the release team is to put stable/yoga directly to Unmaintained?
14:09:25 <hberaud> yes
14:09:33 <elodilles> yepp
14:09:47 <rosmaita> ok, then it would be helpful if you could review https://review.opendev.org/c/openstack/project-team-guide/+/897505
14:09:54 <rosmaita> i think there may be a missing step
14:10:10 <rosmaita> what i mean is
14:10:23 <rosmaita> do we need to tag the stable branch before deleting it?
14:10:38 <rosmaita> or just recreate it from the hash at HEAD?
14:11:05 <elodilles> my understanding is that we could cut unmaintained/* branches based on a tag
14:12:08 <rosmaita> yeah, but i don't think the proposal includes that? or what the tag would be called?
14:12:28 <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:31 <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:13:05 <elodilles> fungi: ++
14:13:15 <fungi> you wouldn't lose the history of stable/yoga since it will be the history of unmaintained/yoga
14:13:17 <rosmaita> anyone have a snappy name for such a tag?
14:13:28 <fungi> um... um?
14:13:32 <elodilles> fungi: ah, right
14:13:40 <elodilles> :)
14:13:45 <rosmaita> yoga-end-of-maintenance  <-- seems a bit too long, possibly misleading
14:13:56 <rosmaita> yoga-goodbye
14:14:10 <rosmaita> yoga-transition
14:14:16 <elodilles> we had so far like *-em and *-eol
14:14:18 <fungi> eom is a relatively common abbreviation for end of maintenance
14:14:30 <rosmaita> yoga-eom works for me
14:15:04 <fungi> though my acronym dictionary only returns "end of message"
14:15:06 <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:36 <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:44 <rosmaita> the new thing would be deleting stable/yoga
14:16:20 <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:22 <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:31 <rosmaita> or, what fungi said
14:17:03 <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:41 <rosmaita> oh right, stable branches are cut by specifying a hash that just happened to be the hash of whatever-em
14:17:47 <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:18:23 <rosmaita> i'm willing to go with the majority on that one if y'all think it won't be confusing
14:18:57 <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:19:21 <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:20:15 <fungi> i'm not sure there's a difference between those
14:20:32 <fungi> won't it still ideally be the latest / last / final stable release?
14:20:41 <rosmaita> well, sometimes there is, like if there were no functional changes to the branch
14:20:56 <elodilles> so however keeping *-em would be easier maybe, i'd rather use *-eom if we can do the necessary changes relatively fast
14:21:04 <fungi> there won't be any releases after the -em tag either way
14:21:20 <fungi> or after the -eom tag, whichever you pick
14:22:24 <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:24 <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:23:03 <rosmaita> well, we traditionally haven't if it's only changes to zuul.yaml or other "bookkeeping" kind of changes
14:23:45 <elodilles> fungi: a release should be ACK'd by the teams, hence it has more work and sync with teams :S
14:23:46 <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:24:41 <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:25:25 <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:26:19 <fungi> without needing ptls to agree to new point releases on stable/yoga
14:27:07 <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:28:30 <rosmaita> i guess that would also work for stable/x and stable/w (and stable/v for elodilles)
14:29:51 <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:30:10 <elodilles> but that will also give us sime time before the transition
14:30:33 <elodilles> rosmaita: yeah, i think so
14:31:37 <rosmaita> i want to add some notes to the agenda ... is this the R-21 or R-20 meeting?
14:31:37 <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:57 <elodilles> rosmaita: R-21
14:31:59 <rosmaita> elodilles: yes, i think that makes sense and would be consistent
14:32:41 <elodilles> (a bit of a jungle with these tags: *-em *-eom *-eol :D but probably that's just fine :))
14:33:07 <elodilles> rosmaita: i can add agreements to meeting logs as well :)
14:33:36 <elodilles> #info handling the transition to Unmaintained branches
14:33:57 <elodilles> #agreed strategy is: tag the HEAD of stable/whatever with whatever-eom
14:34:19 <elodilles> #agreed the stable branch will be deleted and an unmaintainted/whatever branch will be created
14:34:59 <elodilles> #action send an email to [ptl] telling them to push their final yoga releases
14:35:13 <elodilles> and a can take that action point ^^^
14:35:41 <frickler> wasn't the unmaintained state to be opt-in only and not automatic?
14:36:21 <rosmaita> well, that's a good point
14:36:43 <elodilles> frickler: isn't it opt-in for the newer branches? or is it opt-in already starting from yoga?
14:37:14 <frickler> in my understanding that is the concept of unmaintained branches in general
14:37:38 <frickler> we only want to have them when there is a clear assignment of who cares about them
14:37:45 <rosmaita> https://review.opendev.org/c/openstack/project-team-guide/+/897505/6/doc/source/stable-branches.rst#76
14:38:12 <rosmaita> current proposal is that the latest eligible Unmaintained is kept open; opt in is for any existing older ones
14:38:32 <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:39:33 <elodilles> which one is the latest eligible unmaintained?
14:39: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:40:09 <rosmaita> well, we are in the transition phase
14:40:10 <elodilles> sound OK to me ^^^
14:40:23 <rosmaita> so the transition proposal was to keep 3
14:40:31 <rosmaita> (which wouldn't include victoria)
14:40:51 <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:59 <elodilles> at least it's easier to prepare the tooling to cut unmaintained/* anyway and the EOL'ing is another story then...
14:41:30 <rosmaita> frickler: at the speed things move in openstack, it's better to do eol on the unmaintained, i think
14:42:49 <frickler> hmm, o.k., so I think this needs more discussion on the p-t-g review, then
14:43:03 <rosmaita> frickler: ++
14:43:14 <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:38 <rosmaita> well, it's not a team-only decision
14:44:06 <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:25 <elodilles> that's also true
14:44:38 <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:38 <frickler> that's what the 1 month grace period suggested by JayF was meant to be for
14:45:36 <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:49 <rosmaita> i don't know that the openstack community can get *anything* done in one month
14:46:50 <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:47:36 <elodilles> maybe this can be done parallel with the discussion on the project-teams-guide patch reviewing
14:47:36 <rosmaita> elodilles: i think you should also send an email announcing your willingness to maintain unmaintained/victoria (when it exists)
14:47:52 <rosmaita> otherwise, you'll have to -1 EOL patches
14:48:27 <rosmaita> also, final question from me
14:48:34 <rosmaita> aobut the EOL patches
14:48:47 <rosmaita> fungi suggested one big patch for each project
14:49:07 <rosmaita> or would you prefer them as patches for project&single seriew
14:49:12 <rosmaita> *series
14:49:15 <fungi> i assumed the fewer patches the release team needs to review, the less work it will be overall
14:49:48 <fungi> as opposed to individual patches for each deliverable+branch combination
14:49:59 <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:50:48 <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:51:05 <elodilles> given that i'll be the one who propose the patches anyway, i can do that in that way
14:51:44 <fungi> in that case yes. the concern was when/if team leaders are proposing the transition patches in the future
14:51:52 <elodilles> fungi: i usually group EOL'ing of deliverables by teams anyway
14:52:16 <fungi> trying to avoid separate teams overwhelming the release team with too many changes
14:52:22 <rosmaita> right ... we can tell PTLs to wait for the auto-generated patches for EOLing train and ussuri?
14:53:14 <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:40 <fungi> makes sense
14:54:05 <elodilles> #action elod to propose train+ussuri EOL patches
14:54:10 <elodilles> is this OK? ^^^
14:54:11 <rosmaita> elodilles: which would you prefer ? i've had cinder patches ready for train through xena for about 6 months now
14:54:16 <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:51 <rosmaita> fungi++, though that guidance could be "wait for the release team to generate the patches for you"
14:54:59 <fungi> completely, yes
14:55:18 <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:41 <rosmaita> well, i don't mind abandoning them ... whatever is better for you
14:57:27 <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:58:08 <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:41 <fungi> the goal is to avoid having eager ptls overloading the release managers with too many changes
14:58:48 <rosmaita> right
14:58:50 <elodilles> +1
14:59:26 <elodilles> OK
14:59:38 <elodilles> and we are at the end of the meeting time frame
14:59:48 <elodilles> anything else before i end the meeting? :)
14:59:59 <rosmaita> nope, we made a lot of progress, thanks!
15:00:06 <elodilles> note: we can discuss things after ending the meeting of course
15:00:11 <elodilles> #endmeeting