14:01:57 #startmeeting releaseteam 14:01:57 Meeting started Fri Apr 5 14:01:57 2024 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:57 The meeting name has been set to 'releaseteam' 14:01:59 you could say it's based on debian, their use of codenames pre-dates ubuntu's existence, and was precisely because of the inability to predict version numbers 14:02:04 o/ 14:02:04 thanks ttx! 14:02:05 o/ 14:02:14 \o 14:02:22 (we forgot to call for a chair on last meeting :S) 14:02:35 fungi: indeed. We borrowed the alpha ordering to ubuntu :) 14:02:55 Ping list: elod armstrong release-team 14:03:16 #topic Review task completion 14:03:25 I hope they are all done, otherwise we have a problem :) 14:03:34 :] 14:04:06 I did log one thing to change... check the map earlier in the process so that it's ready to update at release time 14:04:07 all done fortunately, we striked out every finished tasks o:) 14:04:19 i do need to remember to merge the signing key rotation change on monday 14:04:23 but otherwise it went reasonably well 14:04:45 PyPI acted up a bit, and Zuul was not in its best day 14:04:51 #link https://review.opendev.org/913274 Replace 2024.1/Caracal key with 2024.2/Dalmatian 14:05:04 also i guess we can approve the revert of the semaphore removals now 14:05:10 indeed 14:05:22 oh yes 14:05:23 fungi: +1 14:05:28 #link https://review.opendev.org/914689 Revert "Temporarily remove release docs semaphores" 14:06:32 as for the zuul slowness we observed, we think we narrowed down the cause to a change in database queries which took effect on saturday in our weekly automated upgrades 14:07:05 upgrading the database server version ought to help, but we're still evaluating what we're going to upgrade it to 14:07:13 update at which level? zuul? 14:07:19 hmm, maybe we should hold on those the weekend before release... but that would likely be a complex exception 14:07:47 yes, some database queries in zuul were made more correct, but that ended up not being able to take advantage of optimizations on older mysql versions 14:08:04 i see thx 14:08:44 #topic Assign next week tasks 14:08:53 and the query planner on latest mariadb seems to also have problems with those queries, so we're doing parallel evaluations between mysql and mariadb performance now 14:08:56 #link https://etherpad.opendev.org/p/dalmatian-relmgt-tracking 14:09:35 won't be there so I'm skipping my turn 14:09:52 ACK 14:11:37 I can chair the PTG meeting unless someone else wants to 14:11:53 ttx: please do o:) 14:12:17 Alright all assigned 14:12:31 #topic Open Discussion 14:12:34 Two things... 14:12:36 note: etherpad is not complete yet, so updates might arrive 14:13:01 I would move up the meeting time one hour now that everyone is on DST... but after next week PTG meeting 14:13:18 so 13:00utc instead of 14:00utc, starting April 19 14:13:20 +1 I proposed that last week already 14:13:27 ttx: +1 14:13:52 well starting May 3rd since next two irc meetings are skipped 14:14:11 +1 14:14:27 I can push the update to irc-meetings after the meeting 14:14:36 agreed 14:14:38 thanks o/ 14:14:50 Second... I'd like to look at the review backlog since there are a bunch of things that seem stuck 14:15:30 Like https://review.opendev.org/c/openstack/releases/+/887505 14:15:59 So let's link to our favorite stuck reviews to give them immediate attention 14:16:56 is there anyone from tripleo who could comment? 14:17:06 i mean, if there isn't then let's merge :) 14:17:07 most of the tripleo retirement is still blocked on content removal, but that one could go in IMO 14:17:21 the team is dissolved afaict 14:18:27 also https://review.opendev.org/c/openstack/releases/+/910395 could then be abandoned IMO 14:18:29 ACK, if there's no activity at all around tripleo deliverables, then I'm OK with this 14:18:36 patch LGTM 14:19:14 then there's the remainder of https://review.opendev.org/q/topic:%22vwx-unmaintained%22+status:open 14:19:32 elodilles: did you look at my proposal from this morning yet? 14:20:07 I can do that for the other inactive projects, too, if you agree 14:20:29 #link https://review.opendev.org/c/openstack/releases/+/915113 14:20:32 just for ref 14:21:36 frickler: haven't double-checked the hashes yet, but otherwise looks fine 14:21:55 frickler: please do 14:22:57 hberaud: looks like https://review.opendev.org/c/openstack/releases/+/872653 is blocked on you 14:23:08 elodilles: I didn't check the hashes either I must admit, just took them from your patch ;) 14:23:11 lemme check 14:23:35 ttx hberaud : wasn't that updated already with a different patch? :-o 14:23:40 it looks familiar to me 14:24:28 don't remember 14:24:28 I think we did that recentish, yes 14:24:32 oh, nope, that was another patch 14:25:03 we did add it to R-8 week's mail 14:25:17 'Cycle highlights deadline: $highlights (R-4 week)' 14:25:41 We also need some stance on https://review.opendev.org/c/openstack/reno/+/904049 -- I don;t care that much either way, but would lean toward accepting since it's been so gracefully proposed 14:27:13 to me this is similar to pbr, we shouldn't drop support until we really need to 14:27:18 Should we close https://review.opendev.org/q/topic:%22zed-stable%22+status:open in the absence of PTL+1 ? 14:27:44 +1 to closing zed-stable 14:28:14 Hervé Beraud proposed openstack/releases master: update the cycle highlight date into the mail template https://review.opendev.org/c/openstack/releases/+/872653 14:28:18 there is a non-zero chance those releases are no longer current anyway 14:28:24 well, i'll close them then, zed will move to Unmaintained in a month anyway 14:28:43 i'm sure that e.g. neutron team will do another release before the transition 14:28:44 then there's the 2024.2 vs. dalmatian situation for links and possibly also for the deliverables directory name. despite ttx's theory I'd like to use the former everywhere 14:28:51 fungi: is there a project-wide stance on aggressive Python version abandonment? 14:28:53 but let's abandon these old patches 14:29:10 https://review.opendev.org/c/openstack/releases/+/903635 seems related 14:29:11 ttx: not really, no 14:29:14 * elodilles clicks and doing the abandonings 14:29:18 fungi: context: https://review.opendev.org/c/openstack/reno/+/904049 14:29:36 python 3.6 is EOL 14:29:42 and https://review.opendev.org/c/openstack/releases/+/914619 need discussion I guess 14:29:47 and Python 3.7 is close to EOL 14:30:05 I think that's the point with this reno patch... 14:30:19 hberaud: but only upstream, not for distros, right? 14:30:25 yes 14:30:30 there's a project-wide stance on adding support for new python versions as early as possible, but we don't insist or necessarily even encourage projects to drop support or testing for old versions unless there's some other reason it's necessary 14:30:41 Any reason to hold on https://review.opendev.org/c/openstack/releases/+/912714 https://review.opendev.org/c/openstack/releases/+/910456 https://review.opendev.org/c/openstack/releases/+/913305 ? 14:31:33 "stop supporting x because it's old" isn't really a great argument. "stop supporting x because we want to use some newer thing that will be really hard to retain backward compatibility for" is reasonable 14:31:48 ok 14:32:03 that said, reno doesn't strictly need to be run on older python versions, unlike pbr 14:32:05 ttx: those all depends on open gov changes? 14:32:11 ttx: the patches on 'depends-on' not merged there 14:32:31 damn 14:32:55 though it would be good to merge these 'retire' patches ASAP :/ 14:33:11 before trailing Caracal release at least :P 14:34:08 Alrigth, that's all I had 14:34:16 Anything else before we close the meeting? 14:35:12 about py36&py37 dropping patch: we had a bad experience when the community started to drop py38 versions and things became broken due to things not supporting the proper versions :S so i have a fear when seeing these patches o:) 14:35:12 re: openstack map on the website I'll get it updated asap to match openstack-map repo contents 14:35:27 assuming I'll get feedback on the patches I mentioned later, that's it for me 14:36:25 ttx: I'll be happy to review a new review before pusblishing if needed 14:36:32 *a new version 14:36:42 *publishing 14:37:08 ack thanks 14:37:36 ok, last words? 14:38:19 :X 14:38:35 (nothing from me) 14:38:41 #endmeeting