14:00:05 <ttx> #startmeeting releaseteam
14:00:05 <opendevmeet> Meeting started Fri Nov 14 14:00:05 2025 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:05 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <opendevmeet> The meeting name has been set to 'releaseteam'
14:00:17 <ttx> Ping list: release-team elod
14:00:31 <ttx> Agenda at https://etherpad.opendev.org/p/gazpacho-relmgt-tracking#L86
14:01:18 <elodilles> o/
14:01:34 <ttx> Hi!
14:01:35 <ttx> #topic Review R-20 task completion
14:01:52 <ttx> - Ensure that all trailing projects have been branched for the previous series. (elod)
14:02:08 <elodilles> so, i've run the script to check the state
14:02:39 <elodilles> and kayobe and OSA were the projects that haven't released yet
14:03:37 <elodilles> i did not propose release patches but pinged the PTLs and they confirmed that they are working on the releases
14:03:48 <ttx> should we add a task to cheeck on them in a coming week?
14:04:35 <elodilles> yes, maybe that's OK
14:05:14 <ttx> ok task added
14:05:15 <ttx> - Propose autoreleases for cycle-with-intermediary libraries which did not release since the previous release. (elod)
14:05:15 <elodilles> we have a task on R-17 about the final release patches, but probably would be better to have the RC1 and stable/2025.1 branch cuts prior that
14:05:38 <elodilles> #link https://review.opendev.org/q/topic:gazpacho-milestone-1
14:05:44 <elodilles> the release patches ^^^
14:06:06 <elodilles> around 1/3rd have landed already
14:06:30 <elodilles> we have 2 requests to wait for some patches to merge
14:06:44 <ttx> Should we post a message on them saying we'll approve them Monday if nobody says -1
14:06:59 <elodilles> question is whether we want to force-release the rest, or should we just abandon them
14:07:10 <ttx> oh right, milestone-1
14:07:16 <ttx> probably simpler to drop them
14:07:22 <ttx> teach them a lesson!
14:07:46 <elodilles> :)
14:08:01 <ttx> Let's abandon them with "no feedback from release liaison, abandoned"
14:08:04 <elodilles> most of the release patches don't have serious content, to be honest
14:08:39 <ttx> (on Monday)
14:08:43 <elodilles> though we have already caught some breaking release: oslo.service made heat code to break o:)
14:08:47 <ttx> I can add a task for that
14:09:04 <elodilles> +1
14:10:11 <ttx> - Catch if there are acl issues in newly created repositories (ttx)
14:10:21 <ttx> no issues found
14:10:36 <ttx> - Send weekly email (ttx)
14:10:37 <elodilles> \o/
14:10:41 <ttx> to be done shortly
14:10:42 <fungi> we haven't been creating that many new repos in openstack lately
14:11:02 <ttx> #topic Assign R-19 and R-17 week tasks
14:11:24 <ttx> I think they are all assigned
14:11:35 <ttx> #topic Review weekly countdown email
14:11:43 <ttx> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails
14:11:57 * elodilles clicks
14:13:35 <elodilles> LGTM
14:13:48 <ttx> Will send when meeting ends
14:13:50 <ttx> #topic Open Discussion
14:14:38 <ttx> Anything to cover?
14:15:34 <ttx> going once...
14:15:35 <elodilles> maybe worth to mention the cycle-trailing projects' transitioning issue: OSA is about to move its stable/2024.1 to Unmaintained
14:16:02 <ttx> how is that an issue?
14:16:17 <elodilles> yepp, validator does not allow that to happen
14:16:37 <elodilles> and last cycles we did the workaround to mark the Unmaintained/EOL'd series as 'open' temporarily
14:16:54 <elodilles> but i promised to adapt the code of the validator
14:17:02 <elodilles> just haven't proposed a solution yet
14:17:24 <ttx> we can do the workaround again, I guess...
14:17:48 <elodilles> the problem is that makes it uncomfortable to OSA is that it has to branch OSA-roles first,
14:17:53 <fungi> what's missing for validation there?
14:18:15 <elodilles> then do another release of OSA project itself
14:18:21 <fungi> ah, ordering of repos in the transition i guess
14:18:34 <elodilles> fungi: not missing, but the validator does not allow to release anything beyond 'stable'
14:18:54 <fungi> oh it's that they need a tag on unmaintained?
14:19:08 <fungi> that's definitely a little weird
14:19:41 <elodilles> fungi: cycle-trailing projects do their releases after everything else got released, this is their request, which completely makes sense,
14:19:53 <elodilles> and the same applies when we move to Um/EOL
14:20:31 <elodilles> relmgt granted the exception to them, so that they can prepare their final releases AFTER everything else have branched
14:21:14 <fungi> maybe i'm misunderstanding. they want to tag releases on unmaintained/2024.1, or they still have stable/2024.1 and want to release on that after the eom deadline?
14:21:18 <elodilles> but we don't want to keep e.g. 2024.1 Caracal to linger weeks as 'maintained' while it is already unmaintained
14:21:37 <elodilles> fungi: they still have stable/2024.1
14:21:49 <fungi> okay, that makes more sense, thanks
14:21:55 <elodilles> this is how we did that in the last couple of cycles
14:22:18 <elodilles> anyway, it's just a heads up, that i'm planning to propose a patch for that,
14:22:19 <fungi> so the exception would be for releasing past the deadline, not releasing from an unmaintained/* branch
14:22:43 <elodilles> and if we running out of time, then we have to do the workaround :/
14:23:41 <elodilles> fungi: yes: to allow cycle-trailing modelled projects to release in Unmaintained state from their stable branch
14:23:42 <ttx> ok... anything else?
14:23:49 <elodilles> ttx: nothing else from me
14:23:49 <fungi> and policy-wise it seems fine that cycle-trailing projects could have a later deadline for eom transition too, the release tooling just doesn't support that yet
14:24:04 <elodilles> fungi: exactly
14:24:25 <ttx> ok then...
14:24:26 <ttx> have a great weekend!
14:24:31 <elodilles> same to you o/
14:24:32 <fungi> you too!
14:24:34 <ttx> #endmeeting