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