Friday, 2022-09-02

opendevreviewYasufumi Ogawa proposed openstack/releases master: Release final python-tackerclient for Zed
opendevreviewYasufumi Ogawa proposed openstack/releases master: Release final python-tackerclient for Zed
opendevreviewPranali Deore proposed openstack/releases master: [glance] Create zed branch for all client and non-client lib
opendevreviewpangliye proposed openstack/releases master: Zed Cycle Highlights for Venus
opendevreviewpangliye proposed openstack/releases master: Zed Cycle Highlights for Venus
opendevreviewMerged openstack/releases master: Release final python-swiftclient for Zed
opendevreviewMerged openstack/releases master: [Glance] Zed milestone 3 release
opendevreviewMerged openstack/releases master: Release final python-manilaclient for Zed
opendevreviewMerged openstack/releases master: Release final python-tackerclient for Zed
opendevreviewMerged openstack/releases master: Release final python-masakariclient for Zed
opendevreviewMerged openstack/releases master: [OpenStackAnsible Roles] Transition Queens to End of Life
elodilleshberaud: thanks for reviewing the zed-milestone-3 patches that don't have PTL responses! \o/09:14
opendevreviewMerged openstack/releases master: Release final python-heatclient for Zed
elodillesnow they are merging ^^^09:27
opendevreviewMerged openstack/releases master: Release final python-troveclient for Zed
opendevreviewMerged openstack/releases master: Release final python-mistralclient for Zed
opendevreviewMerged openstack/releases master: Release final python-keystoneclient for Zed
opendevreviewMerged openstack/releases master: Release final python-saharaclient for Zed
*** carloss is now known as carloss|afk11:28
*** carloss|afk is now known as carloss13:03
elodillesreminder: meeting starts in less than half an hour13:33
opendevreviewElod Illes proposed openstack/releases master: WIP: Add
elodilles#startmeeting releaseteam14:01
opendevmeetMeeting started Fri Sep  2 14:01:00 2022 UTC and is due to finish in 60 minutes.  The chair is elodilles. Information about MeetBot at
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:01
opendevmeetThe meeting name has been set to 'releaseteam'14:01
elodillesPing list: armstrong ttx hberaud diablo_rojo_phone14:01
elodilleswe are waaay down at line 30914:01
elodilleslet's start as there are now some tasks & topics14:02
elodilles#topic Review task completion14:02
elodilles1st 'Process any remaining library freeze exception. (all)'14:02
elodillesthis is done as only oslo.db and oslo.metrics + keystonemiddleware had patches and all merged14:03
elodilles2nd '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.'14:04
elodillesmail was sent:
elodillesand fyi, we got some responses that this is quite a burden to PTLs to do it together with Feature Freeze14:05
ttxyeah i kind of agree14:05
ttxMoving it to the week after would make sense14:05
elodillesthere seems to have that conclusion in the thread14:06
fungii talked with aprice a bit, and also discussed that having an incomplete list of highlights is better than waiting until a complete list can be constructed14:06
fungiso if ptls know most of the things that should be in highlights, then going ahead and adding those helps14:06
fungithey can always throw a few more in later after exceptions are past14:07
elodillesprobably stating that this is not a HARD deadline and a couple of days delay is acceptable maybe would serve the needs, but meh... "postponing" one week could work14:07
elodillesfungi: yepp, that seems reasonable14:08
fungiand pointing out that adding the ones you know are going to be in the release is good even if there might be more14:08
elodillesfungi: ++14:08
fungithis is really so the marketing folks can get ideas for what themes to focus on in the press releases and such14:08
fungisince it's creative work that takes time14:08
elodillesfungi: yepp14:09
elodilles#action elod to propose process change based on cycle highlight mail thread14:09
elodillesso i'll propose a patch for this ^^^14:09
ttxI'd keep it a hard deadline but make it one week later14:10
elodillesit will be OK I guess for 99% of the cases, when FFE not overdue that deadline :)14:11
fungihard deadline for a soft data set14:11
elodillesfungi: maybe that's a better explanation14:12
elodillesanyway, we can discuss this further in the patch14:12
elodillesso let's move on14:12
fungicycle highlights added after the deadline may not get incorporated into the overarching release marketing effort, basically14:12
elodillesfungi: ++14:13
elodilles3rd task 'Propose autoreleases for cycle-with-intermediary client libraries which had commits that have not been included in a release. (elod)'14:13
elodillespatches were proposed:
elodillesand all merged \o/14:13
elodilles4th task: 'Evaluate any libraries that did not have any change merged over the cycle to see if it is time to transition them to the independent release model. (elod)'14:14
elodillesmultiple libraries have only the bot generated changes - probably need a different evaluation14:14
elodillesthe following libraries have no changes at all: python-adjutantclient python-watcherclient python-zaqarclient14:15
elodillesthe above 3 are completely abandoned, last merged patches are from ~202114:15
elodillesso we have 2 types of cases here i think:14:16
elodilles1) the completely abandoned ones - which are probably even broken (or with broken gate)14:16
elodilles2) the ones that merges only the bot generated patches - i.e. they are probably reached the "stable" state to change to independent model (if their team wants this change and they don't need stable/* branches!)14:18
ttxThe client libraries should be kept following the cycle14:18
ttxI think14:19
ttxIt's not the same as a "stable" library14:19
hberaudI'd say the same thing...14:19
ttxthey just did not get features serverside that warrant a release14:19
elodillesttx hberaud : ack, i see14:19
ttxbut as soon as they do they will need to keep up14:19
ttxi think changing the model makes sense for things like oslo libs when they get stable14:20
ttxbut client libs should stay close to their server counterpart14:20
elodillesttx: sounds reasonable14:20
ttxI guess the task could be updated to: "Evaluate any non-client libraries..."14:21
elodilles#agreed client libraries should be kept following the cycle, they just did not get features serverside that warrant a release, no need to change to independent model in general14:21
elodillesis this ok? ^^^14:21
elodilles#action elod to propose a task update regarding 'Evaluate any libraries...' in the process14:22
elodillesagain, i'll propose a patch and we can refine the phrasing in that14:23
fungii also wonder if we're going to see more client libs go stale as features are added to osc first and maybe never to the old per-service libs14:23
elodillesso then the only question is to see what to do with the 3 above (probably broken) client lib?14:24
elodillesfungi: won't they become deprecated / retired when feature parity is achieved with osc?14:24
fungisome may be if their consumers also get switched to osc14:25
ttxMaybe we can reach out about retiring them... but I'd say for Zed we need to release them14:26
elodillesso it's probably years... we will see then...14:26
ttxeven if that means retagging the same SHA14:26
fungiyeah, it's probably a question of whether the server-to-server interactions the per-service clients are used for need additional features, vs user-facing features ending up exclusively in osc14:27
elodillesttx: that's one thing, the other is that if their gate is broken then we'll get responses that they cannot be built, etc, as we got at Yoga release (two days before the release date)14:27
fungiso divergence there may mean steadily decreasing activity in the per-service clients even if server-to-server interactions don't get switched to using osc14:27
fungiand yes, if they don't have working testing, then tat's a sign they're no longer being "developed" and should probably trigger a discussion with the tc14:28
fungieven feature-complete libs still need working tests14:29
fungiand we run (as you're well aware) daily and weekly bitrot jobs to find those14:30
elodillesanyway, i can send an email targeting [tc][adjutant][watcher][zaqar] with a warning + a question whether these can be fixed14:31
elodillesttx: so you say we cannot remove them (at this stage) from the deliverables even if they are completely abandoned, right?14:32
ttxI think that's something we should do earlier14:32
ttxin the cycle14:32
ttxBy letting them pass the MembershipFreeze we kinda committed to releasing them14:33
ttxnow is not the time to evaluate the impact of *not* shipping them14:33
elodillesso for now we cannot do anything else just *warn* + *ask*14:33
fungithough that doesn't mean the release team has committed to fixing those projects in order to make them releasable14:33
ttxbut yeah we should definitely consider dropping them early next cycle, on the basis that it's stakle14:33
elodillesfungi ttx ++14:34
ttxfungi: not releasable is another thing, I guess... I hope just retagging the same SHA would work though14:34
fungiit probably will14:34
fungias long as they don't need stable branches14:35
elodillesttx: i'm not quite sure as their gates are broken14:35
fungier, even that will probably work14:35
fungitwo stable branches diverging from the same commit could still have different stable point releases later as long as there's sufficient gaps in the version numbers used14:36
elodillesand for example debian distro builds their packages together with running tests14:36
fungiit's mostly that the dev release versions pbr will calculate on them before the first point releases amy be misleading14:36
fungimay be misleading14:36
ttxyeah we'll likely be unable to merge anything on the stable branch but the branch itself should just be ok14:36
ttxwell, I'd say we try, and if it does not work we emergency-pull them off release14:37
elodillesttx: sounds good to me14:37
fungithat sounds reasonable. still makes sense to give the tc (and ptls if they're even listening) a heads up that's the plan14:38
elodillesand hopefully we can avoid that emergency-pull14:38
ttxyeah, plan is "we'll do our best, but definitely consider pulling it off next cycle"14:39
fungiin theory they could still get zed versions built after the release if they fix up their repos and request a new tag14:39
fungithough in these cases i wouldn't hold my breath14:40
elodillesespecially as the last merged patches are from 2021 in these libs14:40
elodillesanyway, ack, i'll propose release patches + check their gate and send mail if needed14:41
elodillesi think we can move on to the next task14:42
elodilles5th task: '    List cycle-with-intermediary deliverables that have not been released yet and send a separate email targeted to teams with such unreleased deliverables to remind them that they need to release before $rc1-deadline. (elod)'14:42
elodillesmail was sent:
elodillesthis is mostly the ironic ones we have discussed already a couple of times14:43
elodillesiurygregory promised that they will release them sooner or later :)14:43
iurygregoryelodilles, yeah we will =) it's on my list =)14:44
elodillesiurygregory: great, thanks \o/ o:)14:44
* iurygregory is finishing the cycle-highlights...14:44
elodilles6th task then: 'On Friday, remind the requirements team to freeze changes to openstack/requirements by applying -2 to all open patches. Ensure that reviewers do not approve changes created by the proposal bot, but do approve changes for new OpenStack deliverable releases. (elod)'14:45
elodillesprometheanfire: ^^^ o:)14:45
elodillesi forgot to ping the team officially, probably i'll send a mail as well14:47
elodilleslast task: 'Propose DNM changes on every repository to check that tests are still passing with the current set of dependencies. (elod)'14:48
elodillesthis is a new task in this cycle,14:48
elodilleswe agreed about this at the PTG14:48
ttxshould be done post-freeze I suspect?14:49
elodillesi've started to draft the new task into the process:
elodillesttx: we agreed to do it at R-5 (to have some time to fix the broken gates?)14:49
elodillesand i didn't want to bombard the gate at FF14:50
ttxelodilles: makes sense14:50
elodillesso yes, i haven't pushed patches yet14:50
prometheanfiremail sending and stuff is fine, the current bot patches will be merged though14:50
ttxBut isn't doing it at R-5 a good way to bombard the gate at FF?14:50
elodillesprometheanfire: ack14:51
ttxthat's why I would ercommend doing it late on R-5 or early on R-414:51
ttxonce we freeze requirements basically14:51
ttxsince it's supposed to test that the set we have actually works14:52
elodillesttx: sorry, yes, i wanted to say the same thing that i waited until the FF rush goes down o:) and yes, late R-5 or R-4 should be aimed14:54
elodillesi've prepared a minimal script to propose the DNM patches:
elodillesplease let me know if i misunderstood something about this task o:)14:55
elodillesotherwise, i'll run it some time later today (and propose DNM patches against libraries for first)14:56
elodilleshmmm, we are running out of time, so let's move on... sorry :S14:57
elodilles#topic Assign R-4 tasks14:57
elodillesplease add your name to any task if you'll have time next week14:58
elodillesanyway, i've added my name to the ones without owner + wrote 'all' to the exception handling stuff15:00
elodilles#topic Review countdown email contents15:00
elodillesplease review ^^^15:00
elodillesack, thanks! will send it later15:02
elodilles#topic Final choice for Antelope release schedule15:02
ttxLooks like the 24w option is slightly more popular15:02
ttxbased on comments on both15:03
elodilleshberaud: ++15:03
ttxpeople are either ambivalent or prefer the short one15:03
elodilleswe have these two plans:
elodillesand yes, as ttx says 24w seems to be the winner15:03
elodillesand gmann also prefers the 24w so this is TC perspective as well we can say :)15:04
ttxand we really should make one official at this point15:04
elodillesttx: do we need to do anything else beyond merging the schedule?15:05
ttxI'll +2 the one I prefer15:05
elodilles#agreed to accept & merge the 24w schedule15:05
ttxWe'll likely want to fix a few things but i would merge this as-is15:06
ttxand fix extra things after that15:06
elodillesyes, we can propose follow-ups15:06
elodillesttx hberaud please +2+w then the 24w after the meeting when you have time15:06
elodillesthanks in advance!15:06
elodilles#topic Open Discussion15:07
elodillesthanks, both of you :)15:07
elodilleswe ran out of time already, so say quickly if you have anything to raise :)15:08
elodillesok, then let's wrap up quickly15:08
fungii'm about done creating the 2023.1/antelope cycle artifact signing key, should have changes for that up later today hopefully15:08
fungito list it as pending15:09
elodillesfungi: ack, thanks, wanted to ping you with that after the meeting o:)15:09
elodillescool, let's finish then! thanks for participating! o/15:09
hberaudelodilles: thanks!15:09
opendevmeetMeeting ended Fri Sep  2 15:09:47 2022 UTC.  Information about MeetBot at . (v 0.1.4)15:09
opendevmeetMinutes (text):
elodilleshberaud: thanks too!15:09
ttxthanks elodilles !15:10
elodillesoh, one thing we could have mentioned is the team's leadership model change to DPL :S15:10
elodillesmaybe next time if we don't forget it...15:10
ttxconsider ourselves warned!15:11
elodillesi hope everyone is OK with it15:11
ttxI think one change will be tat we'll add a "Chair:" line for every meeting so that it rotates a bit more15:11
elodillesttx: yepp, that's a good idea15:11
ttxalthough I'll say that elodilles is really good at it15:12
ttxI'm sure you will appreciate a bit of relief there15:12
*** dviroel is now known as dviroel|lunch15:13
elodillesyes, it will be good to rotate as I'm not the best at keeping the time limits (like today :D)15:14
elodillessorry for that o:)15:14
opendevreviewMerged openstack/releases master: Proposed release schedule for 2023.1 Antelope (24w)
opendevreviewGregory Thiemonge proposed openstack/releases master: Release final python-octaviaclient for Zed
opendevreviewElod Illes proposed openstack/releases master: Move Cycle Highlights task to R-4
*** dviroel|lunch is now known as dviroel16:41
opendevreviewCarlos Eduardo proposed openstack/releases master: Zed cycle highlights for Manila
*** dviroel is now known as dviroel|out20:56

Generated by 2.17.3 by Marius Gedminas - find it at!