13:00:03 #startmeeting releaseteam 13:00:03 Meeting started Fri May 17 13:00:03 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:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:03 The meeting name has been set to 'releaseteam' 13:00:07 o/ 13:00:13 Ping list: release-team elod 13:00:15 \o 13:00:21 #link https://etherpad.opendev.org/p/dalmatian-relmgt-tracking 13:00:42 we are @ L97 13:00:50 o/ 13:00:58 Dalmatian-1 ~o~ 13:01:44 life is too short... 13:02:03 o/ 13:02:05 and development cycles fly by 13:02:09 let's start! 13:02:18 #topic Review task completion 13:02:37 1st task: 'Ensure that all trailing projects have been branched for the previous series. (elod)' 13:02:46 kayobe (kolla) and openstack-ansible were not branched 13:02:54 https://review.opendev.org/q/topic:caracal-trailing-branch-cut 13:03:06 patches proposed but teams responded with -1 ^^^ 13:03:40 so we have to keep an eye on these and follow up later 13:03:57 2nd task: 'Propose autoreleases for cycle-with-intermediary libraries which did not release since the previous release. (elod)' 13:04:10 https://review.opendev.org/q/topic:dalmatian-milestone-1 13:04:21 patches were generated ^^^ 13:04:51 many deliverables had only non-functional changes, so around half needed a release patch 13:05:38 and as you can see there are many without response from team 13:06:20 i've +2+PTL-Approved+1'd them, so I think it's OK to proceed with them 13:06:32 if you'll have time to review 13:06:45 Time to fill out the team reponse scorecard at the bottom of the etherpad! 13:07:13 hmmm, right, let me add details quickly 13:11:32 done 13:12:23 move on then: 13:12:55 3rd task: 'Catch if there are acl issues in newly created repositories (ttx)' 13:13:06 * puppet-ceph triggered an issue, but was exempted recently 13:13:15 * updated aclissues to reflect that: https://review.opendev.org/c/openstack/releases/+/919928 13:13:23 anything to add ttx ? 13:13:56 oh sorry 13:14:13 Not much to add... 13:14:20 ACK 13:14:37 4th task: 'Process Unmaintained transitioning patches for stable/zed (all)' 13:14:38 We could change the code so that it's more granular (per repo instead of per-team) but that will do for now 13:14:57 ttx: +1 13:14:58 Linking back to the change with the decision is a great improvement already 13:17:15 ACK 13:17:37 so, about the zed to unmaintained/zed: 13:17:41 https://review.opendev.org/q/topic:zed-unmaintained+is:open 13:18:21 we still have 2 patches to sort out, 13:19:02 but these are special cases 13:19:42 winstackers -> needs EOL rather 13:20:55 and openstack-ansible patch needs an update 13:21:32 #action elod to move winstckers to EOL and update OSA zed-unmtained patch 13:21:39 i'll take care of these ^^^ 13:22:03 sounds good 13:22:08 these were all of the tasks! 13:22:21 #topic Assign R-19 and R-18 week tasks 13:22:43 I'm mostly traveling next week 13:23:20 ACK 13:23:29 will be a short one week for me too 13:23:47 we need a meeting chair for the meeting in two weeks 13:23:53 a bit shorter to me, too, though it still will be 4 days to me :) 13:24:11 thx hberaud :) 13:24:15 taken 13:24:27 just like the tasks! thanks everyone! 13:24:30 move on then 13:24:48 #topic Review countdown email for week R-19 13:24:59 #link https://etherpad.opendev.org/p/relmgmt-weekly-emails 13:25:03 please review ^^^ 13:25:09 one thing to mention: 13:25:19 i'm not sure about the 'goals' 13:25:31 are they still active goals? 13:25:50 it looks like stale tasks 13:25:53 yeah, I was about to ask 13:26:02 e.g. migrate to jammy :S 13:26:12 IIRC last cycle we skipped that mention.. Let me doublecheck 13:26:17 should be more like noble :) 13:26:21 srbac is still active afaict 13:26:39 yes, that one is a long standing task, that's true 13:27:03 Lat cycle we just said "Teams should now be focused on feature development." 13:27:03 so this somewhat feels half-relevant 13:27:17 the TC has not set goals for a while now 13:27:25 yes 13:27:26 I'll take updating/checking that list to the TC 13:27:28 so I support just saying "feature development" 13:27:31 at least not 'cycle goals' 13:27:43 ttx: +1 13:27:44 lgtm 13:27:47 frickler: thanks! 13:28:13 mail updated 13:28:14 We might want to edit the template if goals are not going to come back 13:29:11 well we have some in the pipeline like eventlet deprecation 13:29:12 lgtm 13:29:29 but no consensus on the path forward yet 13:29:37 +1 to the mail 13:29:39 yeah, that one, too :S 13:30:03 anyway, frickler can you update us with info from TC next time? 13:30:22 not sure it will happen that fast, but I'll try to 13:30:29 we could wait with the template update until that is disclosed 13:30:31 ACK 13:31:05 anyway, thanks for the reviews, i'll send the mail after the meeting some time 13:31:23 #topic Open Discussion 13:31:26 we have one topic: 13:31:46 #info (frickler) Automated EOL for feature branches 13:31:54 #link https://review.opendev.org/c/openstack/releases/+/917788/1 13:32:05 #link https://review.opendev.org/c/openstack/releases/+/900810 13:32:17 I found these while looking at open reviews, not sure how to best proceed 13:32:39 so these are about feature + bugfix branches 13:32:58 on one hand I'd like to see those feature branches go away, otoh not sure how much we actually want to get involved 13:33:43 and note, that these are only the branches/deliverables that are listed on releases repo 13:34:53 well https://review.opendev.org/c/openstack/releases/+/917781 would want to add tags for branches that aren't listed currently 13:36:05 if we want to proceed, some agreement on the actual tag name structure would be needed first I guess 13:36:09 right. so, so far only *deliverables* that are listed in releases repo 13:36:11 No strong opinion, I would be fine not getting involved 13:36:28 we handle master and stable branches already, it feels like that's enough :) 13:36:47 +1 with ttx 13:37:48 well we kind of added the handling of unmaintained branches already 13:38:16 at first glance I think it complexify things more than something else 13:38:18 which aren't directly release related, so maybe we already crossed a line there 13:39:41 I'm fine with the tooling handling it 13:39:53 frickler: true, series-eol and series-eom were not directly release related, but still, they are somewhat closer i'd say 13:40:02 But I would not necessarily track those 13:40:31 feature branches, are just feature branches, not sure to see the point with eoling them... 13:40:56 so you'd just delete them without a trace? 13:41:04 yeah 13:42:07 and you'd let teams do that manually? or how would there be tooling for that if we have no record? 13:42:14 That's an option. They were meant as glorified sets of changes 13:42:26 manually 13:42:57 and does the same hold for bugfix branches or are those different? 13:43:33 good question, I think bugfix branches are slightly different use cases 13:43:53 IMO 13:45:07 ironic team handled bugfix branches manually, but by some accident, our tooling re-created some of the branches, so i think that's where the automation idea came from, mainly. (that bug i think (and hope) is fixed in our tooling) 13:45:22 a feature branch, if implementation on it is done, is supposed to be reintegrated somewhere in the official branches 13:45:50 yeah I could see making a case for eoling bugfix branches 13:46:23 a feat branch is IMO a temp branch dedicated to develop a feature and basta 13:46:56 yepp that makes sense ^^^ 13:47:11 but naming and semnatic can diverge between teams... maybe they are seeing feature branches like bugfix branches... don't know 13:47:25 but that's my definition of a feature branch 13:47:41 ok so let's maybe check with timburke whether they can agree to that 13:47:44 something temporary 13:47:53 ok 13:48:10 and then I'll try with rpittau to proceed with the bugfix patch 13:48:45 frickler: ACK, thanks in advance! 13:49:31 anything else to discuss? 13:49:59 nope 13:50:24 well we had gmann's proposal for eoling stable branches of retired projects 13:50:33 (half my idea I admit) 13:50:59 #link https://review.opendev.org/c/openstack/project-team-guide/+/919608 13:52:29 makes sense I think? 13:52:29 oh, i haven't reviewed that yet 13:52:39 to me it's a bit too harsh to directly EOL those stable branches, but I don't object if that is the decision 13:53:06 i mean, we close the option to people show up as maintainers for those repos 13:53:18 but i know that it is quite unlikely 13:53:48 there should be at least 6 months of inactivity before retirement happens 13:54:17 and even inactivity haven't come out of the blue :) 13:54:21 so that's true 13:54:32 and a repo could always be un-retired again 13:54:49 i mean some of these repos were just inactive through multiple cycles :/ 13:54:50 It won't hurt IMO 13:55:00 the opposing concern that on not doing this, people could continue using the stable branch without noticing the retirement 13:55:10 so as I said, i don't object o:) 13:55:34 frickler: that's also true 13:56:16 anyway, feel free to ping me for reviews to those EOL patches and I can +2 them 13:56:37 those still need to be created iiuc, but will do 13:56:44 ++ 13:56:46 gmann: ^^ 13:57:17 any other topic to the remaining 3 minutes? :) 13:57:45 would not mind having them back before jumpiung on my next meeting :) 13:57:55 :) 13:58:04 thanks everyone then! o/ 13:58:06 #endmeeting