17:59:58 <gouthamr> #startmeeting tc 17:59:58 <opendevmeet> Meeting started Tue Sep 24 17:59:58 2024 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:58 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:58 <opendevmeet> The meeting name has been set to 'tc' 18:00:09 <gouthamr> Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. 18:00:13 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 18:00:17 <gouthamr> #topic Roll Call 18:00:22 <noonedeadpunk> o/ 18:00:26 <spotz[m]> o/ 18:00:26 <gmann> o/ 18:00:28 <cardoe> o/ 18:01:25 <bauzas> \o 18:01:35 <frickler> \o 18:02:10 <slaweq> o/ 18:02:38 <gouthamr> nearly there 18:02:40 <gouthamr> courtesy ping: gtema 18:04:29 <gouthamr> no noted absences today; i'm taking this meeting from a parking lot on a hotspot :D so, please accept my apologies to throw the chair at a couple of people that are aware 18:04:42 <gouthamr> #chair gmann 18:04:42 <opendevmeet> Current chairs: gmann gouthamr 18:04:48 <gouthamr> ^ just in case 18:04:52 <gmann> +1 18:05:02 <spotz[m]> We do some meetings where everyone is the chair:) 18:05:30 <gouthamr> haha, like musical chairs, except we never drop a chair 18:05:41 <gouthamr> alright, 5 mins have passed.. lets get started 18:05:51 <spotz[m]> Well and everyone can use the commands if needed:) 18:05:53 <gouthamr> #topic Results of the Combined TC/PTL Elections for 2025.1 18:06:46 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/TBFUH5LTDHDDBOOOOM5AOCL3Z6DHXX6B/ (2025.1 Epoxy: Technical Committee & PTL Election Conclusion & Results) 18:07:00 <gouthamr> lets begin by welcoming cardoe and bauzas 18:07:07 <gouthamr> and welcoming back, gmann and frickler 18:07:16 <frickler> \o/ 18:07:29 <slaweq> congratulations!!! 18:07:32 <JayF> o/ congrats 18:07:35 <cardoe> \o 18:07:45 <gmann> o/ 18:07:46 <spotz[m]> Congrats all! And thank you again Jay and Dan!! 18:08:04 <gmann> yeah thanks JayF and dansmith for your great contribution in TC 18:08:12 <noonedeadpunk> ٩(^ᴗ^)۶ 18:08:18 <gouthamr> ++ thank you JayF and dansmith 18:08:31 <gouthamr> lets continue clinking our glasses/mugs to all the people that volunteered to be PTLs (and project liaisons) 18:08:39 <bauzas> thanks :) 18:09:03 <spotz[m]> Congrats and thank you PTLs! 18:09:05 <gouthamr> and keep the applause going to slaweq and ianychoi who did a great job with these elections :) 18:09:27 <frickler> +1 18:09:28 <bauzas> ++ 18:09:37 <slaweq> thx, it was my first time in that role :) 18:09:59 <cardoe> well it was smooth. great work 18:10:28 <gouthamr> bauzas cardoe: /me meant to check earlier if you had a chance to look through the onboarding material.. 18:10:48 <cardoe> yes 18:11:28 <gouthamr> perfect; thank you.. we use multiple emails, i realize I didn't check what your preferred one was.. 18:11:29 <gmann> slaweq ianychoi thanks for running the show and great job 18:11:42 <gouthamr> for anyone else looking, the TC onboarding email looked like this: 18:11:43 <bauzas> I saw it :) 18:11:45 <gouthamr> #link #link https://etherpad.opendev.org/p/os-tc-onboarding (TC Onboarding) 18:11:45 <gouthamr> 18:11:54 <gouthamr> #undo 18:11:54 <opendevmeet> Removing item from minutes: #link https://etherpad.opendev.org/p/os-tc-onboarding 18:11:57 <gouthamr> #link https://etherpad.opendev.org/p/os-tc-onboarding (TC Onboarding) 18:12:29 <gouthamr> the TC gerrit group has been adjusted as well, which means, please do verify if you have rollcall voting rights as well 18:12:30 <gouthamr> #link https://review.opendev.org/admin/groups/c88faeb0c52f35ee530be8defcc9627ea87b28df (TC Gerrit Group) 18:13:20 <gouthamr> as is procedure, we're onto the next task of picking a TC chair.. i pbkac'ed this one a little bit.. 18:13:49 <gouthamr> as gmann pointed out yesterday, we should have actively encouraged chair nominations for three days past the election cycle 18:13:53 <bauzas> gouthamr: I checked it, and I got the rollcall-vote 18:13:58 <gouthamr> bauzas++ ty 18:14:01 <gouthamr> #link https://review.opendev.org/q/topic:%222025.1-tc-chair%22 (2025.1 TC Chair Candidates) 18:15:02 <frickler> looks like no election needed, another round of gratulations due? ;) 18:15:04 <gmann> As there is only one nomination, we do not need election and gouthamr can directly propose a gerrit change to add 'chair' in TC member list page 18:15:26 <bauzas> I'm fine with this 18:15:36 <gouthamr> ++ thank you; i'll propose the change after this meeting.. 18:15:43 <gmann> yeah, congrat and thanks gouthamr for continuing helping in that role 18:15:50 <bauzas> congrats gouthamr 18:15:55 <gouthamr> would any one like to be vice-chair? 18:15:59 <bauzas> and indeed thanks 18:16:07 <spotz[m]> woohoo congrats:) 18:16:15 <cardoe> thank you for continuing to be the chair gouthamr 18:16:15 <gouthamr> i did lean on frickler quite a bit, as i did on everyone else on the TC :D 18:16:51 <gouthamr> thank you and you're welcome... i'm learning to do this well, publicly and you've been gracious teachers :) 18:16:52 <frickler> didn't seem too bad to me, but I'd be happy for anyone else to take over 18:17:35 <noonedeadpunk> I can try to volunteer though also would be happy if someone has more will :D 18:17:38 <noonedeadpunk> (or time) 18:17:51 <bauzas> not my will :) 18:18:04 <spotz[m]> Vice chair is a good way to get experience and learn more about the governance and such 18:18:20 <bauzas> (I'm already the Nova PTL... :) ) 18:18:35 * gouthamr sheesh, that's not enough workload 18:18:42 <noonedeadpunk> haha 18:18:48 <gmann> :) 18:18:52 <bauzas> noonedeadpunk: propose your name ! 18:19:45 <gouthamr> awesomesauce, we can do this in one change.. if anyone else has a strong urge (and time, as noonedeadpunk noted) to do it, please do speak up now 18:19:51 <noonedeadpunk> will push a change then 18:20:02 <noonedeadpunk> if nobody will 18:20:30 * gouthamr we're all so kind 18:20:31 <gouthamr> https://www.youtube.com/watch?v=ArsrKHYn5v4 18:20:46 <gouthamr> we'll move to the next order of business 18:21:30 <gouthamr> thanks a lot for being an awesome vice chair frickler 18:21:34 <gouthamr> thank you noonedeadpunk for stepping up 18:21:35 <gouthamr> #topic TC weekly meeting times 18:21:58 <gmann> ++ thanks frickler for your time and help in that role 18:22:07 <spotz[m]> Thanks Frickler! 18:22:37 <gouthamr> we've noted that this current meeting time is quite late in the day for those of us in EMEA; 18:22:53 <gouthamr> this is a good time to see if we can move it 18:22:54 <gtema> Yes, pretty late 18:22:55 <gouthamr> #link https://framadate.org/openstacktc-25-1 (Weekly Meeting time poll for 2025.2) 18:22:59 <bauzas> I'm not *that* opiniated 18:23:03 <opendevreview> Dmitriy Rabotyagov proposed openstack/governance master: Add TC Vice-chair for 2025.1 https://review.opendev.org/c/openstack/governance/+/930372 18:23:05 * gouthamr her there's gtema 18:23:10 <frickler> and there's five of us now :) 18:23:15 <slaweq> it would be great if could be earlier :) 18:23:49 <gmann> and considering the daylight saving is coming up soon.. 18:23:53 <gouthamr> nice; could you please vote on that poll, and i can collate some new slot possibilities 18:23:55 <gouthamr> true 18:24:00 <gmann> ++ 18:24:09 <bauzas> gmann: for US, yeah, but for EU, it will be at the end of October ;) 18:24:19 <bauzas> gouthamr: ack, will vote 18:24:29 * bauzas needs to check his already packed agenda 18:24:30 <gouthamr> so, i deliberately removed 1300 UTC from consideration :D 18:24:44 <bauzas> 1600UTC is like the golden hour everyday 18:24:47 <gmann> bauzas: yeah, we can consider that also while selecting new time 18:24:50 <slaweq> yes, and actually after DST change it will be 1h earlier than now, so (at least for me) better :) 18:25:00 <gouthamr> please vote considering every week from now through March 2025.. including your respective daylight savings time change 18:25:06 <gmann> yeah 18:25:12 <bauzas> most of my agenda is packed around that time in the day, everyday 18:25:25 <spotz[m]> need to get my time calculator out 18:25:45 <bauzas> spotz[m]: I can calculate for you, I'm sooooo used to it :P 18:25:58 <gtema> Do we vote now or can it be done async during next few days? 18:26:01 <slaweq> gouthamr maybe you can prepare doodle so everyone can mark their availability? 18:26:07 <gouthamr> async ofcourse 18:26:11 <spotz[m]> I actually have the work calendar configured for UTC and CST/CDT 18:26:14 <gmann> ++ 18:26:23 <gmann> slaweq: he did https://framadate.org/openstacktc-25-1 18:26:24 <bauzas> mid-Oct, it flips for the US folks (well, the ones that have states using DST :) ) 18:26:26 <gmann> #link https://framadate.org/openstacktc-25-1 18:26:36 <slaweq> sorry, I missed it :) 18:26:50 * gouthamr feared you preferred doodle for a minute :) 18:27:04 <bauzas> I'm glad Gagenda can now use UTC TZ 18:27:17 <gouthamr> thanks in advance for adding your times 18:27:22 <bauzas> Gcal I meant 18:27:43 <gouthamr> we have a packed agenda, so any other things to be said about $topic? 18:28:31 <gouthamr> #topic 2024.2 release issues 18:29:03 <gouthamr> frickler and the release management team noted earlier that we have a bunch of pending RC1 patches 18:29:26 <gouthamr> #link https://review.opendev.org/q/topic:dalmatian-rc1-deadline+is:open (pending patches affecting the final RC deadline) 18:29:56 <frickler> these are for projects where the CI was failing 18:29:58 <gouthamr> these patches were blocked by the release team noting that the respective repo's CI system wasn't passing 18:30:01 <cardoe> Is kuryr being looked after? 18:30:12 <gouthamr> that's a good place to start 18:30:22 <gmann> kuryr deliverable is moved to Zun project team 18:30:24 <frickler> so we didn't do the "usual" PTL-approval overrides 18:30:37 <frickler> we pinged hongbin last week, but no progress yet 18:30:38 <gmann> and kuryr-kubernetes is going to be retired as no volunteer to maintain it 18:30:47 <gouthamr> #link https://review.opendev.org/c/openstack/releases/+/928532 (kuryr-libnetwork) 18:31:00 <gouthamr> #link https://review.opendev.org/c/openstack/releases/+/928575 (zun) 18:31:15 <bauzas> we only have two days for that, right? 18:31:15 <gouthamr> ^ these two were waiting on zun's contributors/PTL/release managers 18:31:24 <frickler> also zun itself is broken due to lack of support for sqla 2.0 afaict 18:31:30 <gmann> humm 18:31:32 <noonedeadpunk> iirc, Zun also does depend on kuryr 18:31:56 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/JJVBOTHRLGPE4WFRQDCGLPTUFTVZ6FKC/ ([cyborg][zun][masakari][tacker][venus] Pending removal of LegacyEngineFacade) 18:32:01 <gouthamr> ^ related 18:32:23 <frickler> so the question is: proceed with a forced broken release? or do a late drop from the release? 18:32:39 <bauzas> which exact projects are we talking about ? 18:33:03 <gmann> zun and kuryr-libnetwork 18:33:05 <noonedeadpunk> huh, I don't see masakari importing legacy facade? https://codesearch.openstack.org/?q=LegacyEngineFacade&i=nope&literal=nope&files=&excludeFiles=&repos=openstack/masakari,openstack/masakari-dashboard,openstack/masakari-monitors 18:33:32 <bauzas> IIRC, there was traction on zun 18:33:57 <bauzas> but the fact that it was depending on kuryr was creating an issue 18:33:59 <bauzas> right? 18:34:11 <gmann> seeing integration jobs also failing, I do not think it is good idea to release the broken things 18:34:17 <frickler> https://review.opendev.org/c/openstack/zun/+/928655 is the failing test patch 18:34:18 <gouthamr> gmann: frickler: specifically regarding kuryr-libnetwork, the only changes since 13.0.0 are bot changes 18:34:31 <bauzas> couldn't we add a release note saying "well, we released it but $bugs" ? 18:34:32 <frickler> and I don't see any activity to fix zun recently 18:35:00 <frickler> https://review.opendev.org/q/project:openstack/zun 18:35:00 <gmann> bauzas: but we do not know what all bugs as someone need to check ehat exact bugs and after that it will work 18:35:13 <bauzas> I see 18:35:18 <bauzas> so this would be a blank check 18:35:24 <gmann> yeah 18:35:44 <frickler> we could only advise zun deployments to not upgrade at this time 18:35:57 * gouthamr actually; there're no changes in zun since 13.0.0 either 18:36:06 <gmann> I think that is better way to handle it 18:36:36 <gmann> and maybe this can trigger users of it come forward and help 18:36:46 <gmann> as i remember, its just hongbin taking care of it 18:36:46 <bauzas> zun is cycle-with-rc, right? 18:37:04 <bauzas> shouldn't we change it to independent ? 18:37:24 <gouthamr> https://github.com/openstack/zun/compare/master...13.0.0 18:37:24 <gouthamr> https://github.com/openstack/kuryr-libnetwork/compare/master...13.0.0 18:37:29 <frickler> bauzas: we could propose that for next cycle 18:37:51 <noonedeadpunk> just today I had a chat with some Zun user. But dunno how they will wanna step in. And they don't have very good record frankly speaking 18:38:03 <frickler> but also it would still be broken with current upper-constraints likely. so an issue for uncontainerized deployments 18:38:05 <bauzas> do we have a strong bond on cycle-with-rc that requires us to ship some RC ? 18:38:23 <gouthamr> (sorry, comparison was in the wrong direction) 18:38:24 <gouthamr> https://github.com/openstack/kuryr-libnetwork/compare/13.0.0...master 18:38:34 <gmann> in next cycle, we should check if project is still ok to continue as Active or not. I would say mark it Inactive in start of next cycle and then go from there if we can release or not 18:39:05 <gmann> at least, this way we will get more clarity about maintenance for next cycle in advance 18:39:16 <spotz[m]> How many projects are in this state? 18:39:16 <bauzas> ++ 18:39:34 <noonedeadpunk> I'm very skeptical about Zun frankly speaking. As it didn't have enough love for quite some time now. 18:39:42 <gmann> #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects 18:39:51 <noonedeadpunk> And given it's barely maintained itself - it likely also needs kuryr now on top 18:40:00 <gmann> noonedeadpunk: agree 18:41:21 <bauzas> but the problem is for this release, right? 18:41:34 <bauzas> we know it will be broken 18:42:02 <gmann> this release, I think we should not release and say not to upgrade. consider last cycle release as latest for this cycle also 18:42:38 <bauzas> gmann: is there anything in the cycle-with-rc model that forces us to release ? 18:43:19 <bauzas> tbh, I lean towards your opinion, if we know that master is somehow broken, let's keep the precedent as the blessed release 18:43:26 <noonedeadpunk> I think project needs to be inactive not to release 18:43:27 <gmann> it should be release for that cycle that is why i think release team might require TC resolution for skipping the rleasae 18:43:31 <noonedeadpunk> but not sure where it's written 18:43:49 <noonedeadpunk> and timeline for marking as inactive probably passed 18:43:57 <noonedeadpunk> *(totally passed) 18:44:02 <gmann> like we did for murano case last time, we stopped its release by passing a TC resolution 18:44:07 <gmann> noonedeadpunk: yeah, 18:44:23 <noonedeadpunk> well murano case was way-way-way worse 18:44:29 <gmann> #link https://governance.openstack.org/tc/resolutions/20240227-remove-murano-from-2024-1-release.html 18:44:42 <gmann> noonedeadpunk: but we never know if anything such thing in Zun also 18:44:48 <noonedeadpunk> and also - we did released known broken services before 18:45:03 <fungi> '“cycle-with-rc” projects commit to publish at least one release candidate following a predetermined schedule published by the Release Management team before the start of the cycle.' 18:45:05 <fungi> #link https://releases.openstack.org/reference/release_models.html#cycle-with-rc Cycle With RC model 18:45:09 <noonedeadpunk> with hope to early backport, maybe before final release 18:45:12 <spotz[m]> If it's going to break we need to stop it now with another resolution 18:45:29 <fungi> '“cycle-with-rc” projects commit to produce a release to match the end of the development cycle.' 18:45:33 <bauzas> fungi: thanks for the clarification 18:45:33 <fungi> is what i meant to quote 18:45:50 <bauzas> and yeah it would require a TC resolution then 18:46:00 <fungi> i guess it's a question of how you interpret that commitment 18:46:08 <fungi> but yes, probably 18:46:13 <gmann> I am more inclined to avoid murano case. We do not know if there is any security things there 18:46:34 <noonedeadpunk> well we don't know this about any project 18:46:48 <cardoe> So I think a release is a bit of a signal to the world about the health of a project. If you know it's bad and going to fail, avoid releasing. 18:46:50 <fungi> murano was a case where we said deployments should remove the software asap due to a known and unfixed exploitable vulnerability 18:46:59 <gmann> we do have maintainers and active maintainers for other projects and gate working 18:47:06 <gmann> at least those are enough proof. 18:47:21 <noonedeadpunk> so this per say should not be a concern. And if security thing will raise for project that's passing gates now but won't bother to fix it - won't save us either 18:47:44 <gmann> or at least, we can be sure that if any such security issue comes then we have project team to fix it. 18:48:09 <noonedeadpunk> I mean... 18:48:17 <noonedeadpunk> Are we? 18:48:48 <gmann> risk is more when we know 1. project gate is broken 2. no one to help to fix it 3. we do not know if anyone there to help fixing in future 18:49:16 <gmann> its about how much risk we want to take 18:49:28 <noonedeadpunk> like technically - Zun passes criterias as other projects, except currently broken gates. and we actually don't know - maybe they broke 3 weks ago... 18:49:39 <noonedeadpunk> There's a PTL for it. 18:49:51 <noonedeadpunk> As trust is a very subjective thing, kinda. 18:50:19 <noonedeadpunk> I wonder - can we do RC1 but then don't do final release? 18:50:30 <bauzas> I don't think we can 18:50:33 <gmann> honestly saying, i am ok to no release things even they are ready but not ok for taking risk which can endup in Murano like case 18:50:38 <gouthamr> i'd suggest making our intention to block the release known on the ML for zun (and kuryr-libnetwork).. although in case of kuryr-libnetwork, i don't see any problem not releasing - there aren't any release-worthy changes.. 18:51:02 <noonedeadpunk> and actually neither for Zun... 18:51:08 <noonedeadpunk> yeah, that's a good argument. 18:51:10 <gmann> yeah 18:51:15 <bauzas> one thought, 18:51:32 <bauzas> could we tag RC1 on a SHA1 that's exactly the same than Caracal rc1 ? 18:51:48 <gmann> bauzas: that can be one option. 18:51:58 <noonedeadpunk> I think checks won't pass for releases repo 18:52:01 <noonedeadpunk> but not 100% sure 18:52:07 <bauzas> that's my ask 18:52:18 <gtema> Just for a "Check-Mark"? 18:52:26 <bauzas> nothing prevents me to propose a releases patch against any sha1 18:52:30 <gmann> we do it for some tempest-plugin but need to check if it is same for cycle-wih-rc also 18:52:32 <noonedeadpunk> but like - how that's gonna help? 18:52:38 <bauzas> but I don't know whether jobs would fail 18:52:42 <bauzas> noonedeadpunk: good call 18:52:53 <noonedeadpunk> as it'll be same way broken , as no valid changes were merged in the meanwhile anyuway 18:53:15 <bauzas> if the problem is about being forced to release *something* we trust, then let's release based on our knowledge 18:53:21 <gtema> Exactly, dummy release is useless and harmful 18:53:41 <bauzas> because Caracal was broken too ? if so, nevermind my proposal 18:53:42 <gmann> noonedeadpunk: at least it will handle current release and for next cycle anyways we can mark it inactive and take it forward from there 18:54:11 <noonedeadpunk> Well, based on the changelog I think we can tell that current master is same way truthworthy as 2024.1 18:54:19 <bauzas> \o/ 18:54:24 <bauzas> but we released caracal 18:54:41 <bauzas> there are two ways to see it, then :-) 18:54:54 <gtema> That's a bureaucracy not serving anybody 18:54:59 <gmann> I am ok with either way 1. not to release 2. release with last working sha (caracal) but not ok with release with broken code 18:55:18 <spotz[m]> I'm good with 1 or 2 but not broken 18:55:21 <noonedeadpunk> Caracal is _exactly_ same code 18:55:29 <noonedeadpunk> so 2 == broken 18:55:35 <noonedeadpunk> #link https://github.com/openstack/zun/compare/13.0.0...master 18:55:36 <gmann> humm 18:55:48 <noonedeadpunk> so you're saying that changes to releasenotes broke project? 18:55:57 <slaweq> how we released it broken in Caracal then? Do you know maybe? 18:56:03 <gouthamr> ^ or, sometimes, the CI scripts go out of whack? 18:56:11 <gmann> good point. it is more of it is broken due to deps things 18:56:11 <slaweq> or it wasn't broken at that time? 18:56:12 <noonedeadpunk> we changed u-c since caracal 18:56:19 <slaweq> ok 18:56:23 <noonedeadpunk> that's the reason why gates are failing I bet 18:56:28 <gouthamr> +1 18:56:28 <gmann> slaweq: no, bcz it worked on caracal oslo or other depds 18:56:36 <slaweq> ++ 18:56:37 <slaweq> thx 18:57:00 <gmann> noonedeadpunk: I agree with you now, releasing with caracal does not make sense 18:57:07 <bauzas> ditto 18:57:15 <bauzas> option 1 for me then 18:57:32 * gouthamr time check.. 3 mins 18:57:37 <bauzas> and fear the consequences of a non-written rule 18:57:47 <spotz[m]> #1 18:57:56 <noonedeadpunk> I kinda fine to release it "broken" or do just RC1 and tell not to update dependencies if "upgrading" 18:58:13 <noonedeadpunk> just to follow the process and mark as inactive at very beginning of cycle 18:58:26 <noonedeadpunk> unless honbin won't chime in and fix gates 18:58:30 <noonedeadpunk> and backport to 2024.2 18:59:00 <gouthamr> how could we have avoided this? tagged a release during M-1/M-2 as a forced release? 18:59:09 <gmann> ah, that is another good point. if no release then no stable/2024.2 right? 18:59:17 <gouthamr> ^ yes 18:59:21 <bauzas> yup 18:59:24 <noonedeadpunk> there's already 2024.2 afaik 18:59:30 <bauzas> how so ? 18:59:31 <gmann> is it? 18:59:34 <gouthamr> not without the rc1 changes 18:59:46 <bauzas> yeah unless tooling is broken :) 18:59:54 <noonedeadpunk> oh, forget it, I'm wrong here 18:59:57 <gmann> #link https://github.com/openstack/zun/branches/all 18:59:57 * gouthamr timecheck .. 1 min 19:00:10 <noonedeadpunk> disregard my last comment :) 19:00:11 * gouthamr timecheck.. done 19:00:34 <gouthamr> alright folks; we must proceed beyond the meeting for this one.. and table the other discussion items to next week 19:00:36 <fungi> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/UE23ZVPR4BMUR6ZJ4EG55JZL25XZCUYP/ volunteers needed for 2024.2/dalmatian release episode of openinfra live 19:00:39 <bauzas> but we need to come to an agreeement before end of this week, right ? 19:00:49 <noonedeadpunk> clean forgot that we create branch from tag in one go nowadays 19:00:58 <gmann> yeah 19:01:09 <gouthamr> thank you for the call out regarding the release recap fungi! 19:01:15 <noonedeadpunk> let's raise a ML asap 19:01:36 <gouthamr> noonedeadpunk: +1 19:01:44 <gouthamr> for the sake of the minutes: 19:01:47 <gouthamr> thank you all for attending 19:01:48 <noonedeadpunk> can write it up right after the meeting 19:01:50 <gouthamr> #endmeeting