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