Friday, 2026-01-09

fungijust a heads up that even once zuul is up and running again, you should refrain from approving release requests until we get the (already reset) upload credentials for pypi updated in our zuul secrets in git02:57
fungiand even then, we'll want to start with a test release to make sure we matched them up correctly02:59
-opendevstatus- NOTICE: Zuul is up and running again and should report back to Gerrit successfully. Changes can also merge if there are no other failures, but we expect that publication jobs like docs and tarballs updates will not work currently.05:03
*** ykarel_ is now known as ykarel05:36
opendevreviewElod Illes proposed openstack/release-test master: Bump required python3 version  https://review.opendev.org/c/openstack/release-test/+/97285412:17
opendevreviewMerged openstack/release-test master: Bump required python3 version  https://review.opendev.org/c/openstack/release-test/+/97285412:33
opendevreviewElod Illes proposed openstack/releases master: Test release with release-test 8.3.0  https://review.opendev.org/c/openstack/releases/+/97285912:36
fricklerelodilles: ^^ note we still need to refresh a couple of secrets12:38
elodillesfrickler: ACK, thanks for the info. please +2+A when things are ready ^^^12:56
elodillesreminder: meeting in half an hour13:30
elodilles#startmeeting releaseteam14:00
opendevmeetMeeting started Fri Jan  9 14:00:19 2026 UTC and is due to finish in 60 minutes.  The chair is elodilles. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'releaseteam'14:00
elodillesPing list: release-team elod14:00
elodilles#link https://etherpad.opendev.org/p/gazpacho-relmgt-tracking14:00
ttxo/14:00
ttxhappy new year!14:00
elodilleso/14:00
elodilleshappy new year o/14:00
elodilleswe are @ line 16414:01
elodillesthe 1st half of the cycle has passed already :)14:02
frickler\o14:02
elodillesokay, let's start \o/14:02
elodilles#topic Review past weeks task completion14:03
elodilles- On Monday: send weekly mail from R-13 !!!14:03
elodillesmail sent ^^^14:03
elodilles- Ahead of MembershipFreeze, run governance_consistency.py. (elod)14:03
elodillesthere were mostly the usual consistency issues14:04
elodillesexcept that i don't remember we had reports from cycle independent deliverables :-o14:04
elodillesbut those were valid reports, anyway. so something got fixed o:)14:05
elodilleslet's go into the details14:05
elodilles* Defined in governance but not in deliverable files (excluding deliverables from ['Infrastructure'] team(s) and deliverables specifically marked as being externally managed):14:06
elodillesbarbican-ui14:06
elodillesthis is one of the usual ones14:06
ttxyeah14:06
elodillesi've prepared a governance patch for this:14:06
elodilleshttps://review.opendev.org/c/openstack/governance/+/97231514:06
elodillesi think we have waited enough + there is not much activity, so my proposal is to ignore it in the future14:07
elodilleswith the above governance patch ^^^14:07
frickler+114:07
ttxyeah that's a nice solution14:07
elodillesno response yet from the team, but maybe we are not in the best time period (1st week of new year)14:08
ttxand might attract the TC's attention to those dead (or never born) deliverables14:08
elodilles++14:08
elodillesanother similar case is:14:09
elodillesrbd-iscsi-client -> https://review.opendev.org/c/openstack/governance/+/97231614:09
elodillesand beyond these two, there is a fairly new deliverable on the list:14:10
elodillesgrian-ui14:10
elodilleslet me quote14:10
elodillesnew project (added to governance in May, 2025) -> i've pinged the Telemetry team and they probably won't release it now, but needs to be revisited this in the next cycle14:10
frickler+1 to giving them a bit of time14:10
ttxagreed14:11
elodillesyepp. they explicitly said that the project is not ready to release this, but they want to continue with the deliverable and they will re-evaluate in the next cycle14:12
elodillesnow the other part:14:12
elodilles* Defined in deliverable files but not in (active) governance:14:12
elodilles4 deliverables, all under deliverables/_independent14:13
elodillesmonasca-grafana-datasource, monasca-kibana-plugin, os-client-config, shade14:13
elodilles3 of them are retired, and 1 is only deprecated, but might be that the retirement was just forgotten for it14:14
elodillesnamely, os-client-config is the only deprecated one14:14
elodilles(maybe worth a ping to stephenfin ^^^ as he was dealing with the deprecation and the retirement of shade as well)14:15
elodilles( https://review.opendev.org/c/openstack/governance/+/962197 )14:15
elodillesto fix the above 4 inconsistency, here is my proposal: https://review.opendev.org/c/openstack/releases/+/97232114:16
elodillesit would be good to have an ACK from stephenfin o:)14:16
elodillesotherwise i think we are good with this task14:17
fricklerack, I'll +2 but defer the approval14:17
elodillesfrickler: +114:17
elodillesthx14:17
stephenfinack, yeah I think those can go now14:17
stephenfinleft a +114:17
frickleralso maybe gtema wants to have a look too as ptl14:17
elodillesstephenfin: cool, thanks \o/14:17
elodillesokay, let's move on then to the next task:14:18
gtemadone14:18
elodilles- Propose DNM changes on repositories where no patches merged recently to check that tests are still passing with the current set of dependencies (libraries, client libraries). (elod)14:18
elodillesgtema: thanks, too o/14:18
elodilleshttps://review.opendev.org/q/topic:release-health-check-gazpacho14:18
elodillesfortunately, most of them have a working gate ^^^14:19
elodillesonly 2 failed, and my hope is that the errors were intermittent only14:19
elodillesthat's all about this task14:20
elodilles- Generate a list of all cycle-with-intermediary libraries which did not release since the YYYY-MM-DD date of milestone-1. (elod)14:20
elodilles#link https://review.opendev.org/q/topic:gazpacho-milestone-214:20
elodillesso. here we have the patches, ~half of them got response and we released them14:21
elodilleswhat should we do with the other half?14:22
elodillesi mean, i've added in the commit message, that we'll merge them after Thursday if no response...14:22
elodillesso probably we should not abandon this time14:22
ttxlooking14:23
elodillesit's not yet Gazpacho-3 where we have to release the latest state anyway14:23
elodillesbut Gazpacho-214:23
elodillesso probably we should review them and release, let's say, on Monday14:23
fricklerwe cannot merge them currently anyway. so we could ping oslo team once more, gtema for keystone+sdk and maybe some others, too?14:23
ttxdid any of those do a gazpacho release already?14:23
elodillesfrickler: and that :]14:23
fungiyeah, monday might be possible but i'd call it optimistic14:24
ttxLet's delay those patches until next week?14:24
elodillesfungi: ACK, thanks for the heads up14:24
fungii'll coordinate to make sure we have a successful test release first just to be safe14:24
fungii expect we'll be working through the weekend to replace a bunch of the now-invalidated secrets, but release tooling is high on my priority list to get working again of course14:25
elodilles#action review the remaining Gazpacho-2 patches and approve them if correct + zuul is ready for releasing14:25
elodillesis this OK? ^^^14:25
fungiyep!14:25
elodilles#undo14:25
opendevmeetRemoving item from minutes: #action review the remaining Gazpacho-2 patches and approve them if correct + zuul is ready for releasing14:25
elodilleswell, let's add Monday...14:25
elodilles#action review the remaining Gazpacho-2 patches on Monday and approve them if correct + zuul is ready for releasing14:26
elodillesthis? ^^^14:26
* fungi nods affirmatively14:26
* elodilles nods back :)14:26
frickler+114:27
ttx+114:27
elodillesfungi: thanks for working on it, we'll be waiting for your signal then14:27
elodillesgood. move on then to next task14:28
elodilles- Catch if there are acl issues in newly created repositories. (elod)14:28
elodilles(elod) empty output from tools/aclissues.py14:28
elodillesand that's all about tasks14:29
elodilles#topic Assign R-11 week tasks14:29
elodillesthere's one unassigned task: 'Ensure that all new-release patches in requirements repository for the milestone-2 releases are merged.' is it OK to add 'all' to it,14:30
elodillesor do you want to have a single person on the task?14:30
ttxyeah, all is fine14:30
elodilles+114:31
ttxIt's more so that we remember to review them at next meeting really :)14:31
ttxpretty sure there will be some left over14:31
elodillesyepp14:31
elodillesall taken then14:31
elodilles\o/14:31
elodillesthanks14:31
elodilles#topic Review weekly countdown email14:31
elodilles#link https://etherpad.opendev.org/p/relmgmt-weekly-emails14:31
elodillesplease review ^^^14:32
elodillesoh, one missing thing there: do you see any $other-upcoming-event to list in the mail?14:32
ttxhow about we add "please review the late milestone-2 release patches at XXX if you have not done so already!"14:33
ttxlike just after "we are past milestone-2"14:33
elodillessounds good!14:33
elodillesthanks!14:34
fricklerdo we want to mention the board elections?14:34
fricklerthat's the only other event that comes to my mind14:35
elodilleswe usually say this is more about release stuff to PTLs and liaisons o:)14:35
ttxyeah, we can remove that line14:35
elodillesbut i can bend14:35
ttxfrickler: you can add it14:35
fricklerno, let's leave it as is, fine for me14:36
elodilles+114:36
elodillesOK, if nothing else, then i'll send it later today14:36
elodillesas is14:36
elodilles#topic Open Discussion14:37
elodillesoh, and there are some topics!14:37
elodilles- Updating review rules to account for limited resources (ttx)14:37
elodilles*     Single release-core approval OK for trivial release requests with PTL+114:37
elodilles*     OK to vote on release requests we generated14:37
ttxyes, so...14:38
elodillesunfortunately the 2nd bullet is already the case for many cycles now :/14:38
ttxWe have limited resources for review, so I think we can relax rules for trivial patches14:38
ttxPersonally for example I'll have less time / more distraction so I could go for half a month without reviewing... things should not grind into a halt14:39
ttxso I propose:14:39
ttx- If a release request gets a PTL+1, then a single release core can approve them (it counts as another review, basically)14:40
elodilles+1 (i sadly approve :(14:40
ttx(obviously, if the patch is not trivial, has some complexity or has open questions, we should refrain from +2Aing it14:40
elodilles+1 sounds right14:41
ttxbut if it is a basic patch and it's been reviewed by release liaison, it's safe enough)14:41
elodilles+114:41
ttx- For release requests we generate, it's ok for us to vote on them14:41
frickler+1, do we need to formalize this somehow? or is this meeting's log enough?14:41
ttxThose are usually auto-generated by some tool rather than authored anyway14:42
fricklerack14:42
ttxThis would only apply to release requests14:42
ttxcode changes would still require two pairs of eyes14:42
ttxand we should not self-approve them14:42
ttxbut release requests which do not trigger questions... PTL+1 is ok, and self-approving after PTL+1 is ok14:43
ttxWe should write it down in the relmgt-tracking doc to remember we actually agreed on that14:44
ttxI can add a line on it14:44
ttxand also log it here using #agreed14:44
ttxare both rules ok?14:44
elodillesOK, i had one question but you explained it as well. +1 from me14:44
ttx#agreed Single release-core approval OK for trivial release requests which got PTL+114:45
elodillesboth sounds reasonable to me, unfortunately, we reached the point where we have to take this step14:45
ttx#agreed It's OK for a release-core to vote on trivial release requests they themselves generated14:46
ttx#info a "trivial" release request ais one that requests a new release of a deliverable and which did not trigger any complex question. Code changes should still require two release-core votes14:47
frickler+114:48
ttxThis should not discourage us from recruiting and training a new release-core in the future, but given our recent past track record I'd rather not depend on that14:48
elodillesyep14:48
ttxthat's all I wanted to discuss :)14:48
elodillesthanks for bringing this up and formulating the rules14:49
elodillesduring the holiday i was also thinking to come up with this :/14:50
ttxit just dawned on me that PTL+1 is already another pair of eyes on trivial patches14:50
ttxalso nowadays (1) most patches are generated by tools which don;t make obvious mistakes and (2) our test suite catches 95% of issues really14:51
elodillesyepp14:51
ttxso I'd say we were probably overly cautious. It was good as a training wheels type mechanism... but when we are not actively mentoring...14:52
fungii'll note that for infrastructure configuration changes i often single-core approve them if they're trivial and acknowledged by the affected project's leadership14:52
ttxyeah it's pretty similar14:52
fungilike, i don't want to go making acl changes to keystone unless the keystone ptl is onboard, but if it passes our linter and isn't something particularly novel, i'll just approve without waiting for a second core reviewer14:53
elodillesmakes sense14:54
ttxI think that is all14:55
elodillesACK, thanks14:56
elodillesif no other topics, then let's end the meeting14:56
ttx++14:56
elodillesthanks for participating! o/14:56
elodilles#endmeeting14:56
opendevmeetMeeting ended Fri Jan  9 14:56:33 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:56
opendevmeetMinutes:        https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-01-09-14.00.html14:56
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-01-09-14.00.txt14:56
opendevmeetLog:            https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-01-09-14.00.log.html14:56
frickler\o14:56
elodillesahh, the 'agreed' items are not logged :( https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-01-09-14.00.html14:57
fungii think it might be #agree ?14:57
fungibut i really don't remember now14:58
elodillesme neither14:58
fungiwould have to check the meetbot docs14:58
elodillesmaybe should have grant co-chair right to ttx 14:58
elodilles* I14:58
elodillesmaybe I should have granted co-chair right to ttx14:59
elodilles(well, the log is there, only the summery page misses the list...)15:00
ttxah, will copy them to relmgt-tracking doc15:01
elodillesthanks15:02
elodillesand sorry15:02
fungittx: any idea if you or other release team members have access to the openstack-mirroring account on github.com? we need to generate new ssh and api keys for it, originally added by you in https://review.opendev.org/718479 six years ago19:11
funginot a big deal if you don't, i have access to remove its privileges and create a new replacement account for it, worst case19:13

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!