+1

Based on the discussion in the Discourse ticket, I'm voting -1 here. Fedora QA asserts that it doesn't have the capacity to test another blocking medium and Infra asserts that bugs in the compose cause it to fail for as-yet-unknown reasons roughly 50% of the time.

FWIW, I run Fedora KDE on aarch64 (VM on Apple Silicon), so I'm not voting -1 lightly here.

Based on the discussion in the Discourse ticket, I'm voting -1 here. Fedora QA asserts that it doesn't have the capacity to test another blocking medium and Infra asserts that bugs in the compose cause it to fail for as-yet-unknown reasons roughly 50% of the time.

FWIW, I run Fedora KDE on aarch64 (VM on Apple Silicon), so I'm not voting -1 lightly here.

Wrt testing resources, please see this comment: https://pagure.io/fedora-kde/SIG/issue/526#comment-918078

To summarize: the Fedora KDE SIG is aware that there are no resources available from the project for it, and thus it will be expending its own if this Change is approved.

Secondarily and regardless of this Change, I am exploring moving all Fedora KDE artifacts from lorax to kiwi to get out of this mess.

(To make it abundantly clear, I as Fedora KDE lead will not ask people to buy hardware to do testing if there's no value in doing so. Being unfunded means everyone is doing things out of their own pockets and if KDE AArch64 isn't release-blocking, I will not ask people to buy hardware with their own money to do the testing every cycle.)

https://discussion.fedoraproject.org/t/f41-change-proposal-mark-fedora-kde-aarch64-as-release-blocking-system-wide/120250/8:

IMHO, if there are enough people testing quickly enough for every release for at least 2 releases in a row, we can talk about making it release blocking but making something release blocking before we get to that point is going to make life more difficult; adding release requirements does not make testers materialize.

I think we should make such a requirement.

Also, I think we should wait until the image building is more reliable. I hope the move to Kiwi will achieve that. With 50+% failure rate, things would be very painful if we made that image blocking.

So -1 for now.

I can drop the AArch64 live ISO blocking status for now, and change it once it's moved over to kiwi.

https://discussion.fedoraproject.org/t/f41-change-proposal-mark-fedora-kde-aarch64-as-release-blocking-system-wide/120250/8:

IMHO, if there are enough people testing quickly enough for every release for at least 2 releases in a row, we can talk about making it release blocking but making something release blocking before we get to that point is going to make life more difficult; adding release requirements does not make testers materialize.

I think we should make such a requirement.

I don't think you understand how much of a problem this is: all of us have to buy stuff and spend time doing it of our own accord. Members of the SIG are willing to commit if and only if we have the requisite status to make it meaningful. There is no point in doing it if we wind up doing engineering work only to not be able to get them into the GA release because we don't have blocking status for the work to even matter.

We already spend a lot of time on Fedora KDE for AArch64 because of prominent downstreams like Fedora Asahi Remix, but we want to shift more of that upstream.

Another data point, Fedora KDE is already the next largest set of desktop AArch64 deployments at half the size of Fedora Workstation, and it's continually trending upwards.

From @farchord's charts of the countme data:

For the sake of clarity, because I didn't put labels on axises (It was 11:30pm...)
The X axis is the week's Start Date (Each data point is based on a week number)
The Y axis is a total sum of the hits in the countme database

To address @adamwill's concern, I've updated the pungi-fedora PR so that we don't block on live media on AArch64 yet. There is no time for me to look into it this cycle, but next cycle, we will move our artifacts to kiwi.

This sounds like a good compromise. +1

I'd rather drop stuff that nobody is interested in any longer from being release blocking than block spins that are actively being worked on by a relatively large number of community members from becoming release blocking.

This was discussed in today's meeting, but we did not reach a conclusion. A few of us would like to see ARM SIG involved before making a decision.

cc @pbrobinson - apologies for the late reach out, could someone from the ARM SIG weigh in on this either in the ticket or at a FESCo meeting?

This was discussed in the meeting, approved (+7, 0, -0) and announced in the minutes:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/72M3MGF6YXXRPFT6ZEUQ5LSSQG6QQKD2/

This was discussed in today's meeting, but we did not reach a conclusion. A few of us would like to see ARM SIG involved before making a decision.

Apologies, I have only just seen this. For the record I am not opposed to this but the arm SIG doesn't have the bandwidth to explicitly test this, and in the past when we're reached out to the KDE SIG we've never had feedback so I do have concerns here similar to @adamwill

This was discussed in today's meeting, but we did not reach a conclusion. A few of us would like to see ARM SIG involved before making a decision.

Apologies, I have only just seen this. For the record I am not opposed to this but the arm SIG doesn't have the bandwidth to explicitly test this, and in the past when we're reached out to the KDE SIG we've never had feedback so I do have concerns here similar to @adamwill

The KDE SIG is ramping up its own efforts independently of the ARM SIG. Hardware acquisition is the first step and being tracked here: https://pagure.io/fedora-kde/SIG/issue/543

The KDE SIG is ramping up its own efforts independently of the ARM SIG. Hardware acquisition is the first step and being tracked here: https://pagure.io/fedora-kde/SIG/issue/543

It would at least be nice to have some communications and coordination.

There are already a few of us in the Fedora ARM Matrix room. @farchord in particular has been talking in there and asking about stuff for a while now. I've been there too for quite a long time, and when needed I do talk to ARM SIG folks, I can and do reach out.