14:01:00 <elodilles> #startmeeting releaseteam
14:01:00 <opendevmeet> Meeting 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 http://wiki.debian.org/MeetBot.
14:01:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:00 <opendevmeet> The meeting name has been set to 'releaseteam'
14:01:11 <elodilles> Ping list: armstrong ttx hberaud diablo_rojo_phone
14:01:15 <hberaud> o/
14:01:24 <elodilles> #link https://etherpad.opendev.org/p/zed-relmgt-tracking
14:01:34 <armstrong> o/
14:01:41 <ttx> o/
14:01:43 <elodilles> o/
14:01:55 <elodilles> we are waaay down at line 309
14:02:29 <elodilles> let's start as there are now some tasks & topics
14:02:37 <elodilles> #topic Review task completion
14:02:56 <elodilles> 1st 'Process any remaining library freeze exception. (all)'
14:03:37 <elodilles> this is done as only oslo.db and oslo.metrics + keystonemiddleware had patches and all merged
14:04:07 <elodilles> 2nd '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:24 <elodilles> mail was sent: https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030223.html
14:05:09 <elodilles> and fyi, we got some responses that this is quite a burden to PTLs to do it together with Feature Freeze
14:05:28 <ttx> yeah i kind of agree
14:05:40 <ttx> Moving it to the week after would make sense
14:05:47 <elodilles> https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030267.html
14:05:58 <elodilles> yepp
14:06:17 <elodilles> there seems to have that conclusion in the thread
14:06:22 <fungi> i 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 constructed
14:06:50 <fungi> so if ptls know most of the things that should be in highlights, then going ahead and adding those helps
14:07:04 <fungi> they can always throw a few more in later after exceptions are past
14:07:35 <elodilles> probably 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 work
14:08:03 <elodilles> fungi: yepp, that seems reasonable
14:08:21 <fungi> and pointing out that adding the ones you know are going to be in the release is good even if there might be more
14:08:32 <elodilles> fungi: ++
14:08:45 <fungi> this is really so the marketing folks can get ideas for what themes to focus on in the press releases and such
14:08:56 <fungi> since it's creative work that takes time
14:09:36 <elodilles> fungi: yepp
14:09:38 <elodilles> #action elod to propose process change based on cycle highlight mail thread
14:09:56 <elodilles> so i'll propose a patch for this ^^^
14:10:20 <ttx> I'd keep it a hard deadline but make it one week later
14:11:38 <elodilles> it will be OK I guess for 99% of the cases, when FFE not overdue that deadline :)
14:11:50 <fungi> hard deadline for a soft data set
14:12:05 <elodilles> fungi: maybe that's a better explanation
14:12:36 <elodilles> anyway, we can discuss this further in the patch
14:12:46 <elodilles> so let's move on
14:12:48 <fungi> cycle highlights added after the deadline may not get incorporated into the overarching release marketing effort, basically
14:13:06 <elodilles> fungi: ++
14:13:26 <elodilles> 3rd task 'Propose autoreleases for cycle-with-intermediary client libraries which had commits that have not been included in a release. (elod)'
14:13:42 <elodilles> patches were proposed: https://review.opendev.org/q/topic:zed-milestone-3
14:13:48 <elodilles> and all merged \o/
14:14:36 <elodilles> 4th 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:55 <elodilles> multiple libraries have only the bot generated changes - probably need a different evaluation
14:15:29 <elodilles> the following libraries have no changes at all: python-adjutantclient python-watcherclient python-zaqarclient
14:15:37 <elodilles> the above 3 are completely abandoned, last merged patches are from ~2021
14:16:01 <elodilles> so we have 2 types of cases here i think:
14:16:29 <elodilles> 1) the completely abandoned ones - which are probably even broken (or with broken gate)
14:18:07 <elodilles> 2) 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:48 <ttx> The client libraries should be kept following the cycle
14:19:08 <ttx> I think
14:19:18 <ttx> It's not the same as a "stable" library
14:19:20 <hberaud> I'd say the same thing...
14:19:34 <ttx> they just did not get features serverside that warrant a release
14:19:43 <elodilles> ttx hberaud : ack, i see
14:19:48 <ttx> but as soon as they do they will need to keep up
14:20:14 <ttx> i think changing the model makes sense for things like oslo libs when they get stable
14:20:28 <ttx> but client libs should stay close to their server counterpart
14:20:31 <elodilles> ttx: sounds reasonable
14:21:16 <ttx> I guess the task could be updated to: "Evaluate any non-client libraries..."
14:21:36 <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 general
14:21:42 <elodilles> is this ok? ^^^
14:21:57 <hberaud> LGTM
14:22:01 <elodilles> ++
14:22:44 <elodilles> #action elod to propose a task update regarding 'Evaluate any libraries...' in the process
14:23:13 <ttx> ++
14:23:14 <elodilles> again, i'll propose a patch and we can refine the phrasing in that
14:23:45 <fungi> i 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 libs
14:24:05 <elodilles> so then the only question is to see what to do with the 3 above (probably broken) client lib?
14:24:56 <elodilles> fungi: won't they become deprecated / retired when feature parity is achieved with osc?
14:25:34 <fungi> some may be if their consumers also get switched to osc
14:26:08 <ttx> Maybe we can reach out about retiring them... but I'd say for Zed we need to release them
14:26:08 <elodilles> so it's probably years... we will see then...
14:26:16 <ttx> even if that means retagging the same SHA
14:27:00 <fungi> yeah, 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 osc
14:27:44 <elodilles> ttx: 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:48 <fungi> so divergence there may mean steadily decreasing activity in the per-service clients even if server-to-server interactions don't get switched to using osc
14:28:43 <fungi> and 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 tc
14:29:31 <fungi> even feature-complete libs still need working tests
14:29:45 <elodilles> yepp
14:30:05 <fungi> and we run (as you're well aware) daily and weekly bitrot jobs to find those
14:31:13 <elodilles> anyway, i can send an email targeting [tc][adjutant][watcher][zaqar] with a warning + a question whether these can be fixed
14:32:24 <elodilles> ttx: so you say we cannot remove them (at this stage) from the deliverables even if they are completely abandoned, right?
14:32:43 <ttx> I think that's something we should do earlier
14:32:48 <ttx> in the cycle
14:32:54 <hberaud> agree
14:33:05 <ttx> By letting them pass the MembershipFreeze we kinda committed to releasing them
14:33:17 <elodilles> ack
14:33:29 <ttx> now is not the time to evaluate the impact of *not* shipping them
14:33:36 <elodilles> so for now we cannot do anything else just *warn* + *ask*
14:33:37 <fungi> though that doesn't mean the release team has committed to fixing those projects in order to make them releasable
14:33:51 <ttx> but yeah we should definitely consider dropping them early next cycle, on the basis that it's stakle
14:34:08 <elodilles> fungi ttx ++
14:34:33 <ttx> fungi: not releasable is another thing, I guess... I hope just retagging the same SHA would work though
14:34:47 <fungi> it probably will
14:35:10 <fungi> as long as they don't need stable branches
14:35:24 <elodilles> ttx: i'm not quite sure as their gates are broken
14:35:26 <fungi> er, even that will probably work
14:36:06 <fungi> two 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 used
14:36:20 <elodilles> and for example debian distro builds their packages together with running tests
14:36:40 <fungi> it's mostly that the dev release versions pbr will calculate on them before the first point releases amy be misleading
14:36:48 <fungi> may be misleading
14:36:52 <ttx> yeah we'll likely be unable to merge anything on the stable branch but the branch itself should just be ok
14:37:28 <ttx> well, I'd say we try, and if it does not work we emergency-pull them off release
14:37:58 <elodilles> ttx: sounds good to me
14:38:02 <fungi> that sounds reasonable. still makes sense to give the tc (and ptls if they're even listening) a heads up that's the plan
14:38:14 <elodilles> and hopefully we can avoid that emergency-pull
14:39:22 <ttx> yeah, plan is "we'll do our best, but definitely consider pulling it off next cycle"
14:39:30 <fungi> in theory they could still get zed versions built after the release if they fix up their repos and request a new tag
14:40:03 <fungi> though in these cases i wouldn't hold my breath
14:40:45 <elodilles> especially as the last merged patches are from 2021 in these libs
14:41:29 <elodilles> anyway, ack, i'll propose release patches + check their gate and send mail if needed
14:42:11 <elodilles> i think we can move on to the next task
14:42:31 <elodilles> 5th 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:46 <elodilles> mail was sent: https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030253.html
14:43:14 <elodilles> this is mostly the ironic ones we have discussed already a couple of times
14:43:39 <elodilles> iurygregory promised that they will release them sooner or later :)
14:44:36 <iurygregory> elodilles, yeah we will =) it's on my list =)
14:44:54 <elodilles> iurygregory: great, thanks \o/ o:)
14:44:56 * iurygregory is finishing the cycle-highlights...
14:45:05 <elodilles> :)
14:45:42 <elodilles> 6th 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:56 <elodilles> prometheanfire: ^^^ o:)
14:47:27 <elodilles> i forgot to ping the team officially, probably i'll send a mail as well
14:48:06 <elodilles> last task: 'Propose DNM changes on every repository to check that tests are still passing with the current set of dependencies. (elod)'
14:48:17 <elodilles> this is a new task in this cycle,
14:48:28 <elodilles> we agreed about this at the PTG
14:49:02 <ttx> should be done post-freeze I suspect?
14:49:06 <elodilles> i've started to draft the new task into the process: https://review.opendev.org/c/openstack/releases/+/853618
14:49:53 <elodilles> ttx: we agreed to do it at R-5 (to have some time to fix the broken gates?)
14:50:16 <elodilles> and i didn't want to bombard the gate at FF
14:50:26 <ttx> elodilles: makes sense
14:50:45 <elodilles> so yes, i haven't pushed patches yet
14:50:47 <prometheanfire> mail sending and stuff is fine, the current bot patches will be merged though
14:50:57 <ttx> But isn't doing it at R-5 a good way to bombard the gate at FF?
14:51:19 <elodilles> prometheanfire: ack
14:51:45 <ttx> that's why I would ercommend doing it late on R-5 or early on R-4
14:51:58 <ttx> once we freeze requirements basically
14:52:34 <ttx> since it's supposed to test that the set we have actually works
14:53:50 <prometheanfire> yep
14:54:34 <elodilles> ttx: 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 aimed
14:55:16 <elodilles> i've prepared a minimal script to propose the DNM patches: https://review.opendev.org/c/openstack/releases/+/855663
14:55:18 <ttx> ++
14:55:59 <elodilles> please let me know if i misunderstood something about this task o:)
14:56:41 <elodilles> otherwise, i'll run it some time later today (and propose DNM patches against libraries for first)
14:57:36 <elodilles> hmmm, we are running out of time, so let's move on... sorry :S
14:57:59 <elodilles> #topic Assign R-4 tasks
14:58:48 <elodilles> please add your name to any task if you'll have time next week
15:00:12 <elodilles> anyway, i've added my name to the ones without owner + wrote 'all' to the exception handling stuff
15:00:30 <elodilles> #topic Review countdown email contents
15:00:39 <elodilles> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails
15:00:42 <elodilles> please review ^^^
15:01:49 <ttx> lgtm
15:02:19 <elodilles> ack, thanks! will send it later
15:02:32 <elodilles> #topic Final choice for Antelope release schedule
15:02:42 <hberaud> LGTM
15:02:50 <ttx> Looks like the 24w option is slightly more popular
15:03:00 <ttx> based on comments on both
15:03:06 <elodilles> hberaud: ++
15:03:19 <ttx> people are either ambivalent or prefer the short one
15:03:23 <elodilles> we have these two plans: https://review.opendev.org/q/topic:antelope-schedule-plan
15:03:34 <elodilles> and yes, as ttx says 24w seems to be the winner
15:04:13 <elodilles> and gmann also prefers the 24w so this is TC perspective as well we can say :)
15:04:35 <ttx> and we really should make one official at this point
15:04:45 <gmann> +1
15:05:18 <elodilles> ttx: do we need to do anything else beyond merging the schedule?
15:05:22 <ttx> no
15:05:27 <ttx> I'll +2 the one I prefer
15:05:58 <elodilles> #agreed to accept & merge the 24w schedule
15:06:02 <ttx> We'll likely want to fix a few things but i would merge this as-is
15:06:14 <ttx> and fix extra things after that
15:06:20 <elodilles> yes, we can propose follow-ups
15:06:26 <elodilles> ++
15:06:53 <elodilles> ttx hberaud please +2+w then the 24w after the meeting when you have time
15:06:57 <elodilles> thanks in advance!
15:06:59 <elodilles> \o/
15:07:01 <hberaud> sure
15:07:01 <ttx> done
15:07:23 <hberaud> done
15:07:23 <elodilles> #topic Open Discussion
15:07:30 <elodilles> thanks, both of you :)
15:08:06 <elodilles> we ran out of time already, so say quickly if you have anything to raise :)
15:08:15 <hberaud> nope
15:08:24 <ttx> nope
15:08:38 <elodilles> ok, then let's wrap up quickly
15:08:45 <fungi> i'm about done creating the 2023.1/antelope cycle artifact signing key, should have changes for that up later today hopefully
15:09:01 <fungi> to list it as pending
15:09:11 <elodilles> fungi: ack, thanks, wanted to ping you with that after the meeting o:)
15:09:41 <elodilles> cool, let's finish then! thanks for participating! o/
15:09:45 <hberaud> elodilles: thanks!
15:09:47 <elodilles> #endmeeting