| *** elodilles_pto is now known as elodilles | 08:49 | |
| *** haleyb is now known as haleyb|away | 12:38 | |
| elodilles | reminder: meeting will start in ~20 mins | 13:39 |
|---|---|---|
| cardoe | elodilles: will you be pushing the hibiscus-1 releases today? | 13:57 |
| cardoe | gtema: hoping you can approve https://review.opendev.org/c/openstack/releases/+/988085 today. | 13:58 |
| elodilles | cardoe: friday releases are always risky o:) | 13:59 |
| elodilles | but if it is needed, then we can discuss that | 14:00 |
| elodilles | but now, let's do the relmgt weekly meeting | 14:00 |
| cardoe | Well I was just wondering cause the calendar said the releases would be May 11th to May 15th | 14:00 |
| elodilles | #startmeeting releaseteam | 14:00 |
| opendevmeet | Meeting started Fri May 15 14:00:40 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:01 |
| frickler | \o | 14:01 |
| fungi | ahoy! | 14:01 |
| elodilles | o/ | 14:01 |
| elodilles | we are at line 81 | 14:01 |
| elodilles | already at Hibiscus-1 milestone :-o | 14:01 |
| elodilles | time flies | 14:01 |
| elodilles | so should we | 14:02 |
| elodilles | let's start with the agenda! | 14:02 |
| elodilles | #topic Review task completion | 14:02 |
| elodilles | - Ensure that all trailing projects have been branched for the previous series. (elod) | 14:02 |
| elodilles | so, i've pinged the PTLs last week, | 14:02 |
| elodilles | and they'd said that they are working on it, but they are not there yet | 14:03 |
| elodilles | Kolla has branched | 14:03 |
| elodilles | but kayobe, Puppet OpenStack and OpenStack Ansible are still haven't branched | 14:04 |
| fungi | early this week we saw afs syncing the tarballs volume for ~36 hours straight, which i'm guessing was kolla's new images? | 14:05 |
| elodilles | yes, that is possible :) | 14:05 |
| fungi | i'll try to remember to keep a closer eye on that next time | 14:05 |
| elodilles | they their final release is also available, so that should be the reason ;) | 14:06 |
| elodilles | anyway, i'll add a move the task to next week, and will take it on my name | 14:07 |
| elodilles | let's hope that rest of the cycle-trailing project teams are ready for branching next week | 14:07 |
| elodilles | - Propose autoreleases for cycle-with-intermediary libraries which did not release since the previous release. (elod) | 14:08 |
| elodilles | i've generated the release patches, where they had functional code changes: | 14:09 |
| elodilles | https://review.opendev.org/q/topic:hibiscus-milestone-1 | 14:09 |
| cardoe | can ya ping me during open discussion? (I'm on a work Zoom and tabbing back and forth) | 14:09 |
| elodilles | cardoe: ACK, will do | 14:09 |
| elodilles | some of the patches merged after PTL/release liaison Code-Review+1 | 14:10 |
| elodilles | but still have quite many without any response :( | 14:10 |
| elodilles | for example, oslo patches got +1 from stephenfin , but he is not release liaison for oslo :( though he is a long time active maintainer there | 14:12 |
| elodilles | should we merge them, what do you think? | 14:12 |
| elodilles | maybe worth mentioning, that however it is advised to release libraries at milestones, in the past cycles we did not force merge milestone-1 releases if there were no responses | 14:14 |
| elodilles | (but with milestone-3 we definitely have to force release, to have the latest state released) | 14:14 |
| fungi | oslo is a bit of a weird situation with different people focused on different deliverables | 14:14 |
| elodilles | so maybe part of the question is: should we abandon the release patches that haven't got any response, or let's say we force merge them on Monday? | 14:15 |
| fungi | i wonder if they need to just list all their various maintainers as release liaisons so they can ack releases for the deliverables they're maintaining | 14:17 |
| cardoe | So stuff like python-openstackclient really shouldn't be abandoned. | 14:18 |
| cardoe | The lack of responses from PTLs is a problem that should be brought to the TC | 14:18 |
| cardoe | Because this kind of paper work is what the PTL role is signed up to do. | 14:18 |
| elodilles | fungi: maybe that would be too many. in the past that was the reason to add PTL-Approved+1, so that we know that people who care most about the releases, could signal that the release is okay | 14:19 |
| cardoe | So if you're not filling the role then it's a problem for the health of the project. | 14:19 |
| elodilles | fungi: on the other hand i've already proposed if stephenfin could be release-liaison for oslo, since he is active around oslo and pushes the majority of (non-generated) oslo release patches o:) | 14:20 |
| fungi | yeah, i'm just saying part of why oslo doesn't have a single person interested in releases for all its deliverables is that it's a dumping ground for various libraries anda utilities that didn't fit anywhere better | 14:20 |
| elodilles | cardoe: yes, this is i think some kind of a recurring topic in tc | 14:21 |
| fungi | so a lot of the deliverables there are maintained more or less independent of each other, not by a common team across the whole of oslo | 14:21 |
| stephenfin | I'm okay to be a release liason for both SDK and OSC, if governance allows for that | 14:21 |
| stephenfin | since I'm likely the only person other than tkajinam that regularly touches all of oslo (and probably the only person that regularly works on all of SDK) | 14:21 |
| elodilles | stephenfin: that would be awesome, but the best would be to get an ACK from damani and tkajinam (current release liaisons) | 14:22 |
| fungi | the absent ptls and liaisons problem also has been an issue for the vmt for many years, we finally got the tc to assign volunteer tc liaisons who agree to escalate those when we loop them in | 14:22 |
| elodilles | stephenfin: i mean, ACK from them for you to be a release liaison as well o:) | 14:23 |
| stephenfin | elodilles: is that necessary, given I am already core on the projects and we're using a DPL model (genuine question: governance may well insist on it) | 14:23 |
| stephenfin | ? | 14:23 |
| fungi | maybe we could have something similar for the tc and release team to coordinate? | 14:23 |
| fungi | stephenfin: "core" is a nebulous concept that doesn't have the same definition from one team to the next | 14:24 |
| fungi | we need some official list of people for each team published in a common location | 14:24 |
| elodilles | stephenfin: i'm not insisting that it is necessary, but that would be the plainest/cleanest to have an ACK from them for you to be a release liaison too o:) | 14:25 |
| stephenfin | fungi: I thought that would be the answer but always best to ask :) | 14:25 |
| stephenfin | I'll poke damani internally. I suspect tkajinam is (long) gone for the weekend at this point | 14:26 |
| fungi | keep in mind that even just looking up who is authorized to ack a release request takes time, so we have automation to look that up, it just needs a list somewhere to look it up in (which is currently the list of ptls and release liaisons) | 14:26 |
| elodilles | stephenfin: +1 | 14:26 |
| stephenfin | Is there a YAML file I can propose myself against and have damani vote on? | 14:26 |
| * stephenfin looks in openstack/governance | 14:27 | |
| elodilles | anyway, i don't want to solve this long standing issue now, just raised the question, whether we should abandon the patches, | 14:27 |
| elodilles | but i see that cardoe has some interest on releasing some of the deliverables, | 14:27 |
| elodilles | so i'm ok with those to even force-merge if needed | 14:28 |
| cardoe | well I'm just wanting some CLI fixes that are hitting me and my team | 14:28 |
| elodilles | cardoe: yupp, sounds reasonable | 14:28 |
| cardoe | I'd also like to get some of the typing updates out there in libraries so I can nudge the Outreachy folks to make more progress on typing | 14:28 |
| elodilles | ACK, then considering these, i tend to force-merge them on Monday | 14:29 |
| elodilles | any objection? | 14:29 |
| opendevreview | Artem Goncharov proposed openstack/releases master: Release python-openstackclient for Hibiscus-1 milestone https://review.opendev.org/c/openstack/releases/+/988085 | 14:29 |
| cardoe | stephenfin and I have been -1'ing a number of patches telling folks that something is fixed in a library and the dep just needs to be updated. | 14:30 |
| elodilles | cardoe: ah, i see | 14:30 |
| elodilles | okay, i don't hear any objection o:) | 14:34 |
| elodilles | #action elod to force-merge remaining open hibiscus-1 release patches | 14:35 |
| elodilles | next task was then: | 14:35 |
| elodilles | - Catch if there are acl issues in newly created repositories (ttx) | 14:35 |
| elodilles | No issues detected | 14:35 |
| elodilles | reported on etherpad by ttx ^^^ | 14:36 |
| elodilles | that's all about tasks | 14:36 |
| elodilles | #topic Assign R-19 week tasks | 14:36 |
| elodilles | sorry, had a network lag | 14:38 |
| elodilles | so, 1 task is related to the remaining hibiscus-1 patches, and the other is about keeping an eye on new-release requirements patches, so... | 14:39 |
| elodilles | all taken | 14:40 |
| elodilles | #topic Review weekly countdown email | 14:40 |
| elodilles | please review: | 14:40 |
| elodilles | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:41 |
| frickler | +1, nice and simple ;) | 14:41 |
| elodilles | thanks frickler o/ | 14:42 |
| elodilles | #topic Open Discussion | 14:43 |
| elodilles | cardoe: did we talk through your topic already, or do you have anything else to bring up? o:) | 14:44 |
| *** gibi is now known as gibi_off | 14:46 | |
| elodilles | or any other topic from anyone else? | 14:48 |
| frickler | just a note that we did have an issue with reno publishing | 14:50 |
| frickler | fixed by https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/988768, but some reno pages may be lacking recent branches until they get republished | 14:50 |
| elodilles | ah, good to know, thanks frickler ! | 14:51 |
| elodilles | okay, if nothing else, then thanks everyone for participating and enjoy the weekend o/ | 14:53 |
| elodilles | #endmeeting | 14:53 |
| opendevmeet | Meeting ended Fri May 15 14:53:45 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:53 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-05-15-14.00.html | 14:53 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-05-15-14.00.txt | 14:53 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-05-15-14.00.log.html | 14:53 |
| frickler | thx elodilles | 14:53 |
| elodilles | my pleasure :) | 14:55 |
| elodilles | cardoe: if you think a release can't wait till monday, then ping me here and i'll try to review it today | 14:57 |
| cardoe | No it can wait | 14:58 |
| cardoe | So what I had wanted to bring up was OpenStack Helm and it's container images. | 14:58 |
| cardoe | So OpenStack Helm targets helm charts that are versioned after the current OpenStack release but support the currently supported releases back. So the 2026.1 charts support back to 2025.1 | 14:59 |
| cardoe | There's releases on every commit. | 14:59 |
| cardoe | I'm not sure if we should do some better tie in with the release team or doc improvements. | 14:59 |
| fungi | what did you have in mind? | 14:59 |
| cardoe | I'm also trying to make the container images generated a lot more generic and follow the stable branches of each project. | 14:59 |
| cardoe | Well if there's some practices / operations the release team wants projects to follow. | 15:00 |
| cardoe | I'm just wanting to try and figure out how to make it less off in the corner | 15:01 |
| cardoe | When I get some cycles I'm gonna try and clean up the skyline release process as well. | 15:01 |
| fungi | are the charts versioned independently? do they follow semver or have any other particular version numbering scheme? | 15:01 |
| fungi | just sequential/monotonically increasing? raw integer version numbers or multi-segment? | 15:02 |
| cardoe | It'll be '2025.2.17+bb8dd0598' for example for a placement chart | 15:02 |
| cardoe | So it's 2025.2 base so that's shipping a 2025.2 version of placement by default. It's the 17th version of the placement chart, the monotonic number. And then bb8dd0598 is the git-ish in the repo. | 15:03 |
| fungi | okay, so openstack coordinated release followed by another monotonically-increasing integer | 15:03 |
| fungi | and the latest 2025.2.* versions of all charts are expected to interoperate but their final version components will vary from chart to chart, or are they released in lock-step? | 15:04 |
| fungi | and you don't use distinct git tags for any of this, the versions are just determined on the fly from the repository state from which the chart was built? | 15:06 |
| cardoe | All 2025.2.* charts will interoperate and the final version varies from chart to chart. | 15:06 |
| cardoe | Correct no distinct git tags. The versions are determined from repository state at the time. | 15:06 |
| cardoe | We | 15:07 |
| cardoe | We've been using reno. Which I'll be honest I don't really understand how to make the notes correctly. | 15:07 |
| fungi | people getting different version numbers locally when adding their own commits and not having them sort chronologically compared to upstream is also not an issue, i guess | 15:07 |
| fungi | reno depends on having git tags | 15:08 |
| cardoe | cause there's the general fixes top-level but then there's also the name of the chart top-level in there. | 15:08 |
| fungi | without tags, it won't know what version to associate a note with | 15:08 |
| cardoe | https://docs.openstack.org/releasenotes/openstack-helm/current.html yeah I don't love that output. | 15:09 |
| fungi | if you're not doing tag-based versioning you'll likely need some other mechanism to curate release notes | 15:09 |
| cardoe | Ultimately we don't embed changelog entries in a helm standard format. So none of the helm chart tools can show you changelog entries | 15:10 |
| cardoe | And the reasoning I'm told is that we're complying with release team release notes. | 15:10 |
| cardoe | But I don't think the release notes are working correctly. | 15:10 |
| cardoe | So that led me to just ask are there things that the project should be doing to follow release team process better. | 15:11 |
| cardoe | Cause the project isn't listed on https://releases.openstack.org | 15:14 |
| cardoe | Anyway, it's not really an easy answer question. Just wanting to make the project a better citizen within the umbrella. | 15:15 |
| fungi | openstack release management is tag-oriented pep-440-compliant 3-segment semver for python packaging, if you're not making git tags and building python packages then you're not covered by release management anyway and not integrated with our tooling, so should probably manage release notes in a way consistent with whatever ecosystem's "releasing" model you're following | 15:19 |
| fungi | instead | 15:19 |
| fungi | put another way, openstack's release management is automation built on conventions for what's expected in the python packaging ecosystem. there's little reason to integrate with that if you're building artifacts for a different ecosystem | 15:21 |
| cardoe | okay that's fair | 15:25 |
| cardoe | So the best plan would be for the project to fix the release notes in a way that's compatible with the helm eco system and then publish them to the releasenotes page in a way that'll track the chart better. | 15:26 |
| cardoe | I just want a better experience for users. | 15:28 |
| fungi | yes, i think so | 15:32 |
| fungi | keep in mind that our publication tooling/utilities and automation are similarly built around python packaging ecosystem conventions, so a lot of it may not be reusable and you'll need to find or build more appropriate solutions | 15:33 |
| elodilles | cardoe: just a side note, that releases.openstack.org lists the releases of deliverables that are present in the given series in relmgt repositories. e.g. for gazpacho, the https://releases.openstack.org/gazpacho/index.html lists deliverables that are defined here: https://opendev.org/openstack/releases/src/branch/master/deliverables/gazpacho . but i agree with fungi | 15:36 |
| elodilles | * list the releases and their release notes | 15:37 |
| cardoe | So would it be acceptable to push https://docs.openstack.org/releasenotes/openstack-helm/current.html for example with a tool from the helm eco system to generate the release notes/ | 16:07 |
| cardoe | So like right now for my team, we run our own mirror for the sole purpose of running some tooling to analyze the delta to see what's changed. | 16:11 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily while we restart it onto a new patch release | 18:04 | |
| fungi | cardoe: yeah, i think you'd probably only need to replace the release notes build job in zuul with one that runs the helm tools to build the html you want and create the resulting content tarball with the same name as the publishing job expects | 18:55 |
| cardoe | alright. I'll make some suggestions to the PTL. I just know we cannot be the only ones that cannot follow what's been published. | 18:56 |
| *** janders2 is now known as janders | 20:32 | |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!