14:00:32 <hberaud> #startmeeting releaseteam
14:00:32 <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:32 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:32 <opendevmeet> The meeting name has been set to 'releaseteam'
14:00:39 <hberaud> Ping list: elod frickler armstrong
14:00:42 <elodilles> o/
14:00:49 <hberaud> https://etherpad.opendev.org/p/caracal-relmgt-tracking
14:00:55 <hberaud> we are at line 311 (R-5)
14:01:09 <ttx> o/
14:01:41 <frickler> \o
14:01:51 <hberaud> let's go
14:01:57 <hberaud> #topic Review task completion
14:02:03 <hberaud> 1) Process any remaining library freeze exception
14:02:11 <hberaud> https://review.opendev.org/q/topic:caracal-final-non-client-libs+is:open
14:02:28 <hberaud> so everything is now done
14:02:48 <hberaud> 2)     Propose autoreleases for cycle-with-intermediary client libraries (elod)
14:02:58 <hberaud> https://review.opendev.org/q/topic:caracal-milestone-3
14:03:25 <hberaud> same thing, here everything is +W'ed
14:03:35 <elodilles> \o/
14:03:46 <opendevreview> Merged openstack/releases master: Release final python-vitrageclient for 2024.1 Caracal  https://review.opendev.org/c/openstack/releases/+/910213
14:04:02 <hberaud> the remaining patches ^
14:04:12 <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:36 <hberaud> so, Thierry said: All libraries were released at least once
14:04:46 <elodilles> ++
14:04:50 <hberaud> ttx: do you want to add something?
14:05:51 <ttx> oops sorry
14:05:57 <ttx> nope, nothing to report
14:05:58 <hberaud> :)
14:06:02 <hberaud> thx
14:06: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:24 <hberaud> mail sent: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/EGD6IP3W2KFT33HJDLJNK2KM5ZXFFWM3/
14:06:29 <hberaud> thx elodilles
14:06:34 <elodilles> np
14:06:43 <opendevreview> Merged openstack/releases master: Release final python-mistralclient for 2024.1 Caracal  https://review.opendev.org/c/openstack/releases/+/910180
14:07:08 <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:16 <frickler> done, I pinged tonyb and prometheanfire in the reqs channel and also sprinkled some -2s myself
14:07:32 <hberaud> excellent, thank you frickler
14:07:54 <hberaud> #topic Assign next week tasks
14:09:26 <hberaud> everything is now assigned thank you all
14:09:43 <hberaud> #topic Review countdown email
14:09:50 <frickler> the "Freeze" task is just to not approve any releases? or is there some actual action to be done?
14:09:51 <hberaud> https://etherpad.opendev.org/p/relmgmt-weekly-emails
14:10:10 <hberaud> yeah it is just a not approve thing
14:10:47 <frickler> ok
14:10:53 <frickler> mail lgtm
14:11:30 <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:39 <ttx> Added a couple of deadlines, lgtm
14:12:06 <hberaud> I think this one is out dated due to the cycle highlight postponed to R-4
14:12:51 <hberaud> ttx: thx
14:13:02 <elodilles> RC1 deadline, this is always tricky: as that is 'the week of March 11', right?
14:13:16 <hberaud> yes
14:13:18 <ttx> yeah...
14:13:47 <elodilles> so what are we usually saying there? Thursday as a hard deadline? :-o
14:13:59 <elodilles> or just leave it as it is: March 11?
14:14:09 <elodilles> (thursday is March 14th)
14:14:15 <hberaud> I'd leave it as it is for RC
14:14:29 <hberaud> (IMO)
14:15:18 <ttx> we could say "week of March 11"
14:15:43 <elodilles> +1
14:15:50 <hberaud> I made the same thing for final RC
14:16:38 <elodilles> ACK
14:17:35 <hberaud> is it LGTY?
14:18:02 <elodilles> LGTM, thanks!
14:18:08 <hberaud> thx
14:19:52 <hberaud> sent
14:20:07 <hberaud> #topic Open Discussion
14:20:23 <frickler> I have two things
14:20:24 <hberaud> elodilles: the floor is yours
14:20:37 <hberaud> frickler: sorry
14:20:39 <frickler> but elodilles can go first
14:20:53 <hberaud> as you want
14:21:15 <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:22 <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:22:11 <elodilles> so somewhere, in one of our release countdown mail (?) we should add a reminder
14:22:39 <frickler> yes, that's a good thing. should be next to when new branches are being cut
14:23:07 <elodilles> i think it's better early in the cycle, AFTER the official release
14:23:44 <elodilles> well, we only have 1 mail at that period: https://releases.openstack.org/reference/process.html#week-after-previous-release
14:23:52 <ttx> the trick is, the new development cycle starts at RC1
14:23:57 <hberaud> yeah maybe the first week of a series
14:24:28 <ttx> at that point the master branch is basically next-series
14:24:56 <elodilles> ttx: ACK, so you suggest RC1 week's mail?
14:25:16 <ttx> yeah we could add it there
14:25:45 <elodilles> +1, then I can propose a patch for that in the coming days
14:26:20 <hberaud> elodilles: do you want to track it through our etherpad?
14:26:35 <elodilles> hberaud: yeah, we can do that, let me add this task there
14:26:44 <hberaud> ok, thx
14:27:48 <frickler> elodilles: that's it, then?
14:27:57 <elodilles> yepp
14:28:02 <elodilles> if no objection :)
14:28:11 <elodilles> and the 2nd thing from me:
14:28:16 <hberaud> (elod) way forward with castellan 4.4.0 release? https://review.opendev.org/c/openstack/requirements/+/910221
14:28:16 <elodilles> (elod) way forward with castellan 4.4.0 release? https://review.opendev.org/c/openstack/requirements/+/910221
14:28:25 <elodilles> sry o:)
14:28:29 <hberaud> np
14:28:36 <elodilles> so what should we do about castellan?
14:29:58 <frickler> so a), as I wrote in that review, I would suggest to approve that reqs bump
14:30:04 <elodilles> in short: castellan introduced a change that causes some tests to fail in u-c gate
14:30:28 <frickler> and b) I would leave the decision whether to create a major release to the oslo team
14:30:42 <frickler> elodilles: but those have all been fixed now afaict?
14:31:17 <hberaud> tkajinam: FYI ^
14:31:39 <hberaud> I'm ok with a)
14:32:26 <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:33:15 <hberaud> frickler: concerning b), are you suggesting to create another release based on the same SHA?
14:33:49 <hberaud> (I haven't had time to follow this topic)
14:33:53 <frickler> elodilles: ah, yes, I assumed those were already merged. but they do seem to have reviewer consensus mostly I'd hope
14:34:20 <elodilles> frickler: on nova patch we have a -1 from bauzas
14:34:24 <frickler> hberaud: yes, that might be good, since we cannot (I assume) pull the 4.4.0 release?
14:34:56 <frickler> elodilles: but that is responded by further comments that I hope should convince bauzas to agree
14:35:06 <elodilles> true
14:36:08 <hberaud> then, concerning myself, I'm ok for b)
14:36:12 <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:22 <hberaud> lol
14:36:53 <elodilles> yeah, if we can avoid that again, that would be awesome :/
14:37:12 <hberaud> if we can do without it I'm not against it
14:37:15 <elodilles> * avoid that, and not doing that again
14:37:55 <hberaud> damani: FYI ^
14:39:06 <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:30 <hberaud> I can propose this new release if necessary, it would have to be approved by tkajinam  and damani
14:39:59 <frickler> I didn't check releasenotes, maybe add a prelude with a bigger warning for that?
14:40:14 <frickler> (in case there isn't one already)
14:40:20 <hberaud> ok
14:40:23 <hberaud> will check
14:40:42 <hberaud> I added a related task for next week
14:40:51 <hberaud> assigned to myself
14:41:18 <frickler> elodilles: ok for you?
14:41:27 <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:57 <frickler> well we risk things breaking that aren't tested in reqs cross jobs
14:42:25 <elodilles> :S
14:42:33 <frickler> but that's a risk we always have
14:42:52 <frickler> which IMO it is important that reqs updates get merged asap
14:42:56 <elodilles> but hopefully those can have the same simple fix as nova and glance as i understand
14:43:44 <frickler> yes, it should not be as bas as sqla2 :D
14:43:51 <frickler> *bad
14:43:53 <elodilles> :]
14:44:07 <elodilles> okay, let's do this then
14:44:26 <frickler> elodilles: ok, that's all from you?
14:44:38 <elodilles> yepp, that's all, your turn
14:44:53 <frickler> 1. reno and eom. https://review.opendev.org/c/openstack/reno/+/910547
14:45:11 <frickler> afaict this is blocking openstack-ansible
14:45:55 <frickler> noonedeadpunk tried some workarounds within their repo, but it seems without that reno fix it will always fail
14:46:12 <fungi> mtreinish was also asking yesterday about a release for reno
14:46:41 <frickler> yes, we would need one with that fix anyway, so that would coincide nicely
14:47:18 <frickler> I verified locally that the reno fix works
14:47:53 <elodilles> +1
14:48:07 <elodilles> sounds OK to me then
14:48:57 <ttx> It's always sensitive to change reno late in the release process, but that one is warranted
14:49:21 <frickler> ok, if that gets approved and merged I'll propose a release
14:49:23 <hberaud> +1
14:50:14 <frickler> https://review.opendev.org/c/openstack/openstack-ansible/+/908499 is the osa patch in question if you want to check that
14:50:24 <frickler> ok, 2nd topic: murano
14:51:07 <frickler> the project is to be getting marked inactive late in the cycle due to some urgent issues
14:51:35 <frickler> the tc first wanted to approve a policy change in order to still pull it from the current release
14:51:58 <frickler> I argued against that and then they wanted to defer the decision to the release team
14:52:11 <frickler> against which I also objected with my release hat on
14:52:33 <frickler> so now there is a special resolution for this to be voted on by the TC
14:52:35 <ttx> We usually commit to what was in around milestone-2
14:52:47 <ttx> (the "MembershipFreeze")
14:53:30 <ttx> so our default policy is to release it, but they can certainly overrule it
14:53:54 <fungi> right, i think that's why they're doing it as an explicit resolution
14:54:16 <frickler> actually I can't find that resolution
14:54:20 <fungi> because it's recognized that this is contrary to the usual policy
14:54:34 <frickler> I didn't really stay up to date with this over the last two days
14:54:47 <fungi> #link https://review.opendev.org/910434 Resolution: Remove Murano from 2024.1 release
14:55:09 <frickler> these are the two related reviews: https://review.opendev.org/c/openstack/governance/+/908880 and what fungi linked to ;)
14:55:12 <ttx> would be simpler to just mark it inactive after we branch it, but...
14:55:27 <ttx> i suspect there are $reasons for doing it NOW
14:55:43 <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:52 <ttx> right
14:56:27 <ttx> I've been advocating for removal of Murano since before the pandemic so I won't object too much
14:57:29 <frickler> so this is mostly just fyi, please comment in the review(s) if you want to
14:57:51 <ttx> No objection beyond "we should have done that earlier"
14:58:25 <frickler> yes, I hope one of the outcomes will be that marking project inactive will happen easier and earlier in the future
14:58:29 <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:44 <frickler> I have some on my list already
14:59:08 <opendevreview> Merged openstack/reno master: Respect EOM tag for branches in unmaintained status  https://review.opendev.org/c/openstack/reno/+/910547
14:59:27 <frickler> ok, that's it then I guess
14:59:32 <hberaud> Thanks for the heads up
14:59:34 <hberaud> We are close from the end of this meeting, anything else before ending?
14:59:48 <elodilles> nothing from me
14:59:50 * hberaud yes
15:00:43 <ttx> nothing from me
15:00:50 <ttx> I actually need to run to another meeting
15:00:56 <ttx> have a great weekend!
15:01:12 <hberaud> I'm strongly focused on eventlet stuff since a couple of months, so sorry to be less active here right now
15:01:22 <elodilles> same to you o/
15:01:27 <hberaud> that's all for me
15:01:39 <hberaud> thanks everyone for joining
15:01:40 <frickler> hberaud: no need to be sorry, great to see the progress in eventlet
15:01:57 <hberaud> thanks
15:01:59 <hberaud> #endmeeting