| opendevreview | Merged openstack/releases master: Release taskflow 6.1.1 https://review.opendev.org/c/openstack/releases/+/975761 | 11:19 |
|---|---|---|
| ttx | o/ | 14:00 |
| elodilles | o/ | 14:00 |
| ttx | #startmeeting releaseteam | 14:00 |
| opendevmeet | Meeting started Fri Feb 6 14:00:24 2026 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'releaseteam' | 14:00 |
| PavloKostianov[m] | o/ | 14:00 |
| ttx | Ping list: release-team elod | 14:00 |
| ttx | Our agenda is at: | 14:00 |
| ttx | #link https://etherpad.opendev.org/p/gazpacho-relmgt-tracking#L246 | 14:00 |
| elodilles | o/ | 14:01 |
| ttx | #topic Review R-8 week task completion | 14:01 |
| ttx | - Make sure the next development series name has been added to the data/series_status.yaml file. (elod) | 14:01 |
| elodilles | (elod) done, 2026.2 Hibiscus proposed release schedule patch has merged | 14:02 |
| ttx | - Send weekly email (ttx) | 14:03 |
| ttx | Will do after meeting! | 14:03 |
| elodilles | +1 | 14:03 |
| ttx | #topic Assign R-7 week tasks | 14:03 |
| ttx | all assigned! | 14:03 |
| elodilles | yepp | 14:03 |
| ttx | #topic Review weekly countdown email | 14:03 |
| elodilles | still not that many tasks | 14:03 |
| ttx | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:03 |
| * elodilles clicks | 14:04 | |
| ttx | For RC1 deadline and final-RC deadline I set the date to the Fridays, since technically it is a "week" | 14:04 |
| ttx | but I know we have been going back and forth on that | 14:04 |
| elodilles | yeah | 14:06 |
| ttx | ok let's keep it that way then | 14:06 |
| fungi | for cycle statistics i've been going thursday to thursday of rc1 week, for a rough approximation of when most stable branches are created, but making friday the deadline doesn't really change that | 14:06 |
| ttx | ah good point | 14:07 |
| * ttx moves to all Thursdays | 14:07 | |
| fungi | in part because the release team normally avoids approving non-emergency changes on fridays | 14:08 |
| elodilles | final rc deadline should be March 26th, am i wrong? | 14:08 |
| elodilles | in the mail it is March 19th | 14:08 |
| elodilles | but i think that is not correct | 14:09 |
| ttx | checking | 14:09 |
| ttx | nice catch! | 14:09 |
| ttx | anything else? | 14:10 |
| elodilles | i don't see any other issue | 14:11 |
| elodilles | LGTM | 14:11 |
| ttx | ok will send shortly after meeting | 14:11 |
| elodilles | +1 | 14:11 |
| ttx | #topic Open Discussion | 14:11 |
| ttx | Looks like something slipped past tests and reviews | 14:12 |
| ttx | Gazpacho M2 release was tagged 31.0.0.0b2 while Flamingo was 31.0.0, so after | 14:12 |
| elodilles | /o\ | 14:12 |
| ttx | So to answer rosmaita 's questions... | 14:13 |
| ttx | Yes it should have been 32.0.0.0b2 | 14:13 |
| rosmaita | ok | 14:13 |
| ttx | How could it happen? I'm looking at the test that should have failed... | 14:13 |
| elodilles | maybe not all cases are covered in case of beta :/ | 14:14 |
| rosmaita | what i noticed was the last beta was 30.0.0.0b2, we didn't have one in flamingo | 14:14 |
| elodilles | since there wasn't any 31.0.0.0b2 in Flamingo, there were no overlap | 14:14 |
| elodilles | yepp | 14:14 |
| fungi | yeah, but the version rolled backwards | 14:14 |
| rosmaita | yeah, so i guess that was a weird case | 14:15 |
| * ttx deepdives into validation code | 14:15 | |
| ttx | please hold :) | 14:15 |
| ttx | (or beat me to it) | 14:15 |
| fungi | (31.0.0.0b2 tagged after 31.0.0 even though 31.0.0.0b2 sorts before 31.0.0) | 14:15 |
| fungi | which repository was this in? | 14:16 |
| ttx | Looks like it should have failed https://opendev.org/openstack/releases/src/branch/master/openstack_releases/cmds/validate.py#L315 | 14:17 |
| rosmaita | fungi: glance | 14:17 |
| fungi | aha | 14:17 |
| ttx | That was for openstack/glance, release requested in openstack/releases | 14:17 |
| ttx | oh | 14:18 |
| ttx | maybe it does not test the progression from last series to current, only progression in the same series? | 14:18 |
| rosmaita | that seems to be the case for that function | 14:20 |
| ttx | surprised it would not have failed earlier if that was the case | 14:21 |
| ttx | ok so we have a hole in our validate testing | 14:23 |
| ttx | First priority is... what can we do about it | 14:23 |
| rosmaita | well, i think since 31.0.0 has been released, no one in their right mind would use the 31 beta | 14:24 |
| fungi | augment the `len(releases) == 1` case to check the last release in the previous series? would require loading that in though | 14:24 |
| ttx | yeah, I don't think it's an issue really, but we might want to clean up | 14:24 |
| ttx | fungi: yes I'm under the impression we actually do not look at the context, so unless you pick an existing tag it just passes | 14:25 |
| elodilles | maybe we could re-tag that hash with 32.0.0.0b2? | 14:26 |
| ttx | need to pay specvial attention to those "first in series" releases then | 14:26 |
| ttx | elodilles: yes that would be a good idea | 14:26 |
| fungi | right, it also doesn't guarantee version numbers go forward, just that e.g. you don't tag a beta after rc | 14:26 |
| elodilles | we usually don't delete tags, that are already applied. the question how much confusion that could cause. | 14:26 |
| ttx | that would clean up the deliverable file, at least | 14:26 |
| rosmaita | this is interesting: https://pypi.org/project/glance/#history | 14:27 |
| ttx | lol | 14:27 |
| elodilles | well, and our validator might catch THAT case when we try to re-tag a hash, so it might not work o:) | 14:27 |
| fungi | i wouldn't worry about the existence of the stray beta tag, pip installing that only happens if the version number is explicitly requested or `--pre` is specified and it's the most recent version number | 14:27 |
| ttx | OK let's just fix the deliverable file, tagging 32.0.0.0b2 instead | 14:28 |
| elodilles | can we mark 31.0.0.0b2 in pypi as 'yanked' or something? | 14:28 |
| ttx | that won;t remove the old one but we can leave with it | 14:28 |
| ttx | live* | 14:28 |
| fungi | i can yank it, which causes it not to appear in the index, but doesn't stop it from being installable | 14:28 |
| ttx | that's ok | 14:29 |
| elodilles | fungi: but as you said, pip won't pick it up anyway | 14:29 |
| fungi | but it'll still be in the list of git tags regardless | 14:29 |
| elodilles | fungi: so probably that's okay, and if someone wonders then they can see that it is yanked on pypi, right? | 14:29 |
| fungi | right, someone would need a very unusual set of circumstances to end up with it installed even now | 14:29 |
| fungi | like `pip install --pre glance<31` | 14:30 |
| rosmaita | yeah, because i guess --pre would get you the rc1 release? | 14:30 |
| fungi | oh, right | 14:30 |
| fungi | like `pip install --pre glance<31.0.0.0rc1` then | 14:30 |
| fungi | in practice it won't ever happen | 14:31 |
| opendevreview | Thierry Carrez proposed openstack/releases master: Re-release glance gazpacho-2 as 32.0.0.0b2 https://review.opendev.org/c/openstack/releases/+/975911 | 14:31 |
| ttx | that ^ and yanking the file from Pypi | 14:31 |
| ttx | does that sound ok as mitigation? | 14:32 |
| fungi | i'll mark it yanked on pypi in a few minutes when i break out the mfa for that account | 14:32 |
| ttx | Now we need to avoid that in the future, but I'm not sure the validate framework can easily test for that | 14:33 |
| rosmaita | i think that sounds good ... so the 31.0.0.0b2 tag will still be there, but won't be considered a release because it's not in the deliverables glance.yaml file? | 14:33 |
| ttx | since it basically looks at files in isolation afaict | 14:33 |
| elodilles | ttx: LGTM, but let's wait if validator likes it as well | 14:33 |
| ttx | rosmaita: yes, won;t be listed in the releases page | 14:33 |
| rosmaita | that works for me | 14:33 |
| ttx | \o/ | 14:34 |
| elodilles | with running validator locally it passed me | 14:34 |
| elodilles | so should be fine then | 14:34 |
| ttx | I wonder how many more we have fumbled in the past, but never noticed | 14:34 |
| elodilles | hope the post jobs are doing the tagging as well o:) | 14:34 |
| ttx | after all those years I thought the validator was infaillible | 14:35 |
| rosmaita | :D | 14:35 |
| ttx | I'll list it under "things to change" so that we know we have to work on it. But I'll likely not be able to find time to fix it myself | 14:37 |
| elodilles | even list-changes job shows the latest (highest) version, so i somehow missed that too :( but yeah, i thought validator to be catching this :/ | 14:37 |
| elodilles | ttx: +1 | 14:37 |
| elodilles | (it's strange that i think we should have a log message 'checking progression from {} to {}' at the 'Pre-release versions [..]' test, but there isn't...) | 14:38 |
| fungi | basically two holes: doesn't check against the prior series at start of a new one, and doesn't check that version numbers roll forward | 14:40 |
| ttx | It looks like all validation is within the context of the changed file only, so we only rely on tag collision to test numbers between series | 14:40 |
| ttx | rosmaita: good that you caught that one before the end release :)) | 14:41 |
| rosmaita | ttx: elodilles: fungi: thanks for taking care of this so quickly | 14:41 |
| ttx | would have been fun times around rc1 | 14:41 |
| elodilles | yeah, we would have been quite surprised at rc1 release o:) | 14:42 |
| rosmaita | it was just luck, i was looking at the latest tags for the maintained branches, and that looked weird | 14:42 |
| fungi | good eye | 14:43 |
| ttx | meanwhile we should probably pay extra attention to first releases in a series, especially when not autogenerated | 14:43 |
| elodilles | +1 | 14:43 |
| ttx | (we tend to avoid that with generated patches which actually take previous releases context into account) | 14:44 |
| fungi | checking that versions roll forward is relatively trivial if you have a proper pep 440 version sort (e.g. from the packaging library) | 14:44 |
| fungi | but this also needed to check outside the current series | 14:44 |
| ttx | I mean, who does write those by hand in 2026? :) | 14:46 |
| ttx | OK anything else to discuss? | 14:46 |
| elodilles | - | 14:47 |
| elodilles | did we lost ttx ? | 14:59 |
| ttx | oops | 15:00 |
| ttx | #endmeeting | 15:00 |
| opendevmeet | Meeting ended Fri Feb 6 15:00:56 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-02-06-14.00.html | 15:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-02-06-14.00.txt | 15:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-02-06-14.00.log.html | 15:00 |
| elodilles | :) | 15:01 |
| elodilles | thanks ttx o/ | 15:01 |
| ttx | sorry I thought I had closed it :) | 15:01 |
| fungi | okay, glance 31.0.0.0b2 has been yanked from pypi now | 15:25 |
| elodilles | thanks o/ | 15:29 |
| -opendevstatus- NOTICE: Gerrit on review.opendev.org will experience a short outage while we upgrade it to 3.11.8 | 17:50 | |
| *** gmaan is now known as gmaan_afk | 22:46 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!