| frickler | interesting. nobody having noticed this over the years confirms my assumption that nobody actually cares about our signatures - which is also why I stopped signing the infra keys again | 06:38 |
|---|---|---|
| frickler | but weird that even the links for zed-eom are there, which was made much later than 2023.1 releases | 06:39 |
| opendevreview | Takashi Kajinami proposed openstack/releases master: Release python-observabilityclient 1.5.0 https://review.opendev.org/c/openstack/releases/+/1006698 | 10:30 |
| opendevreview | Elod Illes proposed openstack/releases master: Fix pgp links in deliverables page https://review.opendev.org/c/openstack/releases/+/1008444 | 12:00 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: Release os-vif 5.3.0 version https://review.opendev.org/c/openstack/releases/+/1008445 | 12:02 |
| elodilles | fungi frickler : a simple fix for the missing pgp links: https://review.opendev.org/c/openstack/releases/+/1008444 | 12:17 |
| elodilles | reminder: meeting in 5 mins | 13:55 |
| fungi | thanks elodilles! so i was on the right track about it being related to the alphabet wraparound, i was just sniffing in the wrong part of the code | 13:55 |
| elodilles | yepp | 13:55 |
| fungi | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_372/openstack/37280dc1d40f41a98fc44d1e7af99b00/docs/hibiscus/index.html#adjutant has links, so approving | 13:55 |
| elodilles | thanks o/ | 13:56 |
| fungi | frickler: i think some long-time consumers of the signatures have hard-coded the mapping to just add .asc to the tarball name, rather than relying on rendered hyperlinks, but i agree there's probably not a lot of use (and the signatures on git tags get checked more often) | 13:58 |
| elodilles | #startmeeting releaseteam | 14:00 |
| opendevmeet | Meeting started Fri Oct 2 14:00:05 2026 UTC and is due to finish in 60 minutes. The chair is elodilles. 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 |
| elodilles | Ping list: release-team | 14:00 |
| elodilles | #link https://etherpad.opendev.org/p/hibiscus-relmgt-tracking | 14:00 |
| elodilles | we are at line 422 | 14:00 |
| frickler | \o | 14:00 |
| elodilles | so basically at the bottom | 14:00 |
| elodilles | o/ | 14:00 |
| fungi | ahoy! | 14:00 |
| elodilles | okay, let's start the meeting | 14:01 |
| elodilles | #topic Review task completion | 14:02 |
| elodilles | this section should be short as the tasks were basically the release steps | 14:02 |
| fungi | and we marked through them all once completed | 14:02 |
| elodilles | exactly | 14:02 |
| fungi | i did merge the revert of the semaphore removal too | 14:03 |
| elodilles | any comment for the tasks or the release? | 14:03 |
| elodilles | fungi: ACK, i've just double checked that o:) | 14:03 |
| elodilles | thanks everyone for the work & help. we did succeed with the release \o/ | 14:04 |
| fungi | one of the smoothest on record | 14:05 |
| fungi | somehow we dodged ongoing pypi issues | 14:05 |
| elodilles | yepp, fortunately all went according to plans | 14:05 |
| elodilles | fungi: and that... yes... :S lucky us | 14:05 |
| elodilles | i hope the issue there will be permanently sorted out (if it hasn't been yet) | 14:06 |
| elodilles | to be honest i haven't checked since release day | 14:06 |
| elodilles | well, looking at it now they still have errors :( https://status.python.org/ | 14:07 |
| *** haleyb_ is now known as haleyb | 14:07 | |
| elodilles | anyway, let's move on | 14:07 |
| elodilles | #topic Assign cycle's 1st week tasks | 14:07 |
| elodilles | the tasks can be found on the new tracking etherpad: | 14:08 |
| elodilles | #link https://etherpad.opendev.org/p/indri-relmgt-tracking#L21 | 14:08 |
| elodilles | i've already started some of the tasks | 14:08 |
| elodilles | for example the tracking etherpad setup o:) | 14:08 |
| fungi | thanks! | 14:08 |
| elodilles | np | 14:09 |
| elodilles | note that it's not filled with tasks yet (only 1st week's tasks) | 14:09 |
| elodilles | especially as it will depend on the coming discussion | 14:09 |
| opendevreview | Merged openstack/releases master: Fix pgp links in deliverables page https://review.opendev.org/c/openstack/releases/+/1008444 | 14:10 |
| elodilles | thanks fungi, all tasks taken | 14:11 |
| elodilles | let's move on then | 14:11 |
| elodilles | there is no mail for this time | 14:11 |
| elodilles | so let's skip the mail review task | 14:12 |
| elodilles | #topic Open Discussion | 14:12 |
| frickler | does the "email PTLs directly" include DPLs? | 14:12 |
| elodilles | frickler: should be | 14:12 |
| elodilles | actually i think PTLs + DPLs + release liaisons | 14:12 |
| fungi | release liaisons presumably | 14:12 |
| fungi | yeah | 14:13 |
| elodilles | yes | 14:13 |
| frickler | ok, good | 14:13 |
| elodilles | +1 | 14:13 |
| fungi | could stand to update how it's phrased in the process doc | 14:13 |
| elodilles | okay, so one topic here | 14:13 |
| elodilles | stephenfin: ping | 14:13 |
| elodilles | (elod) Stephen's mail thread about branching openstack/requirements earlier | 14:13 |
| elodilles | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/65GQWCGJRQNCLIA3L3A5AXLVTOPGNZQ7/ | 14:13 |
| stephenfin | o/ | 14:14 |
| elodilles | please read the collected ideas and comments: | 14:14 |
| elodilles | #link https://etherpad.opendev.org/p/hibiscus-relmgt-tracking#L454 | 14:14 |
| elodilles | stephenfin: o/ | 14:14 |
| elodilles | stephenfin wrote a nice short summary + I've added my concerns o:) | 14:14 |
| stephenfin | oh, I hadn't seen those (or I'd have replied already) | 14:15 |
| fungi | i'm not opposed to the general idea. i'll note that the order we do thing in has been fine-tuned repeatedly over time and there's probably very good reasons to branch requirements when we do it, but my memory no longer holds the interdependencies that led us to the current sequence so i'm not sure what else may break | 14:15 |
| fungi | probably we won't know until we try it (maybe for several cycles) | 14:16 |
| elodilles | fungi: exactly, that's my feeling and experience too | 14:16 |
| frickler | there certainly are intricacies involving devstack, grenade, tempest, and how the jobs decide which branches to load where | 14:16 |
| stephenfin | my understanding is that the main reason that requirements branch so late is that it currently needs to happen just before the services branch | 14:16 |
| frickler | actually afterwards? | 14:17 |
| stephenfin | sorry, yes, just afterwards | 14:17 |
| elodilles | i do remember a couple of cases when the release team had to hold a retro about 'what went wrong and why during the release' regarding late merged library changes o:) | 14:17 |
| fungi | in order to be testable, or to keep dependencies from testing with a forked version of reqs that the services aren't using yet? | 14:17 |
| frickler | and how new-release updates get targeted to master vs. new-stable branches plays a role, too | 14:18 |
| elodilles | fungi: yes +1 | 14:18 |
| stephenfin | fungi: we currently only point to the stable u-c on stable branches | 14:18 |
| elodilles | frickler: and that, too | 14:19 |
| stephenfin | so if we branched requirements e.g. 3 weeks earlier, the services wouldn't use the branched version until they themselves get branched | 14:19 |
| fungi | yeah, until the services branch, the release is going to be tested with master branch versions of dependencies listed in requirements, regardless of whether requirements has a stable branch already, but our libs will have already branched and will test with the branched version of requirements if it exists | 14:19 |
| stephenfin | exactly | 14:19 |
| stephenfin | my proposal is to have services point to the branched version of requirements for X weeks until they are branched themselves | 14:20 |
| fungi | so even if we do branch requirements sooner, we have to keep it frozen in master | 14:20 |
| stephenfin | right, unless we can tell services to use the branched version for X week | 14:21 |
| fungi | oh, using branch-override in the zuul job definitions specifically for cycle-with-rc deliverables? | 14:21 |
| stephenfin | (this is not an issue for libraries since they already branch early) | 14:21 |
| stephenfin | that's an option. I hadn't considered that | 14:21 |
| fungi | how were you planning to make zuul supply the right checkout of requirements in jobs? | 14:22 |
| stephenfin | my proposal was to start add a new new generated patch to the list of patches produced by the `copy-release-tools-scripts` role | 14:22 |
| fungi | so that, e.g., depends-on to requirements changes still works | 14:22 |
| elodilles | so that means an u-c replace at R-5 in services' repos to stable/<new-release> and a reset to master at R-3 | 14:22 |
| stephenfin | when openstack/requirments patch, all serices get an auto-generated patch to point their u-c in tox.ini `stable/<next-release>` | 14:23 |
| stephenfin | s/patch/branches/ | 14:23 |
| fungi | zuul jobs don't use those redirects on the release site (or at least aren't supposed to) | 14:23 |
| stephenfin | when the services then branch, the tox.ini change gets undone and it points to master again | 14:23 |
| fungi | those are for local test environments on developer systems | 14:23 |
| frickler | tox.ini only affects unit tests, not devstack based tests | 14:23 |
| fungi | they get ignored in zuul context | 14:23 |
| fungi | that too | 14:24 |
| stephenfin | TIL | 14:24 |
| fungi | zuul jobs clone the requirements repo and checkout the necessary state, then tox or devstack consume the constraints file from the git checkout | 14:24 |
| fungi | that's how depends-on can test with not-yet-merged requirements changes, for example | 14:25 |
| stephenfin | I've proposed the change to the release tooling ending here https://review.opendev.org/c/openstack/project-config/+/1008294. It sounds like there would be more needed to make this work in a CI context (rather than local environment) though | 14:26 |
| stephenfin | that's good to know. I can go think about what that would look like and come back with a proposal | 14:26 |
| elodilles | hmmm. right. i also forgot that u-c is only/mostly used by unit tests and such, but not by all zuul jobs :X | 14:26 |
| stephenfin | before I do though, what I'm really looking for is some kind of agreement on whether we would persue this if I could get it working in a non-awful way | 14:27 |
| stephenfin | the ultimate goal is to have libraries and requirements branch at the same time (or very close together), and then find a way to have services respect the branched requirements until they themselves branch | 14:28 |
| frickler | adding two extra patches to every project also is no small thing, I think I would want to have this discussed at the TC level before committing to it | 14:28 |
| fungi | zuul does have the ability to override branch selection in jobs, but what you suggest will probably need a master-branch variant of all constraints-using jobs specific to cycle-with-rc deliverables which gets applied at requirements branching time and then unapplied after rc1 | 14:28 |
| frickler | and I think I would want to see a group of volunteers that are prepared to handle the possible fallout in term of possible CI issues | 14:29 |
| elodilles | as i said, i'm not fond of branching requirements earlier, but maybe i'm too conservative in that sense and i fear to much that we'll break more things o:) | 14:29 |
| stephenfin | this would allow development on libraries and clients to continue without undermining the stability of the release during the last few weeks of the cycle | 14:29 |
| frickler | that group likely would need to include at least one config-core and qa-core reviewer. and I don't want to include myself there | 14:30 |
| elodilles | my argument is that the development *can* be contineud during the freeze period as well, though i understand that today those patches can't land o:) | 14:30 |
| fungi | nothing will be consuming those master branch library versions during that timeframe though, and you won't be able to effectively cross-project exercise them with services that haven't branched | 14:30 |
| stephenfin | frickler: it is only 1 new commit since the change of TOX_CONSTRAINTS_FILE no longer needs to happen on `stable/<new-release>` (it already happened on master) | 14:30 |
| elodilles | fungi: +1 | 14:31 |
| elodilles | that's another fair point | 14:31 |
| frickler | stephenfin: if the patch is really just that, and nothing more is needed for devstack based tests per project | 14:31 |
| stephenfin | fungi: that depends on how it's implemented, no? A devstack job running on the library (rather than the service) would be using master everything | 14:32 |
| frickler | there may be many project specific jobs that may need specific tweaking, too | 14:32 |
| stephenfin | if there are, we'll figure that out. It's just code | 14:33 |
| fungi | stephenfin: and keep nova master working simultaneously with both stable/indri constraints and master constraints? | 14:33 |
| fungi | er, stable/2027.1 i mean | 14:33 |
| elodilles | :S | 14:33 |
| stephenfin | sure, why not | 14:34 |
| fungi | in order for post-branch oslo.messaging master versions targeting the 2027.2/j release cross-testable with not-yet-branched nova | 14:34 |
| stephenfin | if we make a change to oslo.messaging that requires nova changes before we merge it, then I think it's reasonable to say that should wait until nova is branched to make that change | 14:36 |
| stephenfin | not that that should happen unless nova has been lagging in addressing deprecation warnings | 14:36 |
| stephenfin | unless I'm misunderstanding your point? | 14:36 |
| frickler | thinking about this a bit more, I think this topic would need to become a TC approved community goal. and given the strained resources the community is having globally, I really doubt that that is worth the effort | 14:37 |
| elodilles | frickler: i agree :/ | 14:37 |
| fungi | i guess my main concern is that this is presented as branching requirements earlier, but it's actually more about not freezing library development. and yes, this isn't something just the release team needs to buy into, i agree it's a project-wide discussion to be had | 14:37 |
| stephenfin | library developement isn't freezing: it's just not releasing | 14:38 |
| stephenfin | so it's about reflecting reality and removing that roadblock | 14:38 |
| fungi | good point, we freeze releasing libraries from master | 14:38 |
| elodilles | given stephenfin 's original proposal, maybe a) can be done, but b) could be messy with lot of hacks rather than just a simple change... more after today's discussion | 14:39 |
| fungi | so from a cosy/benefit perspective, what is going to consume those newer library releases? | 14:40 |
| fungi | er, cost/benefit | 14:40 |
| fungi | obviously tagging releases of libraries on master is not a goal itself, something must be wanting to make use of them | 14:40 |
| stephenfin | SDK and OSC are my primary concerns | 14:41 |
| stephenfin | both of those exist half-in and half-out of the unified release, in so far as they are designed to work with a large range of openstack versions, past and present | 14:41 |
| stephenfin | *past, present and future | 14:41 |
| fungi | i wonder if we could re-scope the discussion to finding a way to not stop making new releases of openstackclient and openstacksdk, specificially | 14:42 |
| elodilles | note that the original idea of library freeze is not just release freeze, in my understanding, rather it's feature freeze, too. so that the code consolidates, bug fixes can land. if features land meanwhile, that could make bug fixing and backporting harder | 14:42 |
| fungi | or rather, to being able to release new versions of them that aren't stable branch versions | 14:42 |
| stephenfin | I'd be happy to do so, but I suspect the same issues will rear their heads | 14:43 |
| stephenfin | there is one other middleground here | 14:43 |
| stephenfin | my original proposal was simply to populate the deliverables files earlier, at the same time we start branching for clients and libraries | 14:44 |
| fungi | the incentive i see for openstackclient and openstacksdk is that they are user-facing tools not merely internal implementation details pulled out of and shared between our services | 14:45 |
| stephenfin | soneone (frickler?) noted that releasing stuff for $future series was of little value if we nothing wasn't consuming them and there was a chance that when requirements unfroze | 14:45 |
| stephenfin | ...that we would see a load of latent failures that had crept in over the last X weeks | 14:45 |
| fungi | but the same incentive is not there to be able to make new oslo.db releases from master that no service is using, for example | 14:45 |
| elodilles | that's OK, but probably we still can't release libraries from master until everything have branched. and then is my above point, that lib freeze is feature freeze as well | 14:45 |
| stephenfin | fungi: I'm broadly in agreement. While I'd prefer to be able to release an oslo library at anytime (particularly for those with use outside of OpenStack, like tooz), the SDK/OSC ones are definitely far more user-facing | 14:47 |
| stephenfin | but going back to the deliverables thing, is that idea of a failure with OSC creeping in during the time between requirements freeze and requirements re-opening actually a massive concern? Wouldn't that just put e.g. OSC and SDK in the same bucket as all the non-OpenStack deliverables? | 14:48 |
| fungi | historically we had similar challenges with all the "client libraries" because of being both end-user-facing but also utilized for backend service-to-service integration | 14:49 |
| stephenfin | put another way: could we keep releasing OSC and SDK releases during the X weeks between those two but simply not merge their respective requirements bumps until requirements unfroze? | 14:49 |
| stephenfin | fungi: yep, there was one issue with OSC in the past that I recall writing a rather lengthy to openstack-discuss about | 14:50 |
| stephenfin | ...though iirc, the actual issue happened before R-6 and we simply never merged the OSC bump in openstack/requirements (which had been failing) | 14:51 |
| fungi | from a workflow perspective, i think what we need is to not *propose* requirements bumps from master for already-branched deliverables, but we do still need to propose (and merge) stable branch releases for them to master requirements under the current model | 14:51 |
| stephenfin | that sounds doable | 14:53 |
| elodilles | fungi: and that we currently achive by not adding next-release deliverable files (i.e. not allowing releasing from master branch after branch cut) | 14:53 |
| fungi | so once stable/2027.1 exists for openstacksdk, stable/2027.1 tag of openstacksdk proposed to master requirements, master tag of openstacksdk not proposed to requirements at all | 14:53 |
| stephenfin | if dep branched and requirements not branched: skip patch bumping u-c for dep | 14:54 |
| stephenfin | elodilles: right, but that prevents us releasing entirely, which is the entire problem :) | 14:54 |
| elodilles | right | 14:55 |
| stephenfin | I'm suggesting rescoping this discussion to lets allow releasing SDK and OSC (at a minimum) but keep requirements frozen | 14:55 |
| fungi | end users still install latest openstacksdk from pypi or wherever, but openstack services won't use it until rc1 when they get stable/2027.1 branches themselves and we have some net-new task to sync master requirements for the deferred releases from that requirements freeze timeframe | 14:55 |
| stephenfin | yes | 14:55 |
| elodilles | okay. so that can be done by creating the deliverables/<next-release>/<osc/sdk>.yaml | 14:56 |
| fungi | that feels a lot more tractable as a solution, to me | 14:56 |
| elodilles | fungi: i agree | 14:56 |
| stephenfin | fungi: I would likely avoid a net new tasks, and instead suggest the auto-bump changes get a defacto -2 until requirements unfreezes | 14:57 |
| elodilles | that's something we can try | 14:57 |
| elodilles | stephenfin: +1 | 14:57 |
| stephenfin | which is what happens currently if you manually propose a change | 14:57 |
| fungi | yeah, something along those lines | 14:57 |
| elodilles | yes, it's something that we/requirements team can guard | 14:57 |
| stephenfin | (frickler and prometheanfire have -2d many of my patches over the years for this reason 😇) | 14:57 |
| fungi | i couldn't remember if the periodic autoproposals skipped dependencies we control | 14:57 |
| fungi | but if they're included, then yes that's already a solved problem | 14:58 |
| stephenfin | we get bot proposed patches for openstack requirements, which bump the single dep. all other deps are taken by the large update job which frickler has been chiefly shepherding for the past while | 14:59 |
| fungi | well, both are bot proposed | 14:59 |
| stephenfin | the only bit I'm not sure about is what happens if you don't merge one of the former. If there's a new release does that mean a new additional patch or an updated one | 15:00 |
| fungi | one is triggered by our releases on-demand including just what we tagged, the other a bulk proposal generated and refreshed periodically | 15:00 |
| stephenfin | if the former, we probably want to rework it to reuse the same change-id so we don't end up with X patches of which only one (the newest) is usable | 15:01 |
| stephenfin | I can look into that | 15:01 |
| fungi | and i couldn't remember if we filtered the things we release out of the bulk proposal changes, but if we don't then we get the eventual sync for the deferred updates for them that way | 15:01 |
| elodilles | given we ran out of time, what maybe we can agree: 1) populate next-release/ <osc/sdk>.yaml AFTER branching stable/<current-release> 2) allow OSC/SDK releasing from master 3) do not merge u-c bumps out of these releases | 15:01 |
| stephenfin | fungi: yeah I shouldn't have said bot proposed. They're both bot proposed but the latter has some human involvement | 15:01 |
| elodilles | is this OK ? ^^^ | 15:02 |
| fungi | elodilles: sgtm | 15:02 |
| stephenfin | wfm | 15:02 |
| elodilles | #agreed stephenfin's proposal: 1) populate next-release/ <osc/sdk>.yaml AFTER branching stable/<current-release> 2) allow OSC/SDK releasing from master 3) do not merge u-c bumps out of these releases | 15:02 |
| fungi | and if this works out we could consider it for other deliverables in the client libraries (but probably not general libraries) category if needed | 15:03 |
| stephenfin | thanks for the time. sorry that took so long but I hope it was useful to discuss this in detail | 15:03 |
| elodilles | fungi: +1 | 15:03 |
| fungi | stephenfin: it absolutely was, thanks for bringing it up! | 15:03 |
| elodilles | the discussion can be continued after the meeting, but if nothing else to say now, then i'll end the meeting o:) | 15:03 |
| elodilles | thanks stephenfin o/ | 15:03 |
| elodilles | okay, let's end now. thanks everyone for the participation o/ | 15:04 |
| fungi | thanks elodilles! | 15:04 |
| elodilles | #endmeeting | 15:05 |
| opendevmeet | Meeting ended Fri Oct 2 15:05:01 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:05 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-10-02-14.00.html | 15:05 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-10-02-14.00.txt | 15:05 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-10-02-14.00.log.html | 15:05 |
| fungi | and now that we shouldn't need adjustments to the schedule to support that use case, i guess we can move forward with normal cycle planning | 15:05 |
| elodilles | fungi: +1 | 15:06 |
| elodilles | i will do that :) | 15:06 |
| fungi | https://releases.openstack.org/hibiscus/index.html#adjutant has signature links now, thanks again elodilles!!! | 15:06 |
| frickler | sorry, was distracted by another discussion, but I'm not sure yet I would agree to 2) without further thinking about it | 15:08 |
| fungi | thankfully we still have months to think about potential problems with it before lib branching time | 15:09 |
| stephenfin | Yes. Plenty of time to figure out the tooling kinks also | 15:10 |
| elodilles | frickler: please do think about it. in my opinion we can try that and see if that is causing issues | 15:10 |
| stephenfin | We'd need https://review.opendev.org/c/openstack/releases/+/1005720/6 to start with | 15:10 |
| elodilles | frickler: my concern is that the feature freeze has a meaning, and for OSC/SDK we drop that away... but maybe i just try to be too cautious | 15:12 |
| frickler | elodilles: I'm 100% on your side of being cautious | 15:12 |
| frickler | stephenfin: can you decouple that coding change from the more urgent data updates on top? I don't want to review the code in a rush | 15:13 |
| stephenfin | sure | 15:13 |
| stephenfin | elodilles: frickler: on the concern around freeze, I'll reiterate that OSC/SDK will be no different from any non-OpenStack deliverable | 15:13 |
| frickler | stephenfin: but they are | 15:14 |
| stephenfin | how so? | 15:14 |
| frickler | they are under OpenStack governance, aren't they? | 15:14 |
| stephenfin | yes | 15:14 |
| elodilles | i had only a quick glance on the code change, it looked OK to me, but i was thinking about some other thing that is needed IMHO if we merge this. like 'diff', or 'all' (to generate all), etc | 15:15 |
| fungi | i'm sympathetic to the problem and willing to try solutions if they have minimal side-effects, i'm just not sure they'll prove useful (still worth trything though). my opinions are colored by decades of release freeze arguments in the debian community, and the numerous "let's just branch and not freeze" experiments over the years that all essentially failed | 15:16 |
| frickler | on non openstack deliverables we have no influence. for openstack deliverables we can demand "do a ff in order to allow us to do smooth releases". if you (sdk team) claim to be excempt(sp?) from that, you need to talk to the TC first IMHO | 15:16 |
| fungi | i do agree that this still needs tc discussion and the release team shouldn't just decide, but it seems like we may have identified a workable compromise which can now be presented to the community as an option for consideration | 15:18 |
| stephenfin | Firstly, what does the TC have to do with this? Secondly, what impact does this have on smooth releases if we're explicitly not bumping u-c | 15:18 |
| stephenfin | *? | 15:18 |
| frickler | yes, the larger issue may be ignoring feature freeze. but I also need to think about the whole thing with a fresh mind once more, not on a friday evening | 15:20 |
| fungi | i wouldn't completely discount consistency with other openstack deliverable timelines as worthless, but it's part of the cost/benefit analysis | 15:20 |
| fungi | the change isn't just an implementation detail, and has implications for communication with our users about expectations | 15:21 |
| fungi | different folks will necessarily place different value on those things, so it's worth getting tc/community buy-in on a significant user-facing change in how and when some kinds of deliverables are released or exceptions we might codify | 15:23 |
| frickler | that's a good point, too. how can we tell users "you can always use latest OSC against (not too old) existing clouds", if there is a period where there is a gap in testing that? | 15:23 |
| stephenfin | That's an entirely theoretical point, and not really something for the release team to decide | 15:24 |
| frickler | exactly, that's one of the aspects where the TC comes into play | 15:25 |
| fungi | well, the gap would be for server-side use of the sdk in service-to-service communication, new sdk changes would still be tested against the unreleased state of the services for user-facing interactions | 15:25 |
| frickler | that's assuming sdk has full coverage in their own test jobs | 15:25 |
| fungi | i don't think operators can expect to deploy an under-development nova and neutron from source with a version of the sdk targeting a future release cycle | 15:25 |
| frickler | some features only get coverage in service-specific jobs | 15:25 |
| frickler | that's exactly the question, does the sdk only target the current release cycle? or does (or should) it target a reasonable list of stable releases as well? | 15:27 |
| stephenfin | we support as many historical releases as we can, and avoid removing support for older features unless we are confident no one is using them or they are broken | 15:28 |
| stephenfin | which was my whole point about SDK and OSC having one foot in and one foot out of the release cycle | 15:29 |
| stephenfin | IMO, the release team's concern should be that SDK/OSC merges something that breaks gates for other services. If that happens, then the SDK team is on the hook to fix that, not the release team | 15:30 |
| frickler | but it is the service teams that suffer, and the release team is the guardian to protect them? | 15:31 |
| fungi | i do still think there is likely to be a challenge in jobs that test with consuming unreleased branch state of those deliverables, since right now they probably are using the master branch instead of the stable branch for that cycle (once it exists), but it's already likely for those to diverge anyway with or without tagging releases in master at that point | 15:32 |
| stephenfin | yes, and they do that by not merging u-c bumps until the issue is resolved | 15:32 |
| frickler | but not everyone needs to use u-c. since neither distros nor all users do | 15:33 |
| stephenfin | you're moving the ball. We were talking about services and now we're talking about distros and users | 15:34 |
| stephenfin | distro consume from stable branches though. I haven't proposed any changes to that. We still branch OSC and SDK early | 15:34 |
| fungi | right, but our (current) user/downstream-facing list of versions of things to deploy together is the deliverable files in the releases repo (or release pages on the releases site) | 15:34 |
| fungi | so still not affected by this potential change | 15:34 |
| stephenfin | users are either using u-c or they're not. If they are, nothing changes (u-c is frozen). If they are not, nothing changes since we already release before we bump u-c | 15:35 |
| elodilles | stephenfin: do you know any project that has job agains 'latest master' of OSC / SDK? (i do remember that a couple of teams do that with oslo libs. to avoid surprisa breakages when a late oslo lib release arrives) | 15:35 |
| fungi | the upper-constraints.txt file is an implementation detail of our upstream testing, we include loud warnings not to rely on it downstream | 15:35 |
| stephenfin | osc and sdk test each other with a -tips job | 15:36 |
| stephenfin | I don't think any of the services have an equivalent for either osc/sdk. It would be a bit odd if they did since that's what u-c is there for | 15:36 |
| stephenfin | fungi: indeed, but it is expected that downstream would rely on branches | 15:37 |
| elodilles | stephenfin: true, but some teams want to avoid surprises as i said. maybe those jobs are non-voting, or just periodics o:) | 15:37 |
| fungi | stephenfin: or the deliverables lists in the releases repo/site when it comes to tagged versions, which is what this discussion is about | 15:37 |
| elodilles | but yes, in that case it's just a warning, not a gate issue | 15:37 |
| stephenfin | fungi: that's not changing though | 15:38 |
| fungi | stephenfin: that was my point | 15:38 |
| fungi | (i was agreeing with you) | 15:39 |
| stephenfin | ah, sorry. I understand now | 15:39 |
| opendevreview | Stephen Finucane proposed openstack/releases master: Add 2027.1 Indri deliverable files (library, client-library) https://review.opendev.org/c/openstack/releases/+/1005721 | 15:41 |
| opendevreview | Stephen Finucane proposed openstack/releases master: Add 2027.1 Indri deliverable files https://review.opendev.org/c/openstack/releases/+/1005722 | 15:41 |
| fungi | but also basically any downstream impact that might occur would be for the version currently under development if people made the wrong assumptions about combining latest master branch tags or latest packages from pypi with unreleased master state of services, and we generally expect that people "drinking from the firehose" are consenting adults who can figure out what | 15:41 |
| fungi | they're supposed to do | 15:41 |
| opendevreview | Stephen Finucane proposed openstack/releases master: openstacksdk 4.21.0 https://review.opendev.org/c/openstack/releases/+/1005909 | 15:41 |
| opendevreview | Stephen Finucane proposed openstack/releases master: keystoneauth 5.18.0 https://review.opendev.org/c/openstack/releases/+/1005910 | 15:42 |
| opendevreview | Stephen Finucane proposed openstack/releases master: python-openstackclient 10.4.0 https://review.opendev.org/c/openstack/releases/+/1005911 | 15:42 |
| opendevreview | Riccardo Pittau proposed openstack/releases master: Release sushy 5.14.0 https://review.opendev.org/c/openstack/releases/+/1006695 | 15:42 |
| opendevreview | Takashi Kajinami proposed openstack/releases master: Release python-observabilityclient 1.5.0 https://review.opendev.org/c/openstack/releases/+/1006698 | 15:42 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: Release os-vif 5.3.0 version https://review.opendev.org/c/openstack/releases/+/1008445 | 15:42 |
| stephenfin | frickler: elodilles: for next week at this point, but I've pulled that tooling change out of the stack as rquested | 15:43 |
| elodilles | stephenfin: thanks o/ | 15:43 |
| stephenfin | fungi ++ | 15:43 |
| fungi | probably the greatest downstream impact will be for distribution packagers, who will typically not want to ship more than one version of openstacksdk in their distribution so will need to refrain from packaging the latest tagged version if it's targeting a future release rather than the current one | 15:44 |
| fungi | since they'll presumably prefer to package the one which corresponds to the release for the versions of services they're also working on packaging | 15:45 |
| fungi | in order to have some assurance that they interoperate correctly | 15:45 |
| fungi | but again, that's what we signal in our cycle deliverables lists | 15:46 |
| stephenfin | zigo or the likes can probably weigh in there, but my experience is that the "normal" repos only carry the client and some libraries, and you need to enable special repos if you want to "install" OpenStack | 15:47 |
| stephenfin | The former generally carry the latest and greatest version of $client or $library, while the latter should be contain a version of same corresponding to the given release | 15:47 |
| zigo | Well, OpenStack is also in Debian stable, not just only in an add-on repo (haven't read all the backlog yet). | 15:49 |
| zigo | Can some write a tl;dr please ? :) | 15:49 |
| stephenfin | (which is why folks like sean-k-mooney have been telling our customers for years to just install OSC from pip rather than relying on the packaged version, since that is usually ancient) | 15:49 |
| zigo | pip is 3v1l ! :) | 15:50 |
| stephenfin | zigo: see https://etherpad.opendev.org/p/hibiscus-relmgt-tracking#L477 | 15:50 |
| fungi | zigo: tldr is that openstacksdk and openstackclient maintainers want to be able to tag new releases of those which don't correspond to the openstack release under development, but rather to a future release cycle, instead of freezing | 15:50 |
| fungi | distribution package maintainers will presumably want to refrain from packaging those new versions until they package the corresponding versions of other deliverables for that future cycle | 15:51 |
| zigo | I always vote for freezing and be alligned with the rest of OpenStack. | 15:51 |
| stephenfin | importantly those new releases would be cut from master and not the stable branches, which have stable policy in effect | 15:51 |
| zigo | We've always worked this way, each time something goes away from that model, that's one more problem. | 15:52 |
| fungi | but i think that's not much differet from the situation today, because we make library releases from master earlier in the cycle which aren't intended for use with the prior openstack version | 15:52 |
| zigo | Ah ... | 15:52 |
| zigo | So I wouldn't be impacted then. | 15:52 |
| zigo | Cut any release you want, as long as stable stays ... well... stable ! :) | 15:52 |
| zigo | That's about stable+1 dev that we're talking about, that's not really my business, is it? (well, not with this package maintainer hat at least) | 15:53 |
| stephenfin | yes, no changes to stable branches and no changes to u-c during freeze period | 15:53 |
| fungi | zigo: right, if you only ever package versions of openstack deliverables from their stable branches, nothing changes there either way | 15:53 |
| zigo | Then fine, do what you wish, I haven't been doing in-the-between releases for years anyways. | 15:53 |
| zigo | (and I do not regret that period...) | 15:54 |
| opendevreview | Stephen Finucane proposed openstack/releases master: Move data directory into package https://review.opendev.org/c/openstack/releases/+/1005719 | 15:56 |
| opendevreview | Stephen Finucane proposed openstack/releases master: Migrate commands to use SeriesStatus.default https://review.opendev.org/c/openstack/releases/+/1008247 | 15:56 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!