| opendevreview | Merged openstack/releases master: Release manila RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979547 | 07:11 |
|---|---|---|
| elodilles | release-team: it seems that there is some kind of a network issue (towards pypi? O.o) again. we have new release-job-failures messages: https://lists.openstack.org/archives/list/release-job-failures@lists.openstack.org/thread/EMRPJIUZ73PSUPTNVTZVGTRF5ZP72RPZ/ | 07:32 |
| mnasiadka | Bad request, huh | 08:23 |
| opendevreview | Merged openstack/releases master: Release nova RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979589 | 10:09 |
| opendevreview | Merged openstack/releases master: Release tacker-horizon RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979607 | 11:00 |
| opendevreview | Merged openstack/releases master: Release watcher-dashboard RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979622 | 11:51 |
| opendevreview | Merged openstack/releases master: Release watcher RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979623 | 11:51 |
| opendevreview | Merged openstack/releases master: 2026.1 Gazpacho branch cut for devstack plugins https://review.opendev.org/c/openstack/releases/+/979487 | 11:55 |
| elodilles | reminder: weekly meeting in ~30 mins | 13:30 |
| fungi | the manila rc1 upload failure could potentially be the result of bad package metadata too. since it didn't successfully upload to pypi i'll reenqueue | 13:43 |
| fungi | the "network is unreachable" exception from tox on publish-tox-docs-releases is also hard to tell what happened, but the next build of that job should get the site caught up so less urgent | 13:45 |
| elodilles | thanks fungi for checking the failures | 13:48 |
| elodilles | let's see if manila rc1 is getting uploaded or no | 13:48 |
| elodilles | t | 13:48 |
| fungi | yeah, manila rc1 is back in the pre-release pipeline now | 13:48 |
| fungi | if it fails a second time, i'm probably going to need to hand-build a release for it and try to upload it manually to test.pypi.org | 13:49 |
| fungi | so that i can do `--verbose` and get more detail back from twine | 13:49 |
| elodilles | and it failed :/ | 13:56 |
| fungi | yeah, same error again, so i suspect manila has added something odd to their packaging, like an invalid trove classifier | 13:56 |
| elodilles | it's highly probable now that all the projects are moving towards pyproject.toml from setup.py | 13:56 |
| fungi | odds are i'm going to find that rc1 is unuploadable so we need to plan for an rc2 to correct whatever it is i turn up | 13:56 |
| fungi | i guess if this happens a lot, we can look at having the job run twine in verbose mode so we don't have to manually troubleshoot, but i need to see if it's safe and doesn't echo the upload key or something first | 13:57 |
| frickler | we could also do a release-test release to check whether it might be a general issue? | 13:59 |
| elodilles | yepp | 13:59 |
| elodilles | it can be tested maybe towards testpypi repo | 14:00 |
| elodilles | i mean twine upload | 14:00 |
| elodilles | frickler: i don't think so, i did release nova in the meantime | 14:00 |
| elodilles | anyway | 14:00 |
| elodilles | it's meeting time | 14:00 |
| ttx | o/ | 14:00 |
| elodilles | #startmeeting releaseteam | 14:01 |
| opendevmeet | Meeting started Fri Mar 13 14:01:02 2026 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 | #link https://etherpad.opendev.org/p/gazpacho-relmgt-tracking | 14:01 |
| elodilles | we are at waaaay at the bottom, at line 356 | 14:01 |
| elodilles | o/ | 14:01 |
| elodilles | let's start with the topics! | 14:02 |
| elodilles | #topic Review R-3 week task completion | 14:02 |
| elodilles | 1st: | 14:02 |
| elodilles | Process any remaining library branching exception (all) | 14:02 |
| elodilles | https://review.opendev.org/c/openstack/releases/+/978401 | 14:03 |
| elodilles | this was the only one ^^^ and it merged | 14:03 |
| elodilles | so libraries have branched perfectly \o/ | 14:03 |
| fungi | awesome | 14:04 |
| ttx | \o/ | 14:04 |
| elodilles | 2nd: | 14:04 |
| elodilles | On Monday, generate release requests for all deliverables that do not have a suitable candidate yet: (elod) | 14:04 |
| elodilles | Branch devstack-plugin-* deliverables. | 14:04 |
| elodilles | https://review.opendev.org/c/openstack/releases/+/979487 | 14:04 |
| elodilles | approved & merged. | 14:04 |
| elodilles | cycle-with-intermediary deliverables. | 14:05 |
| elodilles | 2 deliverables are waiting for release: | 14:05 |
| elodilles | bifrost: https://review.opendev.org/c/openstack/releases/+/978453 | 14:05 |
| elodilles | horizon: https://review.opendev.org/c/openstack/releases/+/979473 | 14:05 |
| elodilles | both merged | 14:05 |
| elodilles | cycle-with-rc that are not trailing deliverables and that have not done a RC1 yet | 14:06 |
| elodilles | https://review.opendev.org/q/topic:gazpacho-rc1-deadline | 14:06 |
| elodilles | so | 14:06 |
| elodilles | more than half of them were merged ^^^ | 14:06 |
| elodilles | the rest is waiting for the force-merge | 14:06 |
| elodilles | according to the process, this is the day we have to merge them | 14:07 |
| ttx | a couple of -1s though | 14:07 |
| elodilles | yepp, for those we can wait a bit more | 14:07 |
| ttx | Let's do a reminder today that they will be merged on Monday unless a -1 is posted | 14:08 |
| elodilles | ACK | 14:08 |
| elodilles | let's do that | 14:08 |
| ttx | I can do the force-merge on Monday | 14:08 |
| ttx | I'll add a task | 14:08 |
| elodilles | thanks! | 14:09 |
| ttx | can you post the reminder today? | 14:09 |
| elodilles | and actually that was all about tasks for this week (weekly mail review will come later) | 14:09 |
| elodilles | ttx: sure thing! | 14:10 |
| elodilles | ttx: maybe we can highlight it in the weekly mail | 14:10 |
| elodilles | let's move on to the 2nd topic | 14:10 |
| elodilles | #topic Assign R-2 week tasks | 14:10 |
| ttx | I prefer the comment on the reviews, so that we do not teach everyone else to wait until the last minute and go beyond deadlines | 14:10 |
| elodilles | ah, i see, | 14:11 |
| elodilles | i can do that as well after the meeting | 14:11 |
| elodilles | i'll comment to all the open patches | 14:11 |
| elodilles | a gentle reminder | 14:11 |
| elodilles | okay, meanwhile, i've added my name to the tasks without owner | 14:12 |
| elodilles | #topic Review weekly countdown email | 14:13 |
| elodilles | https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:13 |
| elodilles | please review ^^^ | 14:13 |
| fungi | lgtm | 14:15 |
| ttx | lgtm | 14:15 |
| elodilles | thanks o/ will send it later today | 14:16 |
| elodilles | #topic Open Discussion | 14:16 |
| elodilles | i've added here some things that maybe worth some words | 14:17 |
| elodilles | (elod) Django version bump / RFE - https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/H67NORC72ZELFUPBGFWUXVAKGMCK6TUU/ | 14:17 |
| elodilles | it's more like a Requirements Team topic, but important for us, too, i think | 14:18 |
| ttx | yeah... | 14:18 |
| fungi | yes, my point in that thread is that test jobs and requirements are treating horizon as a library, but we're releasing it on a service schedule | 14:19 |
| elodilles | yes, though this is a long and not new story i think :/ | 14:19 |
| fungi | so there are several obvious solutions, depending on who ends up solving it | 14:19 |
| elodilles | i mean, i have some vague memories about similar discussions in the past and the result was to add horizon in the upper constraints | 14:20 |
| fungi | given the limited developer resources of the horizon team today, i have serious doubts they're going to find the bandwidth to fix their testing design, much less split out a separate horizon-lib like neutron did (that took the neutron team years to untangle) | 14:21 |
| fungi | if they could do either of those things, they would have done so long before now | 14:21 |
| elodilles | and as someone mentioned - maybe not on the ML thread - the problem is that the works needs to be done in the horizon plugins, but there are no active maintaining around those repos | 14:21 |
| elodilles | fungi: i have the same feeling | 14:21 |
| ttx | and the more we discuss, the more painful the late upgrade is | 14:22 |
| fungi | so i was wondering if there are logistical problems with just requiring them to release at the library deadline | 14:22 |
| ttx | I'm comfortable with a 4.2.29 bump at this point, but not the 5.x one | 14:22 |
| elodilles | ttx: i agree | 14:22 |
| fungi | as i pointed out in the discussion and on the release change, even the 4.2.29 increase is unnecessary/unwarranted | 14:23 |
| ttx | yeah, but I'd be ok with it | 14:23 |
| fungi | we freeze requirements for stable testing, and there are going to be plenty more cves in the things in the constraints list for stable/2026.1 soon anyway which we won't address | 14:24 |
| ttx | I'm also fine not bumping anything ftr | 14:24 |
| ttx | I'm not sure we should be the one making the call between the two safe-enough options | 14:25 |
| fungi | but ultimately it's up to the requirements team, so i agree updating constraints for django from 4.2.28 to 4.2.29 is unlikely to be disruptive | 14:25 |
| tmazur | Hi elodilles, could we please have this one merged: https://review.opendev.org/c/openstack/releases/+/979941 | 14:25 |
| ttx | we are just here to flag that the third option is just very risky at this point | 14:26 |
| tmazur | To release RC1 working with Django 5.2, even if we do not update Django in Gazpacho | 14:26 |
| elodilles | yeah, we are late in the cycle for version bumps. i can accept the 4.2.29 bump as an RFE though as it *should* not introduce any incompatibility (like 5.2), but i'm not a Requirements expert o:) | 14:26 |
| tmazur | We're agreed to not bump it to 5.2 now, yes :) But 4.2.29 would be nice to have | 14:27 |
| elodilles | hi tmazur we are just discussing this :) | 14:27 |
| elodilles | though i don't think we should release horizon 26.0.0 now | 14:28 |
| tmazur | I'm talking about this one: https://review.opendev.org/c/openstack/releases/+/979941 -- a release including fixes that make Horizon work with Django 5.2 | 14:28 |
| tmazur | It's not bumping anything, just fixing Django 5.2 job | 14:29 |
| elodilles | hmm. so you mean that 26.0.0 does not require Django 5.2, but it is compatible with it? | 14:29 |
| tmazur | Yes | 14:29 |
| elodilles | ahh, i see | 14:29 |
| fungi | tmazur: and then what would be released on release day? horizon 27.0.0? | 14:29 |
| tmazur | 26.0.0 hopefully | 14:30 |
| tmazur | If we have it merged | 14:30 |
| fungi | then it's set for the wrong deliverable type | 14:30 |
| elodilles | fungi: horizon is cycle-with-intermediary, so it will be what we release now | 14:30 |
| tmazur | Could you please point me what is wrong exactly? I'm a bit confused | 14:31 |
| fungi | i didn't realize that was allowed during the rc period | 14:31 |
| elodilles | fungi: the deadline for horizon was last week, now we are talking about exceptions o:) | 14:32 |
| fungi | but if it's being released ahead of the coordinated release in order to be used as a dependency for other deliverables, that doesn't really give enough time for requirements to settle out, and runs a significant risk of introducing regressions | 14:32 |
| fungi | if it's being used as a library by other deliverables, cycle-with-intermediary doesn't sufficiently restrict final releases to the library deadline where we expect to have time to do those other follow-on activities safely | 14:33 |
| tmazur | So the patch for 26.0.0 doesn't need any changes in requirements. It just includes fixes to make Horizon work with both Django 5.2 and 4.2 | 14:33 |
| elodilles | fungi: if i understand correctly what tmazur says, then we have 2 patches in horizon now that handles some incompatibilites for Django 5.2, but it's not some full refactor. at least i hope so | 14:34 |
| * elodilles is checking the release job log: https://1776cef0547733fd8e91-e208a545991c854bd1a90a063fbc0070.ssl.cf5.rackcdn.com/openstack/d181604d18d847bdadecea8a41c8afd7/tox/list-changes/list-changes-results.log | 14:34 | |
| tmazur | Even if we're not bumping to 4.2.29, 26.0.0 will work fine | 14:34 |
| fungi | so the idea is to keep `horizon===25.6.0` in upper-constraints.txt for stable/2026.1 after releasing 26.0.0? | 14:35 |
| elodilles | first of all, if i'm not mistaken this is not a 26.0.0 release, | 14:35 |
| elodilles | rather 25.6.1, or at most 25.7.0 | 14:35 |
| tmazur | Major version is confusing probably. It was done in hope of having Django 5.2 in requirements | 14:36 |
| elodilles | then, as an exception - if we allow this exception - the upper-constraints.txt needs to be updated with 'horizon===25.6.1' or something (django still kept as 4.2.x) | 14:37 |
| elodilles | so this is my understanding | 14:37 |
| tmazur | Will it be ok to rename it now to say 25.7.0, so we can release and then update horizon===25.7.0 in upper-constraints.txt for stable/2026.1 ? | 14:38 |
| fungi | yeah, that's what i was asking, so "the patch for 26.0.0 doesn't need any changes in requirements" didn't make sense to me | 14:38 |
| tmazur | fungi, my apologies, I was only talking about Django updates in requirements | 14:38 |
| fungi | okay, that solves my confusion, thanks | 14:39 |
| opendevreview | Tatiana Ovchinnikova proposed openstack/releases master: Release Horizon 25.7.0 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979941 | 14:40 |
| elodilles | tmazur: so you say these 2 patches are both compatible with 4.2 and not risky to include now -> https://zuul.opendev.org/t/openstack/build/d181604d18d847bdadecea8a41c8afd7/log/tox/list-changes/list-changes-results.log#601-602 | 14:41 |
| tmazur | elodilles, we have horizon-tox-python3-django42 and horizon-tox-python3-django52 jobs, and they both are passing | 14:42 |
| elodilles | if that's OK and horizon team is confident in it, then i'm OK with the 25.7.0 release with that content | 14:42 |
| elodilles | ttx frickler fungi : what do you think? | 14:42 |
| elodilles | tmazur: sounds good | 14:42 |
| tmazur | Thank you! | 14:42 |
| elodilles | ttx frickler fungi ? | 14:43 |
| ttx | oops sorry | 14:44 |
| fungi | if the idea is that this is the last horizon release of 2026.1 then i guess we should go ahead with it, but it really does seem like we shouldn't be doing releases this late for anything listed in upper-constraints.txt if we can help it, that's what we have the library release deadline to solve | 14:44 |
| ttx | I'm ok with it | 14:44 |
| ttx | but yes, that should be considered an exception | 14:45 |
| fungi | and cycle-with-intermediary isn't really enough of a safeguard for listiong a deliverable in constraints | 14:45 |
| fungi | so probably a ptg discussion, but i feel like if it's in the constraints list it needs to be released on a library schedule | 14:46 |
| fungi | so that we avoid this problem in future cycles | 14:46 |
| elodilles | fungi: we have a task in the process for R-4 (last week) to release all cycle-with-intermediary projects, type other, service, ... | 14:47 |
| elodilles | fungi: so it's "just" one week delay compared to that | 14:48 |
| fungi | yes, though i think the others aren't in the constraints list? | 14:48 |
| fungi | if any are, they should probably be switched to library as well | 14:48 |
| elodilles | fungi: yes, and you are right, maybe if we keep horizon in the constraint list, then its final release should be moved forward in the schedule in the future | 14:49 |
| fungi | mainly reasoning that the week before rc is still very, very late because that's the requirements freeze, so any updates being made for deliverables at that point are likely to become an rfe automatically | 14:50 |
| fungi | basically schedule-wise we shouldn't have release deadlines for things in requirements that fall after requirements has frozen | 14:51 |
| ttx | I'll need to jump to another call in 2 min | 14:53 |
| elodilles | i think here we have 2 different stories: the django 5.2 bump, that is clearly waaay over the schedule. that is clear. the other thing is the horizon final release, which is less of an issue imho, as horizon is not really a library, even though we need to handle it for plugins sake (and that is a long story afaik) | 14:53 |
| ttx | I'm fine with anything except a 5.2 bump :) | 14:54 |
| fungi | yeah, i don't want to hold up the release change, i think we can discuss cross-over policy between requirements and releases at the ptg | 14:54 |
| elodilles | okay, so if i sense it right, then a bit reluctant YES is the answer for 25.7.0, and we can proceed with that, but further discussions can be followed at the PTG | 14:55 |
| fungi | i just think we proably need some policies that better coordinate assumptions baked into the schedule | 14:55 |
| elodilles | #agreed accept 25.7.0 horizon release as an exception - RFE Django 5.2 version bump is out of question for now for this late in the cycle | 14:56 |
| elodilles | ^^^ is this OK? | 14:56 |
| zigo | 4.2.29 is ok ? | 14:57 |
| elodilles | zigo: it's more like a Req team question, | 14:57 |
| zigo | ok | 14:57 |
| elodilles | i'd think it's acceptable | 14:57 |
| elodilles | but i'm in Release team o:) | 14:57 |
| fungi | yes | 14:57 |
| elodilles | okay, i had another topic, but that's also something that can be discussed later | 14:58 |
| elodilles | so if nothing else important now, then we can close the meeting | 14:58 |
| elodilles | anyone, anything? | 14:58 |
| fungi | nothing here | 14:58 |
| elodilles | okay, then thanks folks for joining o/ let's end the meeting | 15:00 |
| elodilles | #endmeeting | 15:00 |
| opendevmeet | Meeting ended Fri Mar 13 15:00:04 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-03-13-14.01.html | 15:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-03-13-14.01.txt | 15:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-03-13-14.01.log.html | 15:00 |
| fungi | elodilles: on your remaining topic, that's probably worth bringing up with the tc as it's more governance-related anyway | 15:00 |
| fungi | i'm going to start trying to figure out what pypi/warehouse doesn't like about manila's packages now | 15:00 |
| zigo | Still missing: cinder, glance, heat, keystone... | 15:01 |
| zigo | I guest they all have a vaid reason for being late, though from my perspective, this is very painful. :( | 15:02 |
| elodilles | fungi: yeah, so i saw that we have multiple teams without 'release liaisons' added as reviewers. and at first i thought it's because of the election and the way we are removing PTLs from the governance/projects.yaml. but it turned out that it was only responsible for 1 team really o:) | 15:02 |
| elodilles | fungi: the other 2 were caused by wrong (replaced) email addresses | 15:02 |
| fungi | right, but also the outdated addresses are a governance topic anyway | 15:03 |
| elodilles | fungi: as the registered emails were not found in gerrit anymore o:) | 15:03 |
| elodilles | fungi: yes, probably right | 15:03 |
| fungi | which is especially odd since those have to be in gerrit for elections to happen | 15:03 |
| fungi | or are they liaisons not ptls? | 15:04 |
| elodilles | fungi: they were PTLs | 15:04 |
| elodilles | or DPTLs | 15:04 |
| elodilles | i'm not sure now | 15:04 |
| fungi | yeah, so maybe the problem is we don't have a forcing function to confirm liaison addresses match a gerrit account | 15:04 |
| elodilles | but maybe they were changed in gerrit just in the wrong timing | 15:05 |
| fungi | also possible | 15:05 |
| elodilles | zigo: yepp, some team reported final changes they require to land before they can confidently release their RC1, and some teams just haven't responded on the RC1 patch o/ | 15:06 |
| elodilles | :/ | 15:06 |
| elodilles | zigo: monday we'll force merge those that don't have response from their release liaisons | 15:08 |
| frickler | elodilles: with mnasiadka's response https://review.opendev.org/c/openstack/releases/+/979538 should be good to go? | 15:16 |
| opendevreview | Merged openstack/releases master: Release Horizon 25.7.0 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979941 | 15:25 |
| elodilles | frickler: ah, thanks, +2+W'd it | 15:36 |
| fungi | i should have wagered money! https://paste.opendev.org/show/b8lxdbsbdroYSVe6Qjwq/ confirms as i suspected, invalid trove classifier. i'll let the maintainers know to prioritize https://review.opendev.org/c/openstack/manila/+/980462 and then they'll need an rc2 once it merges | 15:36 |
| fungi | i'll backport it to stable/2026.1 as well | 15:37 |
| fungi | backport is https://review.opendev.org/c/openstack/manila/+/980463 | 15:38 |
| carloss | fungi: nice catch | 15:39 |
| carloss | I'll look into it and tag some reviewers as well | 15:39 |
| carloss | thanks for investigating and proposing the fix | 15:39 |
| fungi | thanks! | 15:39 |
| fungi | yw | 15:39 |
| fungi | the fix was trivial, the investigation took nearly an hour ;) | 15:40 |
| elodilles | yepp, nice catch, fungi o/ and thanks for the patch & backport! | 15:44 |
| fungi | manual upload testing is not easy, sadly | 15:46 |
| opendevreview | Merged openstack/releases master: Release magnum-ui RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979538 | 15:46 |
| fungi | and https://github.com/pypa/twine/issues/976 and other related issues have been around for years with little traction sadly | 15:47 |
| fungi | oh, actually maybe there is something there now... digging deeper | 15:48 |
| opendevreview | Merged openstack/releases master: Release heat-agents RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979530 | 15:54 |
| elodilles | i've checked now with AI agent as well, and it pointed out the same issue you found. nothing else. is there another issue? :-o | 15:55 |
| fungi | elodilles: no additional issues, i merely discovered that there's a new (experimental) pyproject.toml linter that checks all trove classifiers are valid | 15:56 |
| fungi | playing around with it now | 15:56 |
| elodilles | oh, awesome, that's something we should use for sure! | 15:56 |
| fungi | https://paste.opendev.org/show/bs7B6DSF7TkBb0f3QFbQ/ | 15:57 |
| fungi | sadly it doesn't seem to mention the bad string | 15:57 |
| clarkb | I guess twine check can't catch this at all regardless of where the bad string is because it is looking at the wheel and sdists not your packaging specifications? | 15:58 |
| fungi | okay, so -vv does mention it | 15:59 |
| fungi | https://paste.opendev.org/show/bwRVYXP8S0zZMQ0ehXL2/ | 15:59 |
| fungi | well, in theory twine could catch it, but that would require it add support for doing so | 16:00 |
| fungi | which the twine maintainers left as a wishlist issue basically, and people have made several half-attempts at | 16:00 |
| fungi | but instead it seems like a separate linter for the pyproject.toml file is a more direct solution (at least for metadata that's coming from there and not elsewhere) | 16:01 |
| fungi | having twine check the metadata in packages would still have been preferable because in the past there have been plenty of upload failures when someone put a wrong classifier in setup.cfg too | 16:03 |
| fungi | which validate-pyproject isn't going to catch, for obvious reasons | 16:03 |
| fungi | and given most of the package metadata churn now is going to be from projects moving things into pyproject.toml, maybe this is a "good enough" solution | 16:04 |
| fungi | tkajinam: sean-k-mooney: i recall the two of you have also been doing a lot of stuff around pyproject.toml migrations? do you have any opinion on where would be a good spot to shoehorn in a check like that? just add it to the tox linters/pep8 targets, or a separate job that only runs when that file is altered, or something else? | 16:12 |
| sean-k-mooney | reading back. you rasking about linigt pyproject.toml | 16:14 |
| sean-k-mooney | one approch woudl a pre-commit hook | 16:14 |
| fungi | yeah, needs to `pip install packaging validate-pyproject` (because packaging is apparently only an optional dependency for it), then invoke `validate-pyproject -vv pyproject.toml` and then nonzero exit means there's a problem | 16:14 |
| sean-k-mooney | with a local hook but we coudl also do it with tox or whatever | 16:14 |
| fungi | yeah, not all projects are using (or want to use) precommit, but for projects that are reliant on it i guess that would be a fine alternative | 16:15 |
| sean-k-mooney | ya so you coudl do that with a local hook or a tox target | 16:15 |
| fungi | i mostly worry that if we do it on a project-by-project basis it may not get rolled out consistently (or at all) | 16:15 |
| sean-k-mooney | i think most project woudl jsut includ it in the pep8 target if they have not adopted linters | 16:15 |
| tkajinam | yeah pep8 or pre-commit makes sense to me | 16:16 |
| sean-k-mooney | we might be able to do somethign via hacking i guess but stephenfin might have a better opipion | 16:16 |
| tkajinam | for a project already using pre-commit we can use pre-commit but for the others just add validate-pyproject command in tox (and add validate-pyproject to requirements) | 16:17 |
| fungi | oh, good point, i should have pinged him too | 16:17 |
| tkajinam | though it means we should update all projects to add the check | 16:17 |
| tkajinam | if we could add a new job just run that check and add it to base python job that may save that effort, though it increases CI resource consumption | 16:17 |
| fungi | right, my concern is the projects that don't know or bother to add that check are probably the ones more likely to also add mistakes that we then won't catch until we have a failed release upload | 16:17 |
| sean-k-mooney | fungi: by the way i was not really awre that "valid classifers" was a thing | 16:18 |
| fungi | whereas a separate job that we add to the default project-template in zuul could avoid that problem | 16:18 |
| sean-k-mooney | standard ones yes | 16:18 |
| sean-k-mooney | but vaild? | 16:18 |
| fungi | sean-k-mooney: right, most people aren't aware, but pypi has rejected "wrong" classifiers since at least a decade | 16:18 |
| fungi | it just only comes up at release upload time, so the project developers tend to not notice | 16:19 |
| sean-k-mooney | so we also have packaging jobs that run on each patch right | 16:20 |
| fungi | what i used to do (and what i did this time to find the problem in manila) was upload a build to test.pypi.org to make sure it was safe if i thought there could be something amiss | 16:20 |
| sean-k-mooney | we coudl run the check in that job | 16:20 |
| fungi | yes, running it as part of the release check is another option, catches it later and means more rounds for the project team to solve and request a different release, but at least it prevents us from tagging something that will never appear on pypi | 16:21 |
| sean-k-mooney | test-release-openstack | 16:21 |
| sean-k-mooney | i tired to user feature we coudl not ebcase fo old pakcaging os | 16:22 |
| sean-k-mooney | in https://review.opendev.org/c/openstack/cyborg/+/977887 | 16:22 |
| fungi | i agree we don't need to optimize for finding it before a release is requested since it comes up infrequently and the goal is still met | 16:22 |
| sean-k-mooney | and that blocked it so we coudl do it in that job | 16:22 |
| tkajinam | that makes sense | 16:22 |
| sean-k-mooney | right but that job already runs on every patch in check | 16:22 |
| sean-k-mooney | so we can jsut check it there if its quick to do so | 16:22 |
| tkajinam | https://opendev.org/openstack/project-config/src/branch/master/zuul.d/jobs.yaml#L50-L65 | 16:23 |
| fungi | oh, i see what you mean | 16:23 |
| fungi | i thought you meant run it in the job that performs release request validation | 16:23 |
| sean-k-mooney | that will stop us merging the invalide change in the first place | 16:24 |
| sean-k-mooney | no | 16:24 |
| fungi | yeah, that's actually a great spot | 16:24 |
| fungi | okay, i'll get something proposed for that | 16:24 |
| tkajinam | https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/project-templates.yaml#L129-L157 | 16:24 |
| tkajinam | yeah I assume all projects with python deliverables should have that publish-to-pypi job template already | 16:24 |
| fungi | correct | 16:24 |
| tkajinam | which runs test-release-openstack for any update in setup.* or pyproject.toml | 16:24 |
| sean-k-mooney | they do if they are offical and manged by the release team | 16:24 |
| fungi | and if they don't they're not uploading them to pypi | 16:25 |
| tkajinam | yeah | 16:25 |
| tkajinam | makes complete sense | 16:25 |
| fungi | so we probably care less about valid pyproject.toml files for repos that have one if they're not publishing a package to pypi anyway | 16:25 |
| stephenfin | fungi: I didn't have IRC open until now, but I agree with sean-k-mooney: this should be done in test-release-openstack | 16:25 |
| fungi | thanks for confirming! seems like we have consensus | 16:25 |
| fungi | working on that now before i get distracted by something else | 16:26 |
| opendevreview | Goutham Pacha Ravi proposed openstack/releases master: Release manila rc2 https://review.opendev.org/c/openstack/releases/+/980496 | 16:49 |
| gouthamr | ^ fungi thanks for the fix, ^ | 16:49 |
| fungi | remote: https://review.opendev.org/c/openstack/project-config/+/980500 Run validate-pyproject during package checks [NEW] | 17:28 |
| fungi | that and its depends-on should hopefully prevent similar problems in the future | 17:28 |
| opendevreview | Merged openstack/releases master: Release cloudkitty-dashboard RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979522 | 20:13 |
| opendevreview | Merged openstack/releases master: Release cloudkitty RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979523 | 20:14 |
| opendevreview | Merged openstack/releases master: Release glance RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979529 | 20:14 |
| opendevreview | Yasufumi Ogawa proposed openstack/releases master: Release tacker RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979609 | 23:59 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!