Fedora's 32-bit ARM Xfce Image Demoted While Fedora Workstation AArch64 Gets Promoted

[AdamW]

They've been cutting back on spins available, architectures available, etc. It gives the appearance that they don't have the manpower they once had to maintain all that they want to maintain. It's like when a random business starts cutting employees, hours, and services provided to do whatever they need to do to stay afloat. It gives that downward spiral appearance...at least that's the way I read it...

What's happening is actually more or less exactly the opposite: we're picking up *more* stuff, which means we need to trade off resources spent testing existing stuff.

Part of the background to both this and the other desktop test changes 144Hz mentions is that Fedora CoreOS and Fedora IoT are both becoming release-blocking editions. Silverblue is also an increasingly important effort. So it's increasingly less feasible for us (the QA team) to be spending a very large chunk of our time doing exhaustive testing on *three* different desktops: GNOME, KDE and Xfce. (The brief history of Xfce is: we wanted to have a supported desktop on 32-bit ARM, for a while it was KDE, then we decided that KDE on 32-bit ARM basically sucked so we'd just make Xfce release-blocking instead, then over the next few years we started kinda regretting the workload that adds, le end).

So we started talking about maybe not covering KDE quite so exhaustively, because it ships...so...much...damn...*STUFF* (it takes about 2-3 hours to run the 'launch everything in the menus and check it basically works' test on GNOME; it takes anywhere from 4 hours to two days to do it for KDE, depending on how conscientious you are about it). And we also talked to the ARM folks and said 'so, uh, how much do you really care about Xfce on 32-bit ARM?' and they said "oh not really much at all, in fact we'd been meaning to propose switching to Workstation on 64-bit ARM for desktop ARM blocking purposes, we just didn't get around to it yet". So that synced up nicely.

[AdamW]

BTW, to talk a bit further about spins and arch support: most spins are maintained by community members, who tend to come and go, and stop caring about things sometimes. So they're inherently a bit...ephemeral. If the one person who really cares about making the Foobar Desktop Spin moves distro, or decides they just don't really like Foobar Desktop any more...the spin's probably gonna go away. We got a bit more aggressive about 'garbage collecting' spins that are not actively maintained any more, as well, which makes it more obvious when this happens (in the past they tended to sort of technically still exist, but be really broken or just not compose at all). The spins and editions that are kind of 'core' to Fedora are basically Workstation, KDE, Server, CoreOS, IoT and Silverblue at this point; that's a set that's been gradually getting *bigger* over time, not smaller. (Before Fedora.next the equivalent set was approximately "the GNOME and KDE desktops and the minimal install"; right after Fedora.next it was Workstation, KDE, Server and Cloud).

For arches, I'd say we're gradually extending arch support, not dropping it. There was a very significant change a few years ago where the status of several arches was effectively upgraded: these days, package builds must work (or be explicitly excluded) on x86_64, 32-bit ARM, 64-bit ARM, ppc64 and s390x. If any of those fails, the build is considered bad and not tagged. Before that change, it was only (IIRC) i686 and x86_64 (possibly also 32-bit ARM, I forget), all other arches were run separately and if they failed the package build was still considered 'good'.

32-bit and 64-bit ARM are officially primary arches these days, and we care quite a lot about ppc64 (no, this is not just an IBM buyout thing, it predates it by a couple of years) - we work closely with a few IBM ppc64 folks to ensure things keep working, we have automated testing on ppc64 and stuff like that.

[Britoid]

lowlands Fedora might also cut back on KDE.

https://lists.fedoraproject.org/archives/list/[email protected]/thread/HNXF7WCYQ7RAKMNGCIOXCBXERBAK44TK/

No censorship can hide the fact that the few viable distributions are cutting back on options. Less inits, less display servers, less packaging formats and less desktops.

A much welcome change I would say

You know it's possible to say things without trying to sound like an arsehole?

[wizard69]

They've been cutting back on spins available, architectures available, etc. It gives the appearance that they don't have the manpower they once had to maintain all that they want to maintain. It's like when a random business starts cutting employees, hours, and services provided to do whatever they need to do to stay afloat. It gives that downward spiral appearance...at least that's the way I read it...

That is a bit of a foolish view in my opinion. I say this because I always saw the “spins” as a waste of effort, time and money. The combination of RPM and DNF allows one to configure Fedora’s base distro to suite many needs effectively making spins a waste of resources.

So I don’t see a downward spiral but rather a correction of what amounts to a stupid mistake. One of Linuxs biggest issues is the problem of too many distros, adding spins just dilutes the solution space even more. People want to drive adoption but then confuse new users or even professional user with all the various choices. Choice is good but when a group like FedorA tries to market so many spins it just leaves potential users frustrated.

[wizard69]

What's happening is actually more or less exactly the opposite: we're picking up *more* stuff, which means we need to trade off resources spent testing existing stuff.

Part of the background to both this and the other desktop test changes 144Hz mentions is that Fedora CoreOS and Fedora IoT are both becoming release-blocking editions. Silverblue is also an increasingly important effort. So it's increasingly less feasible for us (the QA team) to be spending a very large chunk of our time doing exhaustive testing on *three* different desktops: GNOME, KDE and Xfce. (The brief history of Xfce is: we wanted to have a supported desktop on 32-bit ARM, for a while it was KDE, then we decided that KDE on 32-bit ARM basically sucked so we'd just make Xfce release-blocking instead, then over the next few years we started kinda regretting the workload that adds, le end).

So we started talking about maybe not covering KDE quite so exhaustively, because it ships...so...much...damn...*STUFF* (it takes about 2-3 hours to run the 'launch everything in the menus and check it basically works' test on GNOME; it takes anywhere from 4 hours to two days to do it for KDE, depending on how conscientious you are about it). And we also talked to the ARM folks and said 'so, uh, how much do you really care about Xfce on 32-bit ARM?' and they said "oh not really much at all, in fact we'd been meaning to propose switching to Workstation on 64-bit ARM for desktop ARM blocking purposes, we just didn't get around to it yet". So that synced up nicely.

Nice to hear from somebody from Redhat / Fedora on this. Personally I really see spins as a big mistake, especially if you want to get new users involved. For experienced user it doesn’t matter.

The problem is spins adds confusion and don’t offer anything significant over a base installation. I would love to see Fedora / Redhat put more effort into groups of software are discovered and installed. Audio tools, TexLive and Engineering groups are good examples of areas where the installation of such software could be improved.

[skeevy420]

What's happening is actually more or less exactly the opposite: we're picking up *more* stuff, which means we need to trade off resources spent testing existing stuff.

Part of the background to both this and the other desktop test changes 144Hz mentions is that Fedora CoreOS and Fedora IoT are both becoming release-blocking editions. Silverblue is also an increasingly important effort. So it's increasingly less feasible for us (the QA team) to be spending a very large chunk of our time doing exhaustive testing on *three* different desktops: GNOME, KDE and Xfce. (The brief history of Xfce is: we wanted to have a supported desktop on 32-bit ARM, for a while it was KDE, then we decided that KDE on 32-bit ARM basically sucked so we'd just make Xfce release-blocking instead, then over the next few years we started kinda regretting the workload that adds, le end).

So we started talking about maybe not covering KDE quite so exhaustively, because it ships...so...much...damn...*STUFF* (it takes about 2-3 hours to run the 'launch everything in the menus and check it basically works' test on GNOME; it takes anywhere from 4 hours to two days to do it for KDE, depending on how conscientious you are about it). And we also talked to the ARM folks and said 'so, uh, how much do you really care about Xfce on 32-bit ARM?' and they said "oh not really much at all, in fact we'd been meaning to propose switching to Workstation on 64-bit ARM for desktop ARM blocking purposes, we just didn't get around to it yet". So that synced up nicely.

I was just referring to how I read "downward spiral" in the context of that user's post and not my actual thoughts on Fedora. Between Fedora and Red Hat, lots of interesting stuff coming out these days and "downward spiral" wouldn't be my first description. I could have made those points a little more clear (I thought adding "at least that's the way I read it" was enough).

But I do appreciate the response and had a chuckle about y'all making the same (suggestively bad) decision I'd have made in the same situation -- go with XFCE.

And that last part about KDE makes me sad. Good KDE coverage is the most important aspect of a distribution to me and why SUSE Tumbleweed and Manjaro KDE have become my go-to distributions...only I don't care for the way SUSE does things and Manjaro is pushing crap too fast for their own good. \

For Manjaro, a distribution with a focus on ZFS should not push Linux 5.5 until they update their ZoL base to a git revision with Linux 5.5+ support or they should sit their happy ass on Linux 5.4 until the next ZoL release that includes Linux 5.5 support is released. Or if I didn't read my damn logs this morning I'd have rebooted into a non-working system. I have a feeling that bullshit like that doesn't usually happen with Fedora.

One can argue that Gnome shipping less stuff and being easier to test initially as a bad thing for the long term -- by that I mean that including less software means the end-user will have to install more software to get a complete system which then adds more complexity and issues for bug fixers, quality assurance, etc -- Pay a little bit more now or pay a lot more later.

[Britoid]

I was just referring to how I read "downward spiral" in the context of that user's post and not my actual thoughts on Fedora. Between Fedora and Red Hat, lots of interesting stuff coming out these days and "downward spiral" wouldn't be my first description. I could have made those points a little more clear (I thought adding "at least that's the way I read it" was enough).

But I do appreciate the response and had a chuckle about y'all making the same (suggestively bad) decision I'd have made in the same situation -- go with XFCE.

And that last part about KDE makes me sad. Good KDE coverage is the most important aspect of a distribution to me and why SUSE Tumbleweed and Manjaro KDE have become my go-to distributions...only I don't care for the way SUSE does things and Manjaro is pushing crap too fast for their own good. \

For Manjaro, a distribution with a focus on ZFS should not push Linux 5.5 until they update their ZoL base to a git revision with Linux 5.5+ support or they should sit their happy ass on Linux 5.4 until the next ZoL release that includes Linux 5.5 support is released. Or if I didn't read my damn logs this morning I'd have rebooted into a non-working system. I have a feeling that bullshit like that doesn't usually happen with Fedora.

One can argue that Gnome shipping less stuff and being easier to test initially as a bad thing for the long term -- by that I mean that including less software means the end-user will have to install more software to get a complete system which then adds more complexity and issues for bug fixers, quality assurance, etc -- Pay a little bit more now or pay a lot more later.

Less extensions more apps is actually something that comes up in the GNOME-sphere a lot.

[skeevy420]

Less extensions more apps is actually something that comes up in the GNOME-sphere a lot.

I didn't even want to bring up the point, more of a personal opinion point, that Gnome is almost unusable to me without a few plugins. I can manage, but it isn't what I'd call an enjoyable experience. Add a few plugins, tweak a few new settings, and I'm a relatively happy camper. At that point I might as well be using Plasma since it has the look, feel, and settings I think a desktop needs all OOTB (or at least available...like some distributions not including red shift/anit-blue OOTB..whatever TF that term is called).

[tildearrow]

Considering there is no post by "144Hz" above that of "tildearrow"...

I wonder if this is an open admission that there is a moderator present in these forums ... other than Michael and perhaps his wife.

There was a post above mine.

[AdamW]

And that last part about KDE makes me sad. Good KDE coverage is the most important aspect of a distribution to me and why SUSE Tumbleweed and Manjaro KDE have become my go-to distributions...only I don't care for the way SUSE does things and Manjaro is pushing crap too fast for their own good. \

One can argue that Gnome shipping less stuff and being easier to test initially as a bad thing for the long term -- by that I mean that including less software means the end-user will have to install more software to get a complete system which then adds more complexity and issues for bug fixers, quality assurance, etc -- Pay a little bit more now or pay a lot more later.

I mean...obviously having to test it is a bias, but a lot of the stuff in Fedora's KDE spin is stuff that is just really not *necessary* at all. Stuff like...I don't know how many there are right now (at least two), but it's shipped three different package managers on the live image in the past. Because, I dunno, choice! or something? So that means we get to test not one but three package managers. And block the release if any one of them is broken. Fedora KDE ships Konqueror, Firefox, Krusader *and* Dolphin, all on the live image. It ships a 'TNEF file viewer', which means if you're trying to do the job properly you need to have a TNEF file lying around somewhere and know what it's supposed to look like. It ships QDbusViewer in the frickin' app menus, for some reason. It ships an Automatic Mouse Clicker?

The KDE control panel has controls for *every goddamn thing in the world*, even things that make absolutely no sense whatsoever. I think they finally fixed this, but it's still my favourite example: at one point it had a setting for the xkb geometry. The *only* thing that actually affects is how xkb draws a little illustration of a keyboard layout if you ask it to...but KDE didn't actually *use* xkb to draw little illustrations of keyboards, it did it itself, and it ignored that setting! So it was literally entirely useless. The general KDE approach to making a configuration GUI is 'take literally every possible setting from the underlying config file and expose it as flexibly as possible'. This is a freaking nightmare for testing. Keyboard config is still the best example of this - there is a checkbox in the KDE keyboard config thing marked "Maintain key compatibility with old Solaris keycodes". Is this *really* a thing the GUI needs to expose? There are *eight separate choices* for "Numeric keypad Delete behavior". These are all things that someone, somewhere in the world needs to set (or needed to set sometime in 2003, sometimes), I guess, but do we really need a checkbox for every damn one? In the main KDE control center?

Anyway, yeah. This is why we maybe don't want to be on the hook for absolutely everything in KDE working any more.