14:00:04 #startmeeting releaseteam 14:00:04 Meeting started Fri Mar 7 14:00:04 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:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:04 The meeting name has been set to 'releaseteam' 14:00:23 Ping list: release-team armstrong 14:00:33 Agenda at https://etherpad.opendev.org/p/epoxy-relmgt-tracking#L316 14:01:07 o/ 14:01:17 o/ 14:02:13 #topic Review task completion 14:02:31 - Process any remaining client library freeze exception. (all) 14:02:43 #link https://review.opendev.org/q/topic:epoxy-milestone-3+is:open 14:02:58 Looks like it's all done 14:03:13 \o/ 14:03:19 - merge cliff release patch: (all) 14:03:24 #link https://review.opendev.org/c/openstack/releases/+/942996 14:03:34 done too 14:03:38 ~o~ 14:03:49 - Ensure that all new-release patches in requirements repository for the client library releases are merged. This should be an empty list: (all) 14:04:03 #link https://review.opendev.org/q/project:openstack/requirements+branch:master+is:open+topic:new-release 14:04:11 Also all set 14:04:23 nice 14:04:26 - Early in the week, email openstack-discuss list to remind PTLs that cycle-highlights are due this week so that they can be included in release marketing preparations (elod) 14:04:41 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/Y5HUSBSEJ3ZMX7ITGKZH2U4V76MGZUP5/ 14:05:07 done ok? 14:05:11 yepp 14:05:16 - Freeze all cycle-based library releases except for release-critical bugs. Independently-released libraries may still be released, but constraint or requirement changes will be held until after the freeze period (all) 14:05:17 cycle highlight patches are coming slowly 14:05:22 Nothing really to be done 14:05:37 - Propose stable/$series branch creation for all client and non-client libraries that had not requested it at freeze time (elod) 14:05:52 #link https://review.opendev.org/q/topic:epoxy-stable-branches 14:06:20 as i said in the morning those can be processed 14:06:24 the open ones 14:06:24 I can approve the ones that were PTL+1ed 14:06:49 ttx: thanks in advance 14:06:59 only oslo is the one we have to think a bit 14:07:36 but if i understand correctly we can continue with the oslo patch as well 14:08:04 as hberaud[m] and frickler discussed that the oslo releases can wait till 2025.2 Flamingo 14:08:28 Should we wait until Monday to approve the ones that did not get the PTL+1 from their PTL? 14:08:41 (I just pushed the ones who did get the approval) 14:09:01 In the spirit of not releasing too much on a Friday 14:09:03 ttx: in general i would not wait, but maybe oslo needs an official statement, i don't know 14:09:16 late o/ 14:09:21 ttx: these are not releases actually, but branch cuts o:) 14:09:44 ok, if those only cut branches I'll push them too 14:09:53 thanks! 14:11:11 Riccardo Pittau proposed openstack/releases master: Release sushy-tools 2.0.0 https://review.opendev.org/c/openstack/releases/+/943234 14:11:33 It's going to take me a few minutes, sorry 14:12:16 no problem, take your time :) 14:12:26 we are not in a hurry :) 14:13:22 OK all set 14:13:33 +1 14:13:54 Only oslo is left 14:14:03 sounds OK to me 14:14:21 #topic List cycle-with-intermediary deliverables that have not been refreshed in the last 2 months and send email (ttx) 14:14:47 List came up empty, however I had false positives 14:15:13 O.o 14:15:17 for some reason the release date calculation in list-deliverables is buggy 14:15:29 Like if you run this command: 14:15:40 tox -e venv -- list-deliverables --series epoxy --deliverable release-test --show-dates --verbose 14:15:51 you get 2024-11-08 instead of 2025-01-30 14:16:16 I checked the gitea commits API and it seems to return the right date 14:16:30 i did not delve a lot deeper 14:17:23 (list-deliverables queries the gitea commits API to get the author date on the release request commit 14:17:44 ttx: 2024-11-08 is the patch's creation date: https://paste.opendev.org/show/bJcnWMZW1bDMu26dXwOv/ 14:18:15 well it is the date of the latest release-test patch, yes 14:18:28 yes 14:18:36 hmm 14:18:48 november 8 is the date on the 2023.1-eom tag 14:18:59 so it looks for the date of the tag and then takes that? 14:19:22 i think it considers 2023.1-eom the highest tagged version 14:19:29 as opposed to 8.0.0 14:19:50 nope, the commit tagged 8.0.0 was also made on that date, even if the tag was added later 14:19:53 ah 14:19:58 aha! 14:20:12 good eye 14:20:24 so it's dereferencing the tag 14:21:18 I had the issue with others though 14:21:25 Merged openstack/releases master: [mistral] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943142 14:21:26 * ttx tries to reproduce 14:21:27 Merged openstack/releases master: [trove] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943145 14:21:30 Merged openstack/releases master: [keystone] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943153 14:21:33 Merged openstack/releases master: [cyborg] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943143 14:21:36 Merged openstack/releases master: [OpenStackSDK] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943155 14:21:38 Merged openstack/releases master: [zaqar] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943146 14:21:42 "git show -s 8.0.0" would show the taggig date 14:21:50 *tagging 14:22:40 frickler: yeah, one issue is that list-deliverables does not checkout the target repository, just uses gitea API to retrieve dates 14:23:34 i would not be surprised if asking for the date at the 8.0.0 tag ref returns the commit's date 14:23:43 I had the same issue with networking-baremetal 6.5.0 returning 2024-11-29 14:23:50 we could check whether there is some API query parameter similar to the "-s" 14:23:57 probably treats it like asking for a branch's date 14:24:43 (it was released on Feb 28, 2025) 14:24:51 networking-baremetal seems to be the same situation 14:24:58 and yeah, the commit for networking-baremetal 6.5.0 has Date: Fri Nov 29 07:54:56 2024 +0000 14:25:16 (note that there is a missing '\' in the example command in the process page in the first line) 14:25:59 We could just switch to look up commit dates for the releases repo change 14:26:33 but it is non-trivial to find which one is related to what 14:26:50 anyway, we don't need to solve it now 14:26:53 just wanted to flag it 14:27:18 I will push it to the list of things we need to fix next cycle 14:27:19 Elod Illes proposed openstack/releases master: [doc] Add a missing line break https://review.opendev.org/c/openstack/releases/+/943713 14:27:51 Merged openstack/releases master: [masakari] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943157 14:27:53 Merged openstack/releases master: [nova] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943137 14:27:56 Merged openstack/releases master: [venus] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943162 14:27:59 Merged openstack/releases master: [tacker] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943163 14:28:01 Merged openstack/releases master: [barbican] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943159 14:28:04 Merged openstack/releases master: [vitrage] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943164 14:28:07 Merged openstack/releases master: [octavia] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943138 14:28:10 Merged openstack/releases master: [zun] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943140 14:28:39 +1 14:28:44 - Send weekly email content (ttx) 14:28:50 this I will do in a few minutes 14:29:11 #topic Assign R-3 week tasks 14:29:44 Given that I'm away on R-2 and R+0, i think I'll take over chairing the meeting with R-3 and R-1 14:30:32 ttx: ACK 14:30:39 Merged openstack/releases master: [freezer] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943151 14:30:42 Merged openstack/releases master: [cloudkitty] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943141 14:31:05 ok all tasks assigned 14:31:27 #topic Review weekly countdown email 14:31:36 #link https://etherpad.opendev.org/p/relmgmt-weekly-emails 14:32:12 next Thursday is March 13, not 14 14:32:29 Should it be Thursday March 13 or Friday March 14, as we've been advertising for a while now? 14:32:39 I'm ok with Friday 14:33:09 works for y'all? 14:33:14 yepp, let's keep it 14 if we advertised like that 14:33:53 that is consistent with "All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week" 14:35:01 email looks good? 14:35:51 yepp, LGTM 14:35:59 Merged openstack/releases master: [glance] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943160 14:36:02 Merged openstack/releases master: [cinder] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943152 14:36:04 Merged openstack/releases master: [watcher] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943154 14:36:08 Merged openstack/releases master: [Telemetry] Create 2025.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/943149 14:36:09 #topic Open Discussion 14:36:30 i'll prod some teams about release highlights, looks like only octavia and watcher have any published so far 14:36:36 As usual, we are late for registering to PTG -- should we do as usual, one meeting during our usual time? 14:36:49 fungi: and there are some on the way: 14:36:49 (if yes I can hamdle getting listed) 14:37:10 manila: https://review.opendev.org/c/openstack/releases/+/943654 14:37:28 glance: https://review.opendev.org/c/openstack/releases/+/943621 14:37:42 I wouldn't mind not having a PTG session 14:37:48 neutron was just updated: https://review.opendev.org/c/openstack/releases/+/943634 14:38:42 ttx: i'm OK with having a session at the usual time 14:39:10 frickler: busy agenda or some other reason? 14:39:38 busy agenda and also just having IRC sessions works well for me 14:40:16 IRC sessions works for me as well, but maybe once per cycle it's good to have a video conf o:) 14:40:24 I find those useful to advertise what we are doing to a larger crowd, but maybe we can separate it from the usual meeting and you can skip it 14:41:13 I'm also ok just not doing it if we can't get critical mass 14:41:21 ping me if a large crowd really shows up ;) 14:41:25 :D 14:41:38 touché 14:41:39 :] 14:42:03 anyway, both works for me :) 14:42:05 would not mind talking directly to kacperrh :) 14:42:26 I'l get us on the list, we can always skip it at last minute 14:42:45 ok 14:42:57 thanks ttx 14:43:05 anything else? 14:43:33 maybe this patch to talk about a bit? https://review.opendev.org/c/openstack/releases/+/939280 14:44:20 should we quickly merge it? 14:44:31 oh, ironic-lib, yeah, tough question 14:44:41 Lajos Katona proposed openstack/releases master: Add Neutron cycle highlights (Epoxy release) https://review.opendev.org/c/openstack/releases/+/943634 14:44:43 looks like the dependent patch merged 14:44:57 yepp 14:45:12 what's the status? did we cut a stable branch for it yet? 14:45:29 (there is a reason why we ask deliverables to set by miletone-2) 14:45:32 usually the removal would have to happen by m-2, right? so that's long, long ago 14:45:39 yepp, there is stable/2025.1 14:45:44 frickler: exactly 14:46:17 so technically it is already "released" 14:46:31 not sure how to undo it 14:46:51 I guess if we just remove the file it won;t get listed anymore 14:46:57 yes, let's not do that, and just not place it into 2025.2 deliverables 14:47:03 and it will just have a weird dangling branch 14:48:21 I'm fine either way i think 14:48:49 me too, actually, it would have been better to finalize this before m-2, though :( 14:49:07 1- we remove the deliverable file and forget about it, it's just a repo with a stable/2025.1 branch that won't go anywhere 14:49:34 2- we release it and it's there but nobody does anything with it 14:49:42 (and we will remember to delete that branch when we get there o:)) 14:49:56 i think the critical thing will be for them to remember that they can retire the repo at 2024.2-eom/eol (which should coincide with 2024.1 since 2024.2 is not-slurp?) 14:50:07 (1) might be slightly more consistent with the governance decision 14:50:38 no strong opinion, leaning towards (1) 14:50:42 if we do 1), we should also eol 2025.1 right away 14:50:54 oh, thats a good idea 14:51:09 same: leaning towards (1) if that is possible 14:51:30 can we eol if we delete the deliverable file? 14:51:47 we can do the EOL as well if we want, but it's not super urgent in my opinion 14:51:48 we need to add an eol tag to the file first I think 14:52:13 or do it manually 14:52:23 if we don't do that, the branch will need to be deleted manually, too 14:52:44 yepp 14:53:30 but whatever path, let's do it now and not rediscover this in 5 years like some funny stable/newton branches 14:53:45 frickler: can you take the action of pushing two patches (the eol addition then the deletion of the file)? 14:54:08 hmm, ok 14:54:23 frickler: thanks! I'll add it to next week list 14:54:34 thanks frickler ! 14:55:04 I'm just a bit surprised that rpittau actually +1d https://review.opendev.org/c/openstack/releases/+/943144 despite the deprecation 14:55:45 might have missed it 14:55:53 Alright, anything else to cover? 14:56:34 calling once... 14:56:36 nothing else 14:56:43 calling twice... 14:56:59 #endmeeting