13:00:10 <elodilles> #startmeeting releaseteam 13:00:10 <opendevmeet> Meeting started Fri May 3 13:00:10 2024 UTC and is due to finish in 60 minutes. The chair is elodilles. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:10 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:10 <opendevmeet> The meeting name has been set to 'releaseteam' 13:00:22 <elodilles> Ping list: release-team elod 13:00:29 <elodilles> #link https://etherpad.opendev.org/p/dalmatian-relmgt-tracking 13:00:45 <ttx> \o 13:00:52 <elodilles> we are @ L54 13:00:55 <elodilles> o/ 13:01:33 <elodilles> frickler wrote he won't be around 13:02:30 <elodilles> hberaud might be around :) 13:02:36 <elodilles> but let's start then 13:02:51 <elodilles> #topic Review task completion 13:03:16 <elodilles> 1st task was: Process Unmaintained transitioning patches for stable/zed (all) 13:03:27 <elodilles> #link https://review.opendev.org/q/topic:zed-unmaintained+is:open 13:03:52 <elodilles> ~half of the projects have transitioned 13:04:16 <elodilles> some late zed final stable release arrived in the recent days 13:04:19 <ttx> should we keep that task for next week? 13:04:34 <elodilles> that's an option, yes 13:04:56 <elodilles> before we punt it to next week i have one comment: 13:05:31 <elodilles> frickler commented on inactive projects that we should not move them to Unmaintained 13:05:54 <elodilles> but every such project went to unmaintained in Yoga 13:06:27 <ttx> not move them to unmaintained... and remove them directly? 13:06:29 <elodilles> so we either 1) move their zed branches to unmaintained for simplicity, 13:06:35 <ttx> or just pause? 13:06:52 <elodilles> or 2) EOL the yoga and zed branches of them, too 13:07:27 <elodilles> i think these two options are the most straightforward ones 13:07:58 <ttx> I don;t have a strong opinion 13:08:08 <elodilles> neither have i :) 13:08:41 <ttx> If frickler feels strongly abou it and is willing to drive the solution, I'm fine with whatever :) 13:09:12 <elodilles> OK, then let's discuss it when he is back 13:09:34 <elodilles> let's move on then to task 2: 13:09:43 <elodilles> 'Create & merge 'Set Zed status to Unmaintained' after every transitioning patch has merged (elod)' 13:09:58 <elodilles> i've created the 2 patches: 13:10:03 <elodilles> #link https://review.opendev.org/c/openstack/releases/+/918034 13:10:12 <elodilles> #link https://review.opendev.org/c/openstack/openstack-manuals/+/918035 13:10:35 <elodilles> here we can wait for the decision of the 1st task i guess 13:10:58 <ttx> yeah 13:11:02 <elodilles> 3rd task was: 13:11:09 <elodilles> 'Add openstack-map check to process after milestone-2 (ttx) https://review.opendev.org/c/openstack/releases/+/915995 ' 13:11:39 <ttx> yes done at the linked patch 13:11:43 <elodilles> needs a 2nd core review 13:11:55 <elodilles> frickler hberaud : when you'll be around ^^^ 13:12:04 <ttx> I can approve it I guess 13:12:22 <elodilles> ++ 13:12:26 <ttx> done 13:12:30 <elodilles> \o/ 13:12:36 <elodilles> 4th task was: 13:12:42 <elodilles> 'Add project health scorecard list to tracking etherpad (ttx) (see bottom of this doc)' 13:13:00 <ttx> yeah so I added a list of all teams at the end of our etherpad 13:13:17 <ttx> The goal is that we write down misses and other force-approved patches 13:13:41 <ttx> every time we move because we did not hear from the team in time 13:14:01 <ttx> and if we see a pattern, we flag it to the TC so that they can anticipate issues 13:14:16 <elodilles> sounds like a plan! 13:14:43 <elodilles> i saw the list of projects at the bottom of the tracking page 13:14:47 <elodilles> LGTM 13:14:53 <ttx> The oens that are stroked out are the ones that are still in governance but do not seem to have deliverables 13:15:00 <ttx> (anymore) 13:15:13 <ttx> so i suspect they are on their way out, or irrelevant to us 13:15:13 <elodilles> 'inactive' projects, right? 13:15:40 <ttx> yeah, but also externally-released 13:15:48 <elodilles> i see 13:15:55 <ttx> like OpenStack-Charms (active but not going through release management) 13:16:02 <elodilles> ++ 13:16:10 <ttx> anyway, let's give it a try for Dalmatian 13:16:20 <elodilles> +1 from me 13:16:58 <elodilles> okay, last task: 13:17:05 <elodilles> 'test PyPI timeout mitigation on release-test (elod)' 13:17:24 <elodilles> * 2 releases: 1) with 'post' tag; 2) on top of that to see how pbr / rel tooling handles 'post' tag 13:17:47 <elodilles> i've started looking it, created the patch: https://review.opendev.org/c/openstack/releases/+/918032 13:18:21 <elodilles> of course, validator errors for these release patches 13:18:32 <elodilles> but that's kind of expected i guess 13:19:06 <elodilles> i haven't checked how pbr handles it 13:19:30 <elodilles> so anyway, i'll take another round with this task 13:20:13 <elodilles> otherwise, these were all the tasks for this week 13:20:22 <elodilles> any question / comment? 13:20:58 <ttx> nope 13:21:11 <elodilles> #topic Assign R-21 week tasks 13:21:15 <elodilles> let's see 13:21:42 <ttx> I took the meeting chair and email send 13:21:46 <elodilles> one task for everyone, and a mail 13:21:56 <elodilles> ttx: thx o/ 13:21:56 <opendevreview> Merged openstack/releases master: Add process step to check openstack map https://review.opendev.org/c/openstack/releases/+/915995 13:22:22 <elodilles> #topic Open Discussion 13:22:36 <elodilles> I added one topic: 13:22:55 <elodilles> (elod) do we want to handle EOL'ing of bugfix/ and feature/ branches in openstack/releases repository? 13:23:41 <elodilles> the background story: i saw a patch that introduces EOL-ing 'feature/' branches 13:24:01 <elodilles> and we had perviously another attempt for 'bugfix/' branches 13:24:06 <elodilles> bugfix/* - https://review.opendev.org/c/openstack/releases/+/900810 13:24:13 <elodilles> feature/* - https://review.opendev.org/c/openstack/releases/+/917788 13:24:49 <elodilles> as I understood this in the past, it was intentional, that these branches were handled (EOL'd and deleted) by the teams themselves 13:25:10 <elodilles> so that these don't add extra burden to release team 13:25:58 <elodilles> the question is whether we want to change our mind and handle these, too? 13:27:24 <elodilles> note: the patches only allow the EOL tagging, branch deletion is not included as it is not yet automated 13:27:39 <ttx> I don;t think that would trigger that much additional work 13:28:14 <ttx> I fear taht we'll have to be involved anyway due to branch ACLs 13:28:34 <elodilles> i guess so, yes 13:28:56 <elodilles> i mean, until now, teams did it manually by themselves (branch deletion) 13:28:56 <ttx> So I'm a weak +1, happy to be overruled by anyone feelgni strongly about it 13:29:46 <elodilles> i don't have strong opinion here either, just remembered we didn't want this in the past o:) 13:30:02 <elodilles> so I'm also OK with it if the team decides so 13:30:35 <elodilles> maybe we can wait for hberaud and frickler's opinion 13:31:15 <ttx> yeah 13:31:57 <elodilles> as I see in the 'team availability note' of next week, they'll probably be around 13:32:23 <elodilles> OK, then that's it from my side 13:32:35 <elodilles> anything else for Open Discussion? 13:33:41 <ttx> nothing from me 13:33:53 <elodilles> then let's end the meeting! 13:34:02 <elodilles> thanks for participating o/ 13:34:05 <elodilles> #endmeeting