Meeting started at 2025-07-21 15:00:42 UTC

The Meeting name is 'Quality'

!hi

Adam Williamson (adamwill) - he / him / his

!hi

Vít Smolík (smoliicek)

!hi

Aoife Moloney (amoloney)

!hi

Kashyap Chamarthy (kashyapc)

!hi

Derek Enz (derekenz)

hi hi everyone

how are we all doing this <INSERT LOCAL WEATHER HERE> monday

pretty good, wbu?

Finr thx

Heh, some respite here in Ghent, after a few days of 30C (86F)

*Fine

i'm good thanks, welcome Vit Smolik

!hi

Sorry, could not get info from FASJSON (code 503)

we had one thing here: "Aoife Moloney will meet with Sumantro Mukherjee to see if she can help with announcements and co-ordination of test days this cycle" - Aoife Moloney Sumantro Mukherjee any news on that?

oh okay it's one of those days

ah, you don't exist again neal, sorry

get outta here

ok bye

Sorry took my eyes off this

on a related note, we already have one test day organization request for the very next week

Yes and no, spoke to sumantro but haven't officially 'onboarded' yet, but that's just a matter of familiarizing myself with the process. Kamil Páral: I can help organize that one if that would be helpful? Gives me a chance to get accustomed to how they work

we'll definitely not say no to a help offer 🙂

but might be best to have sumantro and/or me watching too

Yes please, happy to take you both up on that offer

this one is for the next week, if we can make it happen: https://pagure.io/fedora-qa/issue/815

if it's too soon, saying so and asking for a later date is also totally fine

there are some docs/guides linked from https://fedoraproject.org/wiki/QA/Test_Days

Ack, will take a look at this this evening. Ftr, my help will likely extend to email/discussion announcement of the test days and making sure the wiki or whatever they use is set up for the results

And coordinating with actual qa that they're being requested, obviously 😅

for the testdays app, we have a stg instance to play with. And we'll need to mark your FAS account (once you log in) as an organizer.

let any of us know if you're stuck or need help or have questions

Ok let me look at the sop this evening and some past test days and I'll know where I need some help with them 👍 thanks both!

rgr rgr

so i know this is a mysterious topic! kparal and I (mainly kparal) have been cooking up some proposals that I was supposed to start sending out last week but didn't because i'm bad at stuff

Kamil Páral do you want to share the draft here and we can talk about it? or what do you think?

!fire adamw

(You're not "bad at stuff" - you only have so much bandwidth ;-))

the bot doesn't know basic commands

i've got a bug report in somewhere for that

I think we can't share the gdoc publicly, because the company policy precludes it

but we need to publish it soon (this week!) anyway

yeah, i meant just copy/paste it to a pastebin or smth

Pastebins expire. Perhaps fedorapeople.org

it's a bit long and formatted, it would take people time to read it, I guess it's outside of the scope of this meeting, honestly. But I don't have any objections in general.

I have a question or two if that's ok...

sure

I don't think Adam is suggesting to discus all of its contents here, but perhaps an outline.

no, i was suggesting to discuss the whole thing, cos it's easier. but i forgot it was kinda long :P

Is this a proposal for feedback or is this an fyi announcement, no action from the wider community needed?

it's somewhere in the middle

Ah, I see: sure, I don't have an issue. From what I vaguely recall, most/all of that document contains analysis / review of Fedora QA land, and how best to use limited time of people.

we'd love to get feedback and useful ideas, but at the same time, we really need to publish some "proper" proposals before F43 cycle starts, so that we can still change the requirements before it's too late

so to summarize the intro: for various reasons, the RH fedora qa team is down about 50% (not layoffs, this was all just people choosing to move). a lot of work is done by the community, but the paid team is kinda backstopping some difficult areas of testing, and it's hard to guarantee that with the reduced head count

so we have proposals for specific cuts

this is the list:

Limit aarch64 release-blocking boards to just the most popular device (e.g. Raspberry Pi 4) - discussion link TBD

Ask Cloud SIG for more involvement in their testing participation - discussion link TBD

Ask KDE SIG for more involvement in their testing participation (also x86_64, not just aarch64) - discussion link TBD

We also feel that we need help from other teams in specific areas:

Proposed changes to release criteria and test coverage:

Make optical media boot no longer release-blocking - discussion link TBD

Make Intel-based Macbook dual boot no longer release-blocking - discussion link TBD

Reduce BIOS-based systems release blocking status from covering all scenarios (on parity with UEFI) to just limited scenarios - discussion link TBD

Be stricter about changes between Beta and Final (e.g. no changes to default apps in desktops, no UI/UX changes, etc), unless disclosed through a Change proposal - discussion link TBD

Discuss whether we still need to block on so many storage interfaces (Basic, Final) - discussion link TBD

Ask FESCo to consider whether IoT as an Edition still makes sense - discussion link TBD

Drop IoT hardware testing (ideally also release-blocking status) and rely just on automated virtualized tests - discussion link TBD

Require basic functionality of selected apps equally on all release-blocking desktops, i.e. drop the Workstation x86_64 exception that covers all pre-installed apps - discussion link TBD

Make desktops on aarch64 no longer release-blocking - discussion link TBD

(all the 'discussion link TBD' bits are going to be links to separate discourse threads)

This is exactly why I'm asking, the time is running short for feedback and counter-proposals :) but ye are aware of that too so that's good!

yeah, it's just been awkward timing with kamil having pto and me having the data center move

anyone have any thoughts on the general idea or any of the specifics?

would it be a terrible idea for us to create all the TBD links and post this, say, today?

(i like ambitious goals!)

could i help with that?

when you say "create all the TBD links", do you mean create all the individual proposals including all the relevant details?

optical media boot is not supposed to be release blocking already

Conan Kudo: it is

yeah, hence 'ambitious' :P more realistically, post the ones we have, maybe create a couple more, leave the others tbd

I could have sworn we downgraded this years ago...

Conan Kudo it's blocking but not mandatory testing

ahh

which is an awkward compromise we dont' like

note that FESCo cannot de-edition anything

I don't think it's doable to do all these today, if you want to have some proper explanation and data etc included, but this week, hopefully

so that needs to go to Council

I don't think it's doable to do all these today, if you want to have some proper explanation and data etc included, but this week, hopefully yes

Edition status is at the pleasure of Council, not FESCo

limiting aarch64 release-blocking hardware platforms makes sense to me as it is

Seems fair

> Ask Cloud SIG for more involvement in their testing participation - discussion link TBD

it's super-hard for even us in KDE SIG/PSWG to test reasonably when we don't know what to prioritize

Seems fair

> Ask Cloud SIG for more involvement in their testing participation - discussion link TBD

Jeremy Cline that boils down to 'have someone other than me do the real-cloud testing sometimes'

and doing it earlier than 'morning of the go/no-go meeting' would be nice too :P

Agreed

also, automating it would be *best*. that's been in the middle of my todo list forever but i never get the roundtuits

I think that's achievable... tbh, we've had a todo for months for cloud sig to have automated smoke testing

jinx

Yeah, I'd like a companion for the image uploader that tests things for AWS/Azure/GCP

ftr, we would create some process of reminding teams what needs to be done and when

i can help with the wiki report-y bits if somebody just writes the damn...thing

the suse guys have img-proof as a testing apparatus, but I don't think we can reuse that

There's also a dedicated Azure test suite, so there's lots of stuff out there

but it could be the inspiration for our own

thanks for the offer, I know you joined recently. You can definitely help us with F43 release validation once it's ready, that would be very appreciated. Also participating in test days, etc.

adamw: the larger question I have is related to our OEM testing

that is naturally going to be impacted too, so... how do we handle this?

alright! i'm sadly not gonna be home on the Anaconda installer test day :(

but i'll catch the next test day

Vit Smolik: it's usually a week, or at least a couple of days, so you can participate any time. Even later, after it's over, it's still valuable to see bug report - there's just no real-time dev support in the test day matrix channel (but anaconda devs can be found in their own channel any time)

Vit Smolik: it's usually a week, or at least a couple of days, so you can participate any time. Even later, after it's over, it's still valuable to see bug reports - there's just no real-time dev support in the test day matrix channel (but anaconda devs can be found in their own channel any time)

Conan Kudo how do you mean, exactly?

sorry, I'm not clear what OEM testing refers to

he means framework, lenovo etc i think

yes

we have never quite got around to formalizing that

i swear i did a wiki draft once but i can't find it

aside from a couple of exceptions, all that stuff went to the Brno lab

with the assumption that it was being tested there

i specifically held off doing it this last quarter because of this headcount issue

adamw: you can probably find it in your wiki history page :)

we'll still have kamil and lukas there, so it's still the 'best' option

Conan Kudo nope

it's not in lab, we have it around and sometimes use it for bare metal testing, lruzicka even uses one of the systems as a production laptop. But fewer people in the team of course means fewer people to play with it.

*possibly* i did it on the staging wiki and it got synced away, can't think of any other explanation, but ah well, it wasn't that much work

but OEM testing is not directly related to our proposals, so I haven't included it in the summary draft. It's a separate topic.

> Reduce BIOS-based systems release blocking status from covering all scenarios (on parity with UEFI) to just limited scenarios

What is there to reduce? AFAIK, the automatic testing openqa does should be sufficient for this

I have a more detailed proposal drafted, but in essence we'd like to **block** on just a default BIOS install

what does "default" mean?

no custom partitioning layouts, no fancy storage types, etc. But this is exactly something that needs feedback from e.g. the Server sig

straight through install in a VM with a single disk

I see.

well, also on a 'normal' bare metal machine i guess

but ehhh

I'm guessing we currently don't encode these different methods in OpenQA testing?

as kamil said, it's kind of a 'run it up the flagpole' exercise

we do a lot of scenarios in openqa, but only run a few of them on bios

previously we did the opposite - ran most tests on bios, duplicated a few for uefi

I see.

I'm not completely opposed to it.

then a couple of years back i flipped it so the default is uefi and we also run a few on bios as a test

right

we could probably run more now as we have some more capacity, but it's more noise to cope with in the results, failures need to be investigated...it's still not free

Then, probably best to save that time for something else, IMHO.

yes, this is about shifting our time from less valuable stuff (e.g. too old, too niche), to more valuable stuff. Because we're currently very limited on time.

do we have some kind of metric how much of the users still use bios and not uefi?

no

I'd hesitate to drop the Intel Macbook dual-boot criterion just yet, but I think it's worth discussion adding a timeline to ending it since Apple is dropping Intel Mac support with next year's macOS release

and I want to highlight that there's a difference between blocking on something and testing something. The proposals usually want to drop the blocking part. Because even if we drop testing, we still need to deal with blocker proposals, when they come up. And blocking on stuff we don't test feels wrong to us anyway.

I frankly expect most users to move to UEFI

with the retirement of Intel Mac support with macOS 27, I don't think it would be reasonable to maintain dual-boot with macOS as release-blocking

(this year's release is macOS 26)

the situation is a bit more complex with Macs - Macs with T2 chips don't work well with Fedora anyway, so the latest functional model is from 2017, and its Apple support just ends this year.

yes

Yes all valid points

but this just shows that we need to publish at least some of the proposals and kickstart the discussions, adamw

though t2linux is slowly upstreaming their stuff and there's a downstream build of Fedora Workstation and Fedora KDE with t2linux enablement

and nobody said AH GOD NO DON'T POST THIS

well....

> Make desktops on aarch64 no longer release-blocking - discussion link

This one I don't really want us to do

Kamil Páral maybe we should post it today with the proposals we actually have, and leave out the text for proposals we *haven't* drafted yet, instead have a sort of 'more proposals coming soon!' text there?

that was my expectation, Neal 🙂

Conan Kudo: Are there non-trivial portion of users who care about aarch64 desktops?

😆

that's probably the most radical proposal, yeah. Kamil Páral did matt/jef have some numbers on desktop aarch64 usage?

Agreed

I expect most teams to be angry, but that's why we start with the summary, to show that this really impacts everyone, it's not targeted against something particular

Yes. And it's a growing segment on the Fedora KDE side, in large part because we're actively promoting it that way.

But the challenge is that Fedora ARM's release blocking platform criteria feels like a mess right now.

i think we had some discussion that fedora is just so slow for desktop purposes on SBCs that most people wind up using the distros with out-of-tree patches?

I just replied to this above. Both approaches will potentially backfire, so... shrug.

With the RPi4 platform, at least Fedora KDE is reasonably performant

Yep

Workstation chugs, but the larger problem is that GTK4 just flat out crashes on RPi systems since moving to Vulkan

I see. Would it be reasonable to say that the Fedora KDE community should "take over" responsibility for this? :)

The point is that it has way too little userbase, at least according to some data estimates from Mattdm. And testing desktops on arm is one of the slowest thing to do in QA.

... we already kind of do?

QA already doesn't test Fedora KDE on ARM

we do

this is going to hurt Workstation more than KDE

while that's mostly true, we still need to deal with the bugs

yeah, there is the triage bit and verification stuff

admittedly we are trying to be more proactive on that front too

at least I own an RPi400 for Fedora KDE ARM testing

this is a good example that I really want the proposals to have separate discussions, because some of them will be lengthy 🙂 We're certainly open to any useful solutions, we just want to communicate that we no longer can do all of this, in our current capacity.

ok

we're at the end of the time slot

(I have a hard-stop in 5 mins, afraid.)

so...kamil, let's work together to come up with a plan to post something soon now

ok

Sumantro Mukherjee anything?

alrighty

anything else wildly important?

nothing else from me

alrighty, thanks for coming folks!

Thanks Adam

thanks adam, see you next time everyone :)

thanks, bye

Bye

byeee