14:00:56 #startmeeting releaseteam 14:00:56 Meeting started Fri Nov 15 14:00:56 2024 UTC and is due to finish in 60 minutes. The chair is elodilles. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:56 The meeting name has been set to 'releaseteam' 14:01:06 o/ 14:01:22 \o 14:01:24 Ping list: release-team 14:01:47 #link https://etherpad.opendev.org/p/epoxy-relmgt-tracking 14:01:57 (my copy paste buffer is dying...) 14:02:07 o/ 14:02:25 we are at line 84 14:03:14 let's start! 14:03:29 #topic Review task completion 14:03:36 1st task was: 14:03:50 'Ensure that all trailing projects have been branched for the previous series. (elod)' 14:04:23 i saw 3 repos from 2 teams that needed stable/2024.2 branching: 14:04:36 kayobe: https://review.opendev.org/c/openstack/releases/+/935271 just merged 14:04:56 so this is done ^^^ \o/ 14:05:03 and 14:05:09 OSA + OSA-roles 14:05:31 seems noonedeadpunk is onto that 14:05:33 i've pinged noonedeadpunk and he promised to prepare the patches 14:05:57 in the coming weeks 14:06:55 we still have 3 weeks until Dalmatian cycle-trailing release deadline: https://releases.openstack.org/epoxy/schedule.html#e-cycle-trail 14:07:25 I'm aware of deadlines and will push patches once we will be ready for them 14:07:37 we had very quiet cycle and were hoping to get release early 14:07:56 but plenty of ideas raised right after ptg 14:08:00 noonedeadpunk: thanks for the heads up, sounds like a plan! 14:08:09 that's also good to hear :) 14:08:18 (and CI failing on us heavily recently) 14:08:23 :-o 14:08:55 hmm, that's not good to hear :/ 14:09:34 anyway... fingers crossed, and thanks again for the info. 14:09:40 2nd task was: 14:09:53 'Propose autoreleases for cycle-with-intermediary libraries which did not release since the previous release. (elod)' 14:10:03 https://review.opendev.org/q/topic:epoxy-milestone-1 14:10:42 as you can see, about third of them have merged, 14:10:59 should we force or just ignore the other ones? 14:11:17 since we are at milestone-1 i guess we can ignore 14:11:36 but i'll ping damani to review the patches maybe 14:11:50 as most of the remaining patches are oslo deliverables 14:12:21 if that is OK for you 14:12:28 ok... maybe we can abandon them next week 14:12:37 give a last chance to everyone 14:12:49 and yes oslo ping sounds like a good idea 14:13:07 ttx: ACK, i'll do the pinging and abandon the ones that do not get responses in some days 14:13:34 we have a task for that anyways o:) 14:13:58 Merged openstack/releases master: New os-ken release 2.11.1 https://review.opendev.org/c/openstack/releases/+/935265 14:13:59 i mean, to keep track of the 'milestone-1 exceptions' 14:14:17 3rd task then: 14:14:33 'To catch if there are acl issues in newly created repositories, run tools/aclissues.py (ttx)' 14:14:38 done that -- no issue reported 14:14:47 cool \o/ 14:15:04 and that was all the tasks 14:15:23 #topic Assign R-19 and R-16 week tasks 14:15:42 though as i see we have not much to assign, 14:16:09 i've added 'all' to 'milestone-1 exceptions' 14:16:11 Took the chairing 14:16:20 ttx: +1, thanks! 14:16:55 #topic Review weekly countdown email 14:17:09 #link https://etherpad.opendev.org/p/relmgmt-weekly-emails 14:17:12 please review ^^^ 14:18:03 lgtm 14:18:22 lgtm, added final release date 14:18:40 good, thanks! 14:18:46 will send if later today 14:18:51 s/if/it 14:19:15 #topic Open Discussion 14:19:27 (frickler) Fix for eom->eol transition 14:19:40 https://review.opendev.org/c/openstack/releases/+/935064 14:20:15 as discussed yesterday, the validation currently fails since the e.g. stable/zed branch is gone 14:20:55 if someone feels inclined to amend the code to actually check the unmaintained/* branch, that would be nice, too 14:21:08 but the above would just skip the check for -eol tags 14:21:49 (the check whether tag-eol is actually on a proper branch) 14:22:18 yes I think that works 14:22:31 sounds + looks good to me with a quick glance, i'll review it thorougly after the meeting 14:23:11 anything else to add here? 14:25:05 (nothing from me) 14:25:31 OK then let's move on 14:25:42 '(frickler) Directly EOL EOM branches for retired projects?' 14:26:01 (solum) https://review.opendev.org/c/openstack/releases/+/934475 14:26:01 (ec2-api) https://review.opendev.org/c/openstack/releases/+/934469 14:26:04 (kuryr) https://review.opendev.org/c/openstack/releases/+/934477 14:26:07 (winstackers) https://review.opendev.org/c/openstack/releases/+/934483 14:26:10 (senlin) https://review.opendev.org/c/openstack/releases/+/934508 14:26:12 (sahara) https://review.opendev.org/c/openstack/releases/+/934496 14:26:15 (murano) https://review.opendev.org/c/openstack/releases/+/934504 14:26:45 I must admit I didn't check yet how we handled these last cycle, but I think I remember we did some direct eols there, too? 14:26:47 i don't have strong feelings here 14:27:13 in general, i'm OK to EOL them 14:27:31 I think it makes sense. If ether is no team to continue maintaining them, it's even more true for old branches 14:27:38 but have to check whether older branches are still open (unmaintained/*) 14:27:57 Maybe just a quick email thread to explain and give anyone opportunity to object 14:28:14 technically, unmaintained branches are supposed to be eol'd if nobody volunteers to be their caretaker 14:29:06 i had previously assumed, based on the original discussions at the forum and subsequently in drafting of the tc resolutions, that most of those branches would go eol after one cycle of being unmaintained 14:29:36 since usually nobody volunteers to keep them in working condition 14:29:42 fungi: well the problem with the latter is that nothing is happening by default 14:29:56 so we still need to actually implement that part of the policy 14:29:57 the plan was that they be eol'd by default 14:30:04 for some value of "we" 14:30:14 ACK, then I will drop a mail to ML and state that we are about to EOL solum, [..], murano in a week if noone steps up. 14:30:30 but yeah, maybe that part of the process was never clearly defined, so it's not actionable as-is 14:31:02 well it is clearly defined in the policy. it is just that the implementation differs 14:31:10 #action elod to drop a mail to ML and state that we are about to EOL solum, [..], murano in a week if noone steps up 14:31:24 is that OK for you? ^^^ 14:31:31 regardless, yes, if the project is retired then newer branches aren't being maintained which means the unmaintained branches can't reasonably continue as-is either 14:31:37 worksforme 14:31:55 elodilles: I'm not convinced that it is worth the effort, but I won't stop you, either 14:33:01 if someone did step up, they'd also have to revive the main branch, wouldn't they? 14:33:11 yeah, since i haven't seen any activity on them (not a surprise, they are retired) so i don't expect either any response, but we will see 14:33:48 frickler: that's a good question. probably yes 14:34:27 some bug fix backport + CI fixes could have been done without master revival... but that's it 14:35:17 alrighty then, this was the last topic 14:35:18 anyway, maybe some miracle happens and someone shows up, we can discuss further steps then 14:35:38 :) 14:35:41 indeed 14:35:48 anything else to bring up before we close the meeting? 14:36:35 #info next meeting is at 13th December 14:37:04 just to note that we will skip some meetings in the coming weeks ^^^ 14:37:08 enjoy the break! 14:37:28 yepp-yepp :) 14:38:04 okay, if nothing else, then thanks everyone for joining o/ 14:38:16 #endmeeting