Meeting started at 2026-09-10 17:01:23 UTC

The Meeting name is 'F45 Beta Go/No-Go Meeting'

morning everyone🌄

Ciao ciao, my cosa nostra friends .... oops wrong channel

!hi

Aoife Moloney: Aoife Moloney (amoloney)

!hi

nirik: Kevin Fenzi (kevin) - he / him / his

Lukáš Růžička a shadowy group with strange rituals that moves behind the scenes of mainstream society yet influences it deeply? that sounds like us!

!hi

adamw: Adam Williamson (adamwill) - he / him / his

Welcome to the stone cutters

perhaps more 'organized' than us tho...

!hi

Derek Enz: Derek Enz (derekenz)

!hi

hello hello everyone

!hi

Ephraim Kaov: Ephraim Kaov (ephmo) - he / him / his

Ill give it another minute for ppl to trickle in and then we will get underway ⛵️

Alrighty, it begins

Do we have an rc worthy of the beta title?

We do -> RC 1.3

so close

1.3

son of a ...

is the undo a thing yet?

hi hi

*passes keyboard to QA

what?!

🎊

thus endeth the blocker portion

a new record, surely

I am excitely nervous to ask - how are the test coverages looking?

so we're missing some storage stuff because we lost the person who did that testing and the lab they did it in :|

there is a pending criteria proposal to drop the things we can't test any more, so i think it's reasonable to say we can do beta without them

specifically we're missing SAS and hwraid

as I noted on the discourse thread about that I might be able to scare up some sas server's for testing with... still need to look and see tho.

anaconda-bot also still doesn't test on aarch64 yet, apparently, so webui storage testing on aarch64 is a bit thin. we should talk to kkoukiou about that

Will this be the first release that we will ship beta without certain testing because of losing people from QA over the last little while?

having the hw helps, but lili had the testing automated or at least scripted via beaker iirc

a bit, yeah, although advanced storage has always been tricky, even when we had lili she didn't have *all* the we listed iirc

I understand, but this sounds like this will be the first one that Fedora will likely feel impact from

for f43 beta we actually didn't have these either. for final we did have them though. we were only missing fcoe

f44 final we shipped without sas, hwraid or fcoe, so, erp

ugh, I dont love that this just 'is what it is' now :(

yeah, but oh well

it is arguable that nobody really uses this stuff with fedora anyway

testing these is a long-term problem that got worse, that's why we proposed reducing the criteria

anyway, if you all are ok with proceeding, I cant see anything either to need to redo next week so will I !agree this section too?

hold on, still checking

ack, holdiing

we probably shouldn't forget IoT and CoreOS (as we often do)

I think we have sections for those later in the meeting...

there's a few holes in cloud

but i think overall coverage is fine (we have at least a result for each test, and for the specific tests where we don't have coverage in every env, it seems unlikely they'd be broken in a single env)

so...on the whole i think coverage looks good

sgtm

proceeding with an !agreed then and on to the CoreOS and IoT check in

!hi

!proposal While we are missing some coverage across some places, eg hwraid, SAS and some Cloud, there is a proposal to reduce test coverage in the works and there is sufficient test coverage to continue with RC 1.3 for F45 Beta release

^^ does that sound ok?

ack

ack

ack

ack

ack

dustymabe: is CoreOS good for F45 beta?

Ack

pwhalen: is IoT good to go too for beta?

IoT is Ready!

Aoife Moloney: marmijo may know better than I

pwhalen I've sent the openQA results to https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_45_RC_20260909.0_General

but it is still missing human results for some tests

marmijo: same question to you please :) is Fedora CoreOS ready for beta?

Thank you adamw

Human IoT results are here, somewhat older: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_45_RC_20260828.0_Summary

CoreOS is ready for beta!

Aoife Moloney: looking at our recent builds of `branched` (based on f45) seems to be passing tests. so I'd say we're good

ack, thank you

Kamil PáralI have more to add to 0909, just didnt want to disrupt coconut

I will now poll FESCo, Rel-Eng and QA for a decision

FESCo?

go

Rel-Eng?

also go

QA?

go

go

yaay

🎆

Go

I am shocked. 40 min go/no-go meeting???! and its a Go??!! :D

niknikovsky has already given cookies to amoloney during the F44 timeframe

must be redemption for the delayed launch of 44

I'll take it. 😀

Well done everyone, not only for your work in getting beta shipped, but inadvertently scoring me an hours free babysitting :D

I thought Id be online for at least another 2 hours! yay!

I'm a bit surprised this meeting wasn't in #blocker-review:fedoraproject.org

we can keep the meeting open longer if you need more time...

but it kinda makes sense

go no-go is allways here

there is always more work to be done, both paid and unpaid so I will take the bonus time while I can :D

We are now in open floor, so is there anything folks want to talk about relating to F45 beta before we officially close the meeting?

Go/no go never is in Blocker Review room

completely fair

yeah, a few, but oh well...

yeah, there are some FEs it would've been nice to get in but eh

it's a beta

thank you for checking anyway, nirik . Theres always Final :)

adamw: there are two updates that needs pushing stable, but I'm sure you'll handle that

COSMIC-Atomic (x86_64 and aarch64 ostree), MiracleWM (x86_64 and aarch64 isos), Budgie-Atomic and Sway-Atomic isos.

(kmscon and anaconda-webui)

We can let websites know in the release room anything unavailable for beta

Just curious, do we have any policy whether we release spins that can't even start the installer? Sometimes that happens (currently with SoaS) and I don't think we have any policy for it, we just keep publishing it, even when broken

and I'm thinking more about Final here, not Beta

COSMIC spin, (the recular rpm one) don't start graphic session on VM

COSMIC spin, (the regular rpm one) don't start graphic session on VM

You need to enable 3D acceleration to work

I don't think we do have anything, but perhaps we should?

I have never seen any such policy, but it would make a sense not to ship such assets

I had a quick google skim (not fully into the fedora docs). It doesnt specifically say anything about the installer, but I wonder is it implied if its to be considered for a release. It would seem that that would be a pretty standard thing to be able to do

I know, I test the respins every 15 days, but this time it dind't work

I will take a look

Do we want to take an action here to look into a policy for Final?

maybe F46 is the more realistic release if so, but it might be something for F45

and I can help drive it, Id just need help with wording

I think it's causing us bad PR if we release a completely broken spin, even if non-broken. If anyone has time to design some policy regarding that, I think it would be beneficial for Fedora. I'm not volunteering, though, unfortunately

I think it's causing us bad PR if we release a completely broken spin, even if non-blocking. If anyone has time to design some policy regarding that, I think it would be beneficial for Fedora. I'm not volunteering, though, unfortunately

I can volunteer, once I can lean on a few of you for checking that what I write actually makes sense 😅

I'm wondering if we could do a very basic openqa test on them all? boot, start installer? but then thats work taken away from higher pri stuff

so perhaps just a manual test/sign off

I'm happy to share my opinions 😄

yeah, lets discuss that out of meeting? perhaps next qe meeting?

I would love to be able to do at least a basic smoke test for all spins

and to be clear, I assume the correct pathway here is: engage with FESCo on what the right basic standard should be for Spins to be release-ready via a ticket?

!hi

no worries, the bot ignores me as well

So are we picking up the spins vs installer topic in a qa meeting for more discussion before making any actions?

Well, quality folks have a process for modifying the release critera. I would think that would just be the place

We can discuss it in the next meeting, on at Discussion, both work

that makes sense to me, Im just checking where people are with it. It sounds important, I dont want it to be missed

We can discuss it in the next meeting, or at Discussion, both work

(this also kind of ties into "we need GPUs in OpenQA nodes" too)

we really are going to need 3D acceleration support in OpenQA sooner rather than later

even ignoring all the ML based stuff

So Im going to close this meeting now as we are more or less complete. Lets revisit the spins topic in the next quality meeting please and bring it forward to discourse then if there is a proposal to change criteria from that discussion

without that we can't test the cosmic spin

(you can assume I will be at the next meeting and will do any discussion posting if that helps alleviate some admin work from quality)

with that folks, we are FIN!