One of the most time-consuming criteria is this one:

All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test.

https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Default_application_functionality

We are thinking about weakening this criterion for non-Workstation graphical desktops (KDE, Xfce unless made non-blocking) and applying it to just a set of predefined important desktop apps. I believe we're fine with keeping the criterion intact for x86_64 Workstation, that's Fedora's flagship edition. But if we could also reduce the mandatory testing for aarch64 Workstation (again, to a set of predefined important desktop apps), that would of course help us. Testing the remaining (non-essential) apps would be just best effort. Because there's high chance that most of the bugs will be shared across different architectures, testing x86_64 fully should give us decent quality level even for aarch64.

One option is to say the excluded apps are no longer release blocking (so, if e.g. cheese doesn't work on aarch64, we will not block F32 release). The other option is to keep the release criterion as it is (block on cheese being broken on aarch64), but just not require mandatory QA coverage for those apps. That coverage would be QA best effort and/or community effort.

What do you think?

I'd say: from Workstation's perspective, we only care about x86_64.

On one hand, I think it's great that there is interest in testing Workstation-based aarch64 images as part of the official release process. It did look a bit weird when the official aarch64 offering was based on an alternative desktop (completely different code base etc). It really makes sense to consolidate all efforts behind the same software.

On the other hand, I don't have much interest in being on the hook for fixing release blocker issues for platforms that are (a) not widely used, and (b) I don't have hardware for.

So I'm a bit torn :) I think it's an awesome plan, just as long as it's someone else who is on the hook for fixing issues that might need urgent attention.

Also I wonder if it should get Workstation specific features same as x86_64? e.g. earlyoom, zram-generator, or if will use Workstation as a base and then diverge somehow and then by how much?

I'm here on the same boat as Kalev regarding the hardware availability and usage. I don't count my experiments with some aarch64 Libre Computer board, where I wasn't able to install Fedora on it (really didn't know how to proceed with bootloader installation). I think that before the installation documentation is improved and the installation itself is simplified (preferably by using Anaconda), then I don't see a reason why to do an aarch64 Workstation image a release blocking. But this could be reconsidered in the future.

@pwhalen @pbrobinson Can you please provide an ARM SIG point of view? Thanks.

@pwhalen @pbrobinson Can you please provide an ARM SIG point of view? Thanks.

This request came from the Arm SIG. I spoke with Christian about this back at Flock.

On one hand, I think it's great that there is interest in testing Workstation-based aarch64 images as part of the official release process. It did look a bit weird when the official aarch64 offering was based on an alternative desktop (completely different code base etc). It really makes sense to consolidate all efforts behind the same software.

We've never actually supported a Desktop officially on aarch64 so I have no idea where that statement has come from. We've been producing aarch64 Workstation images for years though, and we added XFCE images by request in F-31.

On the other hand, I don't have much interest in being on the hook for fixing release blocker issues for platforms that are (a) not widely used, and (b) I don't have hardware for.

From the PoV of aarch64 specific issues arm themselves are assisting here in terms of the driver (kernel/mesa and friends stack), if there's crashes in the actual applications it's unlikely to actually be aarch64 specific (and from experience of running it since around F-23 there's been few issues) but if it is there's people to assist.

So I'm a bit torn :) I think it's an awesome plan, just as long as it's someone else who is on the hook for fixing issues that might need urgent attention.

We've always been available, I feel there is a track record and actual trackers to back this up. This actually really is just making things official. If they're actual GNOME bugs vs architecture bugs I would expect the same from the Workstation team.

Also I wonder if it should get Workstation specific features same as x86_64? e.g. earlyoom, zram-generator, or if will use Workstation as a base and then diverge somehow and then by how much?

The images are the same as Workstation on x86_64, we have no difference in the output generated AFAICT. They've been produces for a long time (I think since around F-23) so do feel free to check them out and report back if you're aware of any delta but there's no exceptions in the installer/kickstarts, if there is it's an over sight or a bug.

Hardware can be made available for those that are actually interested in assisting/testing.

FESCo issue created, fesco#2339

If the Workstation WG wants to present any opinion on this, we're going to have to decide tomorrow because the FESCo issue is progressing.

My $0.02 is that this will be better than blocking on Xfce and reduce the chance of release slips relative to current policy, so I'm +1.

My 2¢: I'm okay with supporting AArch64 if the rest of the WG is okay with it. But someone from the WG should take point on AArch64 related issues, because it's a bad idea to keep our branding on there if nobody from the WG is involved there...

https://pagure.io/fesco/issue/2339 has been accepted