| opendevreview | Yasufumi Ogawa proposed openstack/releases master: Release final python-tackerclient for Zed https://review.opendev.org/c/openstack/releases/+/855181 | 01:06 |
|---|---|---|
| opendevreview | Yasufumi Ogawa proposed openstack/releases master: Release final python-tackerclient for Zed https://review.opendev.org/c/openstack/releases/+/855181 | 04:45 |
| opendevreview | Pranali Deore proposed openstack/releases master: [glance] Create zed branch for all client and non-client lib https://review.opendev.org/c/openstack/releases/+/855588 | 05:57 |
| opendevreview | pangliye proposed openstack/releases master: Zed Cycle Highlights for Venus https://review.opendev.org/c/openstack/releases/+/855613 | 07:12 |
| opendevreview | pangliye proposed openstack/releases master: Zed Cycle Highlights for Venus https://review.opendev.org/c/openstack/releases/+/855613 | 07:23 |
| opendevreview | Merged openstack/releases master: Release final python-swiftclient for Zed https://review.opendev.org/c/openstack/releases/+/855180 | 07:44 |
| opendevreview | Merged openstack/releases master: [Glance] Zed milestone 3 release https://review.opendev.org/c/openstack/releases/+/855480 | 08:09 |
| opendevreview | Merged openstack/releases master: Release final python-manilaclient for Zed https://review.opendev.org/c/openstack/releases/+/855170 | 08:14 |
| opendevreview | Merged openstack/releases master: Release final python-tackerclient for Zed https://review.opendev.org/c/openstack/releases/+/855181 | 08:27 |
| opendevreview | Merged openstack/releases master: Release final python-masakariclient for Zed https://review.opendev.org/c/openstack/releases/+/855171 | 08:27 |
| opendevreview | Merged openstack/releases master: [OpenStackAnsible Roles] Transition Queens to End of Life https://review.opendev.org/c/openstack/releases/+/821807 | 08:27 |
| elodilles | hberaud: thanks for reviewing the zed-milestone-3 patches that don't have PTL responses! \o/ | 09:14 |
| hberaud | np | 09:15 |
| opendevreview | Merged openstack/releases master: Release final python-heatclient for Zed https://review.opendev.org/c/openstack/releases/+/855165 | 09:24 |
| elodilles | now they are merging ^^^ | 09:27 |
| opendevreview | Merged openstack/releases master: Release final python-troveclient for Zed https://review.opendev.org/c/openstack/releases/+/855182 | 09:28 |
| opendevreview | Merged openstack/releases master: Release final python-mistralclient for Zed https://review.opendev.org/c/openstack/releases/+/855172 | 09:29 |
| hberaud | \o/ | 09:36 |
| opendevreview | Merged openstack/releases master: Release final python-keystoneclient for Zed https://review.opendev.org/c/openstack/releases/+/855169 | 09:36 |
| opendevreview | Merged openstack/releases master: Release final python-saharaclient for Zed https://review.opendev.org/c/openstack/releases/+/855176 | 09:39 |
| *** carloss is now known as carloss|afk | 11:28 | |
| *** carloss|afk is now known as carloss | 13:03 | |
| elodilles | reminder: meeting starts in less than half an hour | 13:33 |
| hberaud | ack | 13:45 |
| opendevreview | Elod Illes proposed openstack/releases master: WIP: Add repository_test_generator.sh https://review.opendev.org/c/openstack/releases/+/855663 | 13:51 |
| elodilles | #startmeeting releaseteam | 14:01 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'releaseteam' | 14:01 |
| elodilles | Ping list: armstrong ttx hberaud diablo_rojo_phone | 14:01 |
| hberaud | o/ | 14:01 |
| elodilles | #link https://etherpad.opendev.org/p/zed-relmgt-tracking | 14:01 |
| armstrong | o/ | 14:01 |
| ttx | o/ | 14:01 |
| elodilles | o/ | 14:01 |
| elodilles | we are waaay down at line 309 | 14:01 |
| elodilles | let's start as there are now some tasks & topics | 14:02 |
| elodilles | #topic Review task completion | 14:02 |
| elodilles | 1st 'Process any remaining library freeze exception. (all)' | 14:02 |
| elodilles | this is done as only oslo.db and oslo.metrics + keystonemiddleware had patches and all merged | 14:03 |
| 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 |
| elodilles | mail was sent: https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030223.html | 14:04 |
| elodilles | and fyi, we got some responses that this is quite a burden to PTLs to do it together with Feature Freeze | 14:05 |
| ttx | yeah i kind of agree | 14:05 |
| ttx | Moving it to the week after would make sense | 14:05 |
| elodilles | https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030267.html | 14:05 |
| elodilles | yepp | 14:05 |
| elodilles | there seems to have that conclusion in the thread | 14:06 |
| 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 |
| fungi | so if ptls know most of the things that should be in highlights, then going ahead and adding those helps | 14:06 |
| fungi | they can always throw a few more in later after exceptions are past | 14:07 |
| 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:07 |
| elodilles | fungi: yepp, that seems reasonable | 14:08 |
| 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 |
| elodilles | fungi: ++ | 14:08 |
| 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 |
| fungi | since it's creative work that takes time | 14:08 |
| elodilles | fungi: yepp | 14:09 |
| elodilles | #action elod to propose process change based on cycle highlight mail thread | 14:09 |
| elodilles | so i'll propose a patch for this ^^^ | 14:09 |
| ttx | I'd keep it a hard deadline but make it one week later | 14:10 |
| elodilles | it will be OK I guess for 99% of the cases, when FFE not overdue that deadline :) | 14:11 |
| fungi | hard deadline for a soft data set | 14:11 |
| elodilles | fungi: maybe that's a better explanation | 14:12 |
| elodilles | anyway, we can discuss this further in the patch | 14:12 |
| elodilles | so let's move on | 14:12 |
| fungi | cycle highlights added after the deadline may not get incorporated into the overarching release marketing effort, basically | 14:12 |
| elodilles | fungi: ++ | 14:13 |
| 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 |
| elodilles | patches were proposed: https://review.opendev.org/q/topic:zed-milestone-3 | 14:13 |
| elodilles | and all merged \o/ | 14:13 |
| 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 |
| elodilles | multiple libraries have only the bot generated changes - probably need a different evaluation | 14:14 |
| elodilles | the following libraries have no changes at all: python-adjutantclient python-watcherclient python-zaqarclient | 14:15 |
| elodilles | the above 3 are completely abandoned, last merged patches are from ~2021 | 14:15 |
| elodilles | so we have 2 types of cases here i think: | 14:16 |
| elodilles | 1) the completely abandoned ones - which are probably even broken (or with broken gate) | 14:16 |
| 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 |
| ttx | The client libraries should be kept following the cycle | 14:18 |
| ttx | I think | 14:19 |
| ttx | It's not the same as a "stable" library | 14:19 |
| hberaud | I'd say the same thing... | 14:19 |
| ttx | they just did not get features serverside that warrant a release | 14:19 |
| elodilles | ttx hberaud : ack, i see | 14:19 |
| ttx | but as soon as they do they will need to keep up | 14:19 |
| ttx | i think changing the model makes sense for things like oslo libs when they get stable | 14:20 |
| ttx | but client libs should stay close to their server counterpart | 14:20 |
| elodilles | ttx: sounds reasonable | 14:20 |
| ttx | I 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 general | 14:21 |
| elodilles | is this ok? ^^^ | 14:21 |
| hberaud | LGTM | 14:21 |
| elodilles | ++ | 14:22 |
| elodilles | #action elod to propose a task update regarding 'Evaluate any libraries...' in the process | 14:22 |
| ttx | ++ | 14:23 |
| elodilles | again, i'll propose a patch and we can refine the phrasing in that | 14:23 |
| 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:23 |
| elodilles | so then the only question is to see what to do with the 3 above (probably broken) client lib? | 14:24 |
| elodilles | fungi: won't they become deprecated / retired when feature parity is achieved with osc? | 14:24 |
| fungi | some may be if their consumers also get switched to osc | 14:25 |
| ttx | Maybe we can reach out about retiring them... but I'd say for Zed we need to release them | 14:26 |
| elodilles | so it's probably years... we will see then... | 14:26 |
| ttx | even if that means retagging the same SHA | 14:26 |
| 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 |
| 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 |
| 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:27 |
| 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:28 |
| fungi | even feature-complete libs still need working tests | 14:29 |
| elodilles | yepp | 14:29 |
| fungi | and we run (as you're well aware) daily and weekly bitrot jobs to find those | 14:30 |
| elodilles | anyway, i can send an email targeting [tc][adjutant][watcher][zaqar] with a warning + a question whether these can be fixed | 14:31 |
| elodilles | ttx: so you say we cannot remove them (at this stage) from the deliverables even if they are completely abandoned, right? | 14:32 |
| ttx | I think that's something we should do earlier | 14:32 |
| ttx | in the cycle | 14:32 |
| hberaud | agree | 14:32 |
| ttx | By letting them pass the MembershipFreeze we kinda committed to releasing them | 14:33 |
| elodilles | ack | 14:33 |
| ttx | now is not the time to evaluate the impact of *not* shipping them | 14:33 |
| elodilles | so for now we cannot do anything else just *warn* + *ask* | 14:33 |
| fungi | though that doesn't mean the release team has committed to fixing those projects in order to make them releasable | 14:33 |
| ttx | but yeah we should definitely consider dropping them early next cycle, on the basis that it's stakle | 14:33 |
| elodilles | fungi ttx ++ | 14:34 |
| ttx | fungi: not releasable is another thing, I guess... I hope just retagging the same SHA would work though | 14:34 |
| fungi | it probably will | 14:34 |
| fungi | as long as they don't need stable branches | 14:35 |
| elodilles | ttx: i'm not quite sure as their gates are broken | 14:35 |
| fungi | er, even that will probably work | 14:35 |
| 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 |
| elodilles | and for example debian distro builds their packages together with running tests | 14:36 |
| fungi | it's mostly that the dev release versions pbr will calculate on them before the first point releases amy be misleading | 14:36 |
| fungi | may be misleading | 14:36 |
| ttx | yeah we'll likely be unable to merge anything on the stable branch but the branch itself should just be ok | 14:36 |
| ttx | well, I'd say we try, and if it does not work we emergency-pull them off release | 14:37 |
| elodilles | ttx: sounds good to me | 14:37 |
| 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 |
| elodilles | and hopefully we can avoid that emergency-pull | 14:38 |
| ttx | yeah, plan is "we'll do our best, but definitely consider pulling it off next cycle" | 14:39 |
| 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:39 |
| fungi | though in these cases i wouldn't hold my breath | 14:40 |
| elodilles | especially as the last merged patches are from 2021 in these libs | 14:40 |
| elodilles | anyway, ack, i'll propose release patches + check their gate and send mail if needed | 14:41 |
| elodilles | i think we can move on to the next task | 14:42 |
| 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 |
| elodilles | mail was sent: https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030253.html | 14:42 |
| elodilles | this is mostly the ironic ones we have discussed already a couple of times | 14:43 |
| elodilles | iurygregory promised that they will release them sooner or later :) | 14:43 |
| iurygregory | elodilles, yeah we will =) it's on my list =) | 14:44 |
| elodilles | iurygregory: great, thanks \o/ o:) | 14:44 |
| * iurygregory is finishing the cycle-highlights... | 14:44 | |
| elodilles | :) | 14:45 |
| 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 |
| elodilles | prometheanfire: ^^^ o:) | 14:45 |
| elodilles | i forgot to ping the team officially, probably i'll send a mail as well | 14:47 |
| 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 |
| elodilles | this is a new task in this cycle, | 14:48 |
| elodilles | we agreed about this at the PTG | 14:48 |
| ttx | should be done post-freeze I suspect? | 14:49 |
| elodilles | i've started to draft the new task into the process: https://review.opendev.org/c/openstack/releases/+/853618 | 14:49 |
| elodilles | ttx: we agreed to do it at R-5 (to have some time to fix the broken gates?) | 14:49 |
| elodilles | and i didn't want to bombard the gate at FF | 14:50 |
| ttx | elodilles: makes sense | 14:50 |
| elodilles | so yes, i haven't pushed patches yet | 14:50 |
| prometheanfire | mail sending and stuff is fine, the current bot patches will be merged though | 14:50 |
| ttx | But isn't doing it at R-5 a good way to bombard the gate at FF? | 14:50 |
| elodilles | prometheanfire: ack | 14:51 |
| ttx | that's why I would ercommend doing it late on R-5 or early on R-4 | 14:51 |
| ttx | once we freeze requirements basically | 14:51 |
| ttx | since it's supposed to test that the set we have actually works | 14:52 |
| prometheanfire | yep | 14:53 |
| 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:54 |
| elodilles | i've prepared a minimal script to propose the DNM patches: https://review.opendev.org/c/openstack/releases/+/855663 | 14:55 |
| ttx | ++ | 14:55 |
| elodilles | please let me know if i misunderstood something about this task o:) | 14:55 |
| elodilles | otherwise, i'll run it some time later today (and propose DNM patches against libraries for first) | 14:56 |
| elodilles | hmmm, we are running out of time, so let's move on... sorry :S | 14:57 |
| elodilles | #topic Assign R-4 tasks | 14:57 |
| elodilles | please add your name to any task if you'll have time next week | 14:58 |
| elodilles | anyway, i've added my name to the ones without owner + wrote 'all' to the exception handling stuff | 15:00 |
| elodilles | #topic Review countdown email contents | 15:00 |
| elodilles | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 15:00 |
| elodilles | please review ^^^ | 15:00 |
| ttx | lgtm | 15:01 |
| elodilles | ack, thanks! will send it later | 15:02 |
| elodilles | #topic Final choice for Antelope release schedule | 15:02 |
| hberaud | LGTM | 15:02 |
| ttx | Looks like the 24w option is slightly more popular | 15:02 |
| ttx | based on comments on both | 15:03 |
| elodilles | hberaud: ++ | 15:03 |
| ttx | people are either ambivalent or prefer the short one | 15:03 |
| elodilles | we have these two plans: https://review.opendev.org/q/topic:antelope-schedule-plan | 15:03 |
| elodilles | and yes, as ttx says 24w seems to be the winner | 15:03 |
| elodilles | and gmann also prefers the 24w so this is TC perspective as well we can say :) | 15:04 |
| ttx | and we really should make one official at this point | 15:04 |
| gmann | +1 | 15:04 |
| elodilles | ttx: do we need to do anything else beyond merging the schedule? | 15:05 |
| ttx | no | 15:05 |
| ttx | I'll +2 the one I prefer | 15:05 |
| elodilles | #agreed to accept & merge the 24w schedule | 15:05 |
| ttx | We'll likely want to fix a few things but i would merge this as-is | 15:06 |
| ttx | and fix extra things after that | 15:06 |
| elodilles | yes, we can propose follow-ups | 15:06 |
| elodilles | ++ | 15:06 |
| elodilles | ttx hberaud please +2+w then the 24w after the meeting when you have time | 15:06 |
| elodilles | thanks in advance! | 15:06 |
| elodilles | \o/ | 15:06 |
| hberaud | sure | 15:07 |
| ttx | done | 15:07 |
| hberaud | done | 15:07 |
| elodilles | #topic Open Discussion | 15:07 |
| elodilles | thanks, both of you :) | 15:07 |
| elodilles | we ran out of time already, so say quickly if you have anything to raise :) | 15:08 |
| hberaud | nope | 15:08 |
| ttx | nope | 15:08 |
| elodilles | ok, then let's wrap up quickly | 15:08 |
| fungi | i'm about done creating the 2023.1/antelope cycle artifact signing key, should have changes for that up later today hopefully | 15:08 |
| fungi | to list it as pending | 15:09 |
| elodilles | fungi: ack, thanks, wanted to ping you with that after the meeting o:) | 15:09 |
| elodilles | cool, let's finish then! thanks for participating! o/ | 15:09 |
| hberaud | elodilles: thanks! | 15:09 |
| elodilles | #endmeeting | 15:09 |
| opendevmeet | Meeting ended Fri Sep 2 15:09:47 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:09 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-09-02-14.01.html | 15:09 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-09-02-14.01.txt | 15:09 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-09-02-14.01.log.html | 15:09 |
| elodilles | hberaud: thanks too! | 15:09 |
| ttx | thanks elodilles ! | 15:10 |
| elodilles | oh, one thing we could have mentioned is the team's leadership model change to DPL :S | 15:10 |
| elodilles | maybe next time if we don't forget it... | 15:10 |
| ttx | consider ourselves warned! | 15:11 |
| elodilles | i hope everyone is OK with it | 15:11 |
| elodilles | :) | 15:11 |
| ttx | I think one change will be tat we'll add a "Chair:" line for every meeting so that it rotates a bit more | 15:11 |
| elodilles | ttx: yepp, that's a good idea | 15:11 |
| ttx | although I'll say that elodilles is really good at it | 15:12 |
| ttx | I'm sure you will appreciate a bit of relief there | 15:12 |
| *** dviroel is now known as dviroel|lunch | 15:13 | |
| elodilles | yes, it will be good to rotate as I'm not the best at keeping the time limits (like today :D) | 15:14 |
| elodilles | sorry for that o:) | 15:14 |
| opendevreview | Merged openstack/releases master: Proposed release schedule for 2023.1 Antelope (24w) https://review.opendev.org/c/openstack/releases/+/852741 | 15:14 |
| opendevreview | Gregory Thiemonge proposed openstack/releases master: Release final python-octaviaclient for Zed https://review.opendev.org/c/openstack/releases/+/855675 | 15:37 |
| opendevreview | Elod Illes proposed openstack/releases master: Move Cycle Highlights task to R-4 https://review.opendev.org/c/openstack/releases/+/855682 | 16:03 |
| *** dviroel|lunch is now known as dviroel | 16:41 | |
| opendevreview | Carlos Eduardo proposed openstack/releases master: Zed cycle highlights for Manila https://review.opendev.org/c/openstack/releases/+/855695 | 18:19 |
| *** dviroel is now known as dviroel|out | 20:56 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!