| elodilles | frickler: sorry, had to leave early yesterday. about the feature branch: i don't have knowledge about that one but i assume we don't eol them via release tools, so it should be done manually | 08:58 |
|---|---|---|
| elodilles | ttx hberaud : do you have any memory about this ^^^ ? | 08:59 |
| opendevreview | Merged openstack/releases master: Tag governance 0.16.0 for Feb 2024 elections https://review.opendev.org/c/openstack/releases/+/910523 | 09:00 |
| opendevreview | Merged openstack/releases master: Release final python-heatclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910170 | 09:01 |
| hberaud | elodilles: you speak about Takashi's email? | 09:06 |
| elodilles | hberaud: nope, sorry, about this: https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2024-02-29.log.html#t2024-02-29T15:00:15 | 09:08 |
| hberaud | yeah, that's the same topic https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/NA7OEMB3QMPW7R4D3MAERXP6K4IVFCUD/ | 09:09 |
| hberaud | so, TBH I don't remember removing feature branch before, but I don't think we need to eol them. I think these branches only require a manual removal | 09:09 |
| elodilles | +1 | 09:12 |
| frickler | ok, I was only wondering whether it might be helpful to record that deletion somewhere. maybe by introducing a tag with a deletion date into the deliverables file? but I'll go ahead and just delete that branch then | 09:16 |
| hberaud | no, speaking about oslo.messaging, AFAIK nobody really used them | 09:17 |
| hberaud | (no to the record) | 09:17 |
| ttx | Yes in the past we did manual branch removing for feature branches -- those are basically outside of release management scope | 09:27 |
| opendevreview | Hervé Beraud proposed openstack/releases master: fix R-5 template https://review.opendev.org/c/openstack/releases/+/910710 | 09:40 |
| opendevreview | Merged openstack/releases master: Move ironic projects to launchpad https://review.opendev.org/c/openstack/releases/+/910634 | 09:41 |
| opendevreview | Merged openstack/releases master: Release final python-manilaclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910176 | 09:47 |
| opendevreview | Merged openstack/releases master: Release ovn-octavia-provider for stable/zed https://review.opendev.org/c/openstack/releases/+/906873 | 10:55 |
| opendevreview | Elod Illes proposed openstack/releases master: Release final python-cinderclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910164 | 12:19 |
| frickler | ok, branch deleted | 12:31 |
| opendevreview | Elod Illes proposed openstack/releases master: Release final python-magnumclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910175 | 12:51 |
| opendevreview | Elod Illes proposed openstack/releases master: Release final python-mistralclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910180 | 13:00 |
| opendevreview | Elod Illes proposed openstack/releases master: Release final python-vitrageclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910213 | 13:05 |
| opendevreview | Elod Illes proposed openstack/releases master: Release final python-mistralclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910180 | 13:08 |
| elodilles | if you have time, then these are ready for review: https://review.opendev.org/q/topic:caracal-milestone-3+is:open | 13:14 |
| elodilles | deadline has passed and should be good to go | 13:14 |
| hberaud | ack | 13:14 |
| elodilles | thx in advance o/ | 13:14 |
| hberaud | friendly reminder, our weekly meeting will start in ~30 minutes | 13:27 |
| elodilles | ACK | 13:32 |
| opendevreview | Merged openstack/releases master: Release final python-magnumclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910175 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-watcherclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910214 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-blazarclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910162 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-muranoclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910201 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-aodhclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910160 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-adjutantclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910159 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-brick-cinderclient-ext for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910163 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-keystoneclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910174 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-designateclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910167 | 13:40 |
| opendevreview | Merged openstack/releases master: Release final python-glanceclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910168 | 13:41 |
| opendevreview | Merged openstack/releases master: Release final python-barbicanclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910161 | 13:41 |
| opendevreview | Merged openstack/releases master: Release final python-cinderclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910164 | 13:41 |
| opendevreview | Merged openstack/releases master: Release final python-novaclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910206 | 13:41 |
| opendevreview | Merged openstack/releases master: Release final osc-placement for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910158 | 13:41 |
| elodilles | note that i've updated these 2 as well: https://review.opendev.org/q/topic:caracal-milestone-3+is:open | 13:45 |
| hberaud | done | 13:53 |
| elodilles | thx again o/ | 13:57 |
| hberaud | #startmeeting releaseteam | 14:00 |
| opendevmeet | Meeting started Fri Mar 1 14:00:32 2024 UTC and is due to finish in 60 minutes. The chair is hberaud. 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 |
| hberaud | Ping list: elod frickler armstrong | 14:00 |
| elodilles | o/ | 14:00 |
| hberaud | https://etherpad.opendev.org/p/caracal-relmgt-tracking | 14:00 |
| hberaud | we are at line 311 (R-5) | 14:00 |
| ttx | o/ | 14:01 |
| frickler | \o | 14:01 |
| hberaud | let's go | 14:01 |
| hberaud | #topic Review task completion | 14:01 |
| hberaud | 1) Process any remaining library freeze exception | 14:02 |
| hberaud | https://review.opendev.org/q/topic:caracal-final-non-client-libs+is:open | 14:02 |
| hberaud | so everything is now done | 14:02 |
| hberaud | 2) Propose autoreleases for cycle-with-intermediary client libraries (elod) | 14:02 |
| hberaud | https://review.opendev.org/q/topic:caracal-milestone-3 | 14:02 |
| hberaud | same thing, here everything is +W'ed | 14:03 |
| elodilles | \o/ | 14:03 |
| opendevreview | Merged openstack/releases master: Release final python-vitrageclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910213 | 14:03 |
| hberaud | the remaining patches ^ | 14:04 |
| hberaud | 3) Evaluate any non-client libraries that did not have any change merged over the cycle to see if it is time to transition them to the independent release model (ttx) | 14:04 |
| hberaud | so, Thierry said: All libraries were released at least once | 14:04 |
| elodilles | ++ | 14:04 |
| hberaud | ttx: do you want to add something? | 14:04 |
| ttx | oops sorry | 14:05 |
| ttx | nope, nothing to report | 14:05 |
| hberaud | :) | 14:05 |
| hberaud | thx | 14:06 |
| hberaud | 4) List cycle-with-intermediary deliverables that have not been released yet and send a separate email targeted to teams with such unreleased deliverables to remind them that they need to release before $rc1-deadline (elod) | 14:06 |
| hberaud | mail sent: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/EGD6IP3W2KFT33HJDLJNK2KM5ZXFFWM3/ | 14:06 |
| hberaud | thx elodilles | 14:06 |
| elodilles | np | 14:06 |
| opendevreview | Merged openstack/releases master: Release final python-mistralclient for 2024.1 Caracal https://review.opendev.org/c/openstack/releases/+/910180 | 14:06 |
| hberaud | 5) On Friday, remind the requirements team to freeze changes to openstack/requirements by applying -2 to all open patches. Ensure that reviewers blablabla (frickler) | 14:07 |
| frickler | done, I pinged tonyb and prometheanfire in the reqs channel and also sprinkled some -2s myself | 14:07 |
| hberaud | excellent, thank you frickler | 14:07 |
| hberaud | #topic Assign next week tasks | 14:07 |
| hberaud | everything is now assigned thank you all | 14:09 |
| hberaud | #topic Review countdown email | 14:09 |
| frickler | the "Freeze" task is just to not approve any releases? or is there some actual action to be done? | 14:09 |
| hberaud | https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:09 |
| hberaud | yeah it is just a not approve thing | 14:10 |
| frickler | ok | 14:10 |
| frickler | mail lgtm | 14:10 |
| hberaud | this morning a proposed a patch to update the email template of R-5 https://review.opendev.org/c/openstack/releases/+/910710 | 14:11 |
| ttx | Added a couple of deadlines, lgtm | 14:11 |
| hberaud | I think this one is out dated due to the cycle highlight postponed to R-4 | 14:12 |
| hberaud | ttx: thx | 14:12 |
| elodilles | RC1 deadline, this is always tricky: as that is 'the week of March 11', right? | 14:13 |
| hberaud | yes | 14:13 |
| ttx | yeah... | 14:13 |
| elodilles | so what are we usually saying there? Thursday as a hard deadline? :-o | 14:13 |
| elodilles | or just leave it as it is: March 11? | 14:13 |
| elodilles | (thursday is March 14th) | 14:14 |
| hberaud | I'd leave it as it is for RC | 14:14 |
| hberaud | (IMO) | 14:14 |
| ttx | we could say "week of March 11" | 14:15 |
| elodilles | +1 | 14:15 |
| hberaud | I made the same thing for final RC | 14:15 |
| elodilles | ACK | 14:16 |
| hberaud | is it LGTY? | 14:17 |
| elodilles | LGTM, thanks! | 14:18 |
| hberaud | thx | 14:18 |
| hberaud | sent | 14:19 |
| hberaud | #topic Open Discussion | 14:20 |
| frickler | I have two things | 14:20 |
| hberaud | elodilles: the floor is yours | 14:20 |
| hberaud | frickler: sorry | 14:20 |
| frickler | but elodilles can go first | 14:20 |
| hberaud | as you want | 14:20 |
| elodilles | (elod) add a new reminder to release process for teams to not forget zuul config cleanup when starting a new development cycle | 14:21 |
| elodilles | see clarkb's messages: https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2024-02-26.log.html#t2024-02-26T16:39:54 | 14:21 |
| elodilles | so somewhere, in one of our release countdown mail (?) we should add a reminder | 14:22 |
| frickler | yes, that's a good thing. should be next to when new branches are being cut | 14:22 |
| elodilles | i think it's better early in the cycle, AFTER the official release | 14:23 |
| elodilles | well, we only have 1 mail at that period: https://releases.openstack.org/reference/process.html#week-after-previous-release | 14:23 |
| ttx | the trick is, the new development cycle starts at RC1 | 14:23 |
| hberaud | yeah maybe the first week of a series | 14:23 |
| ttx | at that point the master branch is basically next-series | 14:24 |
| elodilles | ttx: ACK, so you suggest RC1 week's mail? | 14:24 |
| ttx | yeah we could add it there | 14:25 |
| elodilles | +1, then I can propose a patch for that in the coming days | 14:25 |
| hberaud | elodilles: do you want to track it through our etherpad? | 14:26 |
| elodilles | hberaud: yeah, we can do that, let me add this task there | 14:26 |
| hberaud | ok, thx | 14:26 |
| frickler | elodilles: that's it, then? | 14:27 |
| elodilles | yepp | 14:27 |
| elodilles | if no objection :) | 14:28 |
| elodilles | and the 2nd thing from me: | 14:28 |
| hberaud | (elod) way forward with castellan 4.4.0 release? https://review.opendev.org/c/openstack/requirements/+/910221 | 14:28 |
| elodilles | (elod) way forward with castellan 4.4.0 release? https://review.opendev.org/c/openstack/requirements/+/910221 | 14:28 |
| elodilles | sry o:) | 14:28 |
| hberaud | np | 14:28 |
| elodilles | so what should we do about castellan? | 14:28 |
| frickler | so a), as I wrote in that review, I would suggest to approve that reqs bump | 14:29 |
| elodilles | in short: castellan introduced a change that causes some tests to fail in u-c gate | 14:30 |
| frickler | and b) I would leave the decision whether to create a major release to the oslo team | 14:30 |
| frickler | elodilles: but those have all been fixed now afaict? | 14:30 |
| hberaud | tkajinam: FYI ^ | 14:31 |
| hberaud | I'm ok with a) | 14:31 |
| elodilles | frickler: well, gate jobs are green, but we still depend on 2 patches, without which their gate (nova, glance) will fail, right? correct me if i'm wrong | 14:32 |
| *** ykarel is now known as ykarel|away | 14:33 | |
| hberaud | frickler: concerning b), are you suggesting to create another release based on the same SHA? | 14:33 |
| hberaud | (I haven't had time to follow this topic) | 14:33 |
| frickler | elodilles: ah, yes, I assumed those were already merged. but they do seem to have reviewer consensus mostly I'd hope | 14:33 |
| elodilles | frickler: on nova patch we have a -1 from bauzas | 14:34 |
| frickler | hberaud: yes, that might be good, since we cannot (I assume) pull the 4.4.0 release? | 14:34 |
| frickler | elodilles: but that is responded by further comments that I hope should convince bauzas to agree | 14:34 |
| elodilles | true | 14:35 |
| hberaud | then, concerning myself, I'm ok for b) | 14:36 |
| frickler | the only other solution I guess would be to repeat the revert dance from last cycle and I don't think anyone would want that? | 14:36 |
| hberaud | lol | 14:36 |
| elodilles | yeah, if we can avoid that again, that would be awesome :/ | 14:36 |
| hberaud | if we can do without it I'm not against it | 14:37 |
| elodilles | * avoid that, and not doing that again | 14:37 |
| hberaud | damani: FYI ^ | 14:37 |
| frickler | hberaud: would you want to propose the new release, then? it might improve the consensus on the nova patch a bit, too | 14:39 |
| hberaud | I can propose this new release if necessary, it would have to be approved by tkajinam and damani | 14:39 |
| frickler | I didn't check releasenotes, maybe add a prelude with a bigger warning for that? | 14:39 |
| frickler | (in case there isn't one already) | 14:40 |
| hberaud | ok | 14:40 |
| hberaud | will check | 14:40 |
| hberaud | I added a related task for next week | 14:40 |
| hberaud | assigned to myself | 14:40 |
| frickler | elodilles: ok for you? | 14:41 |
| elodilles | my only concern is: IF we merge those 2 patches (nova, glance) and bump castellan's u-c, THEN we won't risk any further breakage, right? | 14:41 |
| frickler | well we risk things breaking that aren't tested in reqs cross jobs | 14:41 |
| elodilles | :S | 14:42 |
| frickler | but that's a risk we always have | 14:42 |
| frickler | which IMO it is important that reqs updates get merged asap | 14:42 |
| elodilles | but hopefully those can have the same simple fix as nova and glance as i understand | 14:42 |
| frickler | yes, it should not be as bas as sqla2 :D | 14:43 |
| frickler | *bad | 14:43 |
| elodilles | :] | 14:43 |
| elodilles | okay, let's do this then | 14:44 |
| frickler | elodilles: ok, that's all from you? | 14:44 |
| elodilles | yepp, that's all, your turn | 14:44 |
| frickler | 1. reno and eom. https://review.opendev.org/c/openstack/reno/+/910547 | 14:44 |
| frickler | afaict this is blocking openstack-ansible | 14:45 |
| frickler | noonedeadpunk tried some workarounds within their repo, but it seems without that reno fix it will always fail | 14:45 |
| fungi | mtreinish was also asking yesterday about a release for reno | 14:46 |
| frickler | yes, we would need one with that fix anyway, so that would coincide nicely | 14:46 |
| frickler | I verified locally that the reno fix works | 14:47 |
| elodilles | +1 | 14:47 |
| elodilles | sounds OK to me then | 14:48 |
| ttx | It's always sensitive to change reno late in the release process, but that one is warranted | 14:48 |
| frickler | ok, if that gets approved and merged I'll propose a release | 14:49 |
| hberaud | +1 | 14:49 |
| frickler | https://review.opendev.org/c/openstack/openstack-ansible/+/908499 is the osa patch in question if you want to check that | 14:50 |
| frickler | ok, 2nd topic: murano | 14:50 |
| frickler | the project is to be getting marked inactive late in the cycle due to some urgent issues | 14:51 |
| frickler | the tc first wanted to approve a policy change in order to still pull it from the current release | 14:51 |
| frickler | I argued against that and then they wanted to defer the decision to the release team | 14:51 |
| frickler | against which I also objected with my release hat on | 14:52 |
| frickler | so now there is a special resolution for this to be voted on by the TC | 14:52 |
| ttx | We usually commit to what was in around milestone-2 | 14:52 |
| ttx | (the "MembershipFreeze") | 14:52 |
| ttx | so our default policy is to release it, but they can certainly overrule it | 14:53 |
| fungi | right, i think that's why they're doing it as an explicit resolution | 14:53 |
| frickler | actually I can't find that resolution | 14:54 |
| fungi | because it's recognized that this is contrary to the usual policy | 14:54 |
| frickler | I didn't really stay up to date with this over the last two days | 14:54 |
| fungi | #link https://review.opendev.org/910434 Resolution: Remove Murano from 2024.1 release | 14:54 |
| frickler | these are the two related reviews: https://review.opendev.org/c/openstack/governance/+/908880 and what fungi linked to ;) | 14:55 |
| ttx | would be simpler to just mark it inactive after we branch it, but... | 14:55 |
| ttx | i suspect there are $reasons for doing it NOW | 14:55 |
| fungi | in this case there's also a concern that it contains a severe security vulnerability (not yet public) and there's no developers available to fix it | 14:55 |
| ttx | right | 14:55 |
| ttx | I've been advocating for removal of Murano since before the pandemic so I won't object too much | 14:56 |
| frickler | so this is mostly just fyi, please comment in the review(s) if you want to | 14:57 |
| ttx | No objection beyond "we should have done that earlier" | 14:57 |
| frickler | yes, I hope one of the outcomes will be that marking project inactive will happen easier and earlier in the future | 14:58 |
| fungi | that was basically the conclusion the tc came to as well. this should have been removed sooner but slipped through the cracks and now it's going to cause a problem | 14:58 |
| frickler | I have some on my list already | 14:58 |
| opendevreview | Merged openstack/reno master: Respect EOM tag for branches in unmaintained status https://review.opendev.org/c/openstack/reno/+/910547 | 14:59 |
| frickler | ok, that's it then I guess | 14:59 |
| hberaud | Thanks for the heads up | 14:59 |
| hberaud | We are close from the end of this meeting, anything else before ending? | 14:59 |
| elodilles | nothing from me | 14:59 |
| * hberaud yes | 14:59 | |
| ttx | nothing from me | 15:00 |
| ttx | I actually need to run to another meeting | 15:00 |
| ttx | have a great weekend! | 15:00 |
| hberaud | I'm strongly focused on eventlet stuff since a couple of months, so sorry to be less active here right now | 15:01 |
| elodilles | same to you o/ | 15:01 |
| hberaud | that's all for me | 15:01 |
| hberaud | thanks everyone for joining | 15:01 |
| frickler | hberaud: no need to be sorry, great to see the progress in eventlet | 15:01 |
| hberaud | thanks | 15:01 |
| hberaud | #endmeeting | 15:01 |
| opendevmeet | Meeting ended Fri Mar 1 15:01:59 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2024/releaseteam.2024-03-01-14.00.html | 15:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2024/releaseteam.2024-03-01-14.00.txt | 15:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2024/releaseteam.2024-03-01-14.00.log.html | 15:01 |
| elodilles | hberaud: thanks for the meeting & also for working on the eventlet stuff ;) | 15:02 |
| hberaud | np, thanks :) | 15:03 |
| gtema | dear release team. I am a bit unsure about the release schedule. Is OpenStackCLI now able to merge next feature changes or not? | 15:56 |
| gtema | able=allowed | 15:56 |
| elodilles | gtema: let me check the state there | 16:03 |
| elodilles | gtema: so, this week is Feature Freeze, yes, which means that you should not merge any feature from now on, only bug fixes | 16:06 |
| gtema | ok, till when? Apil? | 16:07 |
| stephenfin | elodilles: starting from when? last Monday? This evening? | 16:07 |
| elodilles | gtema: R-3 is the week when the final release have to be proposed, | 16:07 |
| elodilles | (this week is R-5) | 16:07 |
| elodilles | and then will start the branching (stable/2024.1) as well | 16:08 |
| gtema | ok, means for next 2 weeks only bugfixes. | 16:08 |
| gtema | ah, I confused the other branching which was just completed | 16:08 |
| elodilles | after the branching is done, officially the master branch becomes 2024.2 Dalmatian's development branch, | 16:08 |
| gtema | thank you for clarification | 16:09 |
| elodilles | but best is to avoid feature merges until the final release, if possible, to make bug fixing easier (have to fix everything on master branch then cherry pick to stable/2024.1) | 16:09 |
| elodilles | final release is April 3rd | 16:10 |
| gtema | basically everything would be fine if not the one case: we have one final thing for the Neutron so that they can mark "feature completed" | 16:10 |
| gtema | the change is there we are just unsure whether we could/should merge it to help Neutron folks | 16:11 |
| elodilles | if the team decides so, then a Feature Freeze Exception can be requested, but best is to be ready with the feature ASAP | 16:12 |
| elodilles | so only if that is deemed necessary | 16:12 |
| gtema | and in this case, is it Neutron team or sdk team ;-)? | 16:12 |
| elodilles | well, i mean the sdk team, but of course, you should agree :) | 16:17 |
| gtema | sure, thank you. | 16:18 |
| elodilles | hmmm, maybe, since python-openstackcli is cwi but has the release type 'other', the FFE is not really necessary. | 16:18 |
| gtema | right, I was always very very unsure about that | 16:19 |
| elodilles | anyway, best is to release ASAP the final version of it, and not latest than March 14th | 16:19 |
| gtema | got it, thanks | 16:19 |
| elodilles | (cycle-with-rc + libraries + non-client libraries had Feature Freeze yesterday) | 16:20 |
| gtema | 👍️ | 16:22 |
| elodilles | gtema: and note that this is valid for python-openstackclient, and NOT for openstacksdk, which has release type 'library', hence it is definitely in FF o:) | 16:28 |
| gtema | oh man, quite fun | 16:29 |
| gtema | anyway - we discuss now only the cli change, sdk was merged in time | 16:29 |
| elodilles | cool :] | 16:30 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Release reno 4.1.0 https://review.opendev.org/c/openstack/releases/+/910824 | 17:29 |
| frickler | release team core (still need to define that hilight) ^^ not sure about missing reno (sic!) and version bump, please check | 17:32 |
| damani | sorry i have not seen the ping | 18:28 |
| damani | sorry what is the issue with oslo? | 18:29 |
| damani | elodilles, are you still around? | 18:32 |
| damani | elodilles, are you still around? | 18:39 |
| elodilles | damani: i'm halfway to home (from home office :D) in short: castellan release caused some errors in other projects and we are at Feature Freeze phase of the cycle so it's a bit problematic how to handle this. | 18:55 |
| elodilles | damani: during the meeting we agreed in the wayforward. see the meeting logs for details | 18:55 |
| *** ralonsoh_ is now known as ralonsoh | 19:08 | |
| opendevreview | Jay Faulkner proposed openstack/releases master: Release bifrost 17.2.0 https://review.opendev.org/c/openstack/releases/+/910843 | 20:01 |
| opendevreview | Jay Faulkner proposed openstack/releases master: Release ironic-prometheus-exporter 4.3.0 for Caracal https://review.opendev.org/c/openstack/releases/+/910844 | 20:04 |
| opendevreview | Jay Faulkner proposed openstack/releases master: Release ironic-python-agent-builder 5.3.0 for caracal https://review.opendev.org/c/openstack/releases/+/910845 | 20:08 |
| opendevreview | Jay Faulkner proposed openstack/releases master: Release ironic-ui 6.3.0 https://review.opendev.org/c/openstack/releases/+/910846 | 20:10 |
| opendevreview | Jay Faulkner proposed openstack/releases master: Release networking-generic-switch 7.3.0 for Caracal https://review.opendev.org/c/openstack/releases/+/910847 | 20:16 |
| zigo | How come python-aodhclient has oslo.db<14.2.0 in it's setup.cfg when oslo.db 15.0.0 was released ?!? | 20:17 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!