I agree. Both DEs can be used for gamers, developers, normal users alike. Heck, in the last couple months we’ve been putting a decent amount of effort in making the KDE spin more comfortable for developers by reintroducing kdoctools and baking the building of qt development headers in our frameworks (Those qch files).
1 Like
I would love this, so +1 for it!!!
However, i still think they should be marketed as
Gnome Workstation
&
Plasma Workstation
and users should be given the chance to choose any of these two “equally”.
(edit:
i also like the solution suggested at:
where the Workstation installer had - in itself - the choice between the two Desktops - at installation time - would not only provide equal status but also avoid the creation of 2 different editions )
2 Likes
I want to share my quality-team -related sentiment not towards KDE, but rather Council/FESCo. With my Quality hat on, I feel that Fedora keeps on adding and adding, but forgets to remove as well. Regarding “important things” that need to be tested, in the not-that-distant past we added aarch64, IoT, CoreOS, Toolbox container images, KDE on aarch64 (right now in F41), just from top of my head, probably forgetting many other stuff. All of those are now release-blocking. All of them are expected to be released with a high level of quality. At the same time, we never let go of stuff. We still block on CD-ROM, for crying out loud (at least we’re not obliged to test it anymore, but still blocking). We still block on BIOS, X11, and similar “old stuff”. But the QA team and QA community is far from growing. It’s just automation that saves us, partially.
So far, KDE received a smaller portion of our test time than Workstation, because obviously Workstation is an Edition, a primary product. (KDE is also much harder to test, given how crammed it is with apps and tools by default). I don’t think this is going to change, because we simply have no free time to spare. The KDE SIG might not have any expectations in this regard, related to this proposal, I have no idea, but inevitably, in the future, people will start demanding that QA focuses more on KDE, “because it’s now also an Edition”, and be angry if we don’t/can’t. This post is my attempt to set expectations right in advance, but I’m sure it will happen anyway.
Just right now, in the F41 cycle, KDE on aarch64 became release blocking, even though I presented similar QA-related arguments (and I don’t see any existing large user base indicating that it was the right move). At least we agreed that the KDE SIG will handle testing on that image themselves. So far, we haven’t seen much results, and we had to test F41 Beta ourselves instead. (Just recently I posted a release validation tutorial to the KDE list, in hope that the situation improves for F41 Final). So I don’t see any testing track record at the moment.
I hope this is taken into consideration by Council/FESCo or whoever decides this. It’s not targeted against KDE at all (I’m personally very glad that there’s a usable alternative to GNOME with a decent level of quality, even though I’m not convinced that it needs to be presented at the same importance level), it’s targeted against the approach of just adding stuff without removing. QA time is a finite resource, and either we focus, or dilute it. We need to find the right balance.
7 Likes
Starting with Fedora 41, we should no longer be blocking on X11. Both release-blocking desktops do not ship X11 on any deliverable media.
Yes, we probably should drive more growth in the Fedora QA community, including actively mentioning it as a contribution path in release parties and other venues so that the group has much more visibility.
We also should push more for automation-centric validation, but I’m not sure how we can do that with our infrastructure contraints. 
Before saying things like this, please actually verify this. Aside from the addition of KMail; NeoChat; a few KDE games; and LibreOffice shortcuts that were excluded from Workstation, the application set is mostly at parity. We have actually trimmed things down a fair bit over the years. We deliberately ship NeoChat to make access to the Fedora community via Matrix more accessible. We also already have an agreement about what apps “count” for release-blocking status, and things like the games aren’t part of that list.
Honestly, then use that as an avenue to ask people to help with testing.
The KDE SIG itself is doing its own bring-up for AArch64 QA efforts. We literally started as soon as the Change was approved. And we are trying to figure out a recruitment program for building out general KDE QA.
We can certainly talk about helping to increase the QA community and engagement with Fedora QA.
I appreciate that you sent the email to help people navigate reporting their testing. We are working on this and I will also start sending people to Fedora Quality to report to you folks rather than just to us internally. It’s not that there isn’t testing, it’s just that typically it just happens to us directly and we address them as they come.
4 Likes
This is one of the reasons I’m excited about “image mode”. I posted some thoughts kind of randomly in Base fedora image for constructing containers - #3 by mattdm. In the ideal world, we have a Base Runtime (*cough*) shared by (in the ideal) all our blocking deliverables. I think this layered structure can really help simplify the Quality team burden:
- Only one base to test for everything.
- More rigor and resources can be focused on ensuring the inner levels are solid, and explicitly less from Quality directly on the higher levels.
- Unlike prior minimization efforts, there is a tangible, immediate, and lasting benefit to moving packages out and up.
- A team working on a Spin or Edition starts with
from:fedora/ring3(the "Consensus Common Core[1]). They can be confident that that everything up until that line should just work, and be able to focus on their specific changes.[2]
With this, we can push more release-validation work to the Edition and Spin teams. We could even realize my ancient dream of pushing the release call for their own deliverable to that team, and not block on anything above the Consensus Common Core
We can (future-tense “can”) even build package mode (traditional rpm) deliverables using the image mode build pipeline, “flattened” as a last step. (As I understand it, @jligon is working on this.)
see the other message for more, but the rule of this layer is: everything common between all of the Editions, with implicit veto for every team that wants it smaller. Nothing to argue about — just move that thing up a layer. ↩︎
On the inner side of the line, I imagine a renewed “Base System Working Group” with ownership of the lower layers. I expect since the Edition Working groups do care about the end-to-end, they’d want to participate here as well (but wouldn’t have to). ↩︎
3 Likes
Wasn’t that discussion, like, five years ago? I bet we could successfully revisit.
I don’t think this is the panacea you think it is. In practice, we already have layering through composition groups. Almost every Fedora deliverable derives from the same basic set of components, but that doesn’t change the fact that the integration of those components is what changes things. You can’t actually test them in isolation and expect those test results to propagate up to changed environments.
The top down test model makes more sense for integration than a bottom-up one like you propose. Your suggested model might actually make things worse because the assumption of quality is not validated and enforced at the upper layers where the user experience exists.
A simple example: the Raspberry Pi 4 series graphics driver works totally fine on its own in a simple case, but integrate it with the GNOME deliverable or the KDE Plasma deliverable, and you get two distinct sets of seriously broken results. We have spent the past several weeks chasing bugs that only exist when you stack everything together. “Common core” is functionally not testable in a useful way for issues like this. And these make up the bulk of our problems every cycle.
2 Likes
Yes, I mentally jumped ahead a bit, sorry. One of the arguments for blocking on every app in Workstation and just selected apps on KDE was that Workstation is an Edition, while KDE is not. When KDE also becomes an Edition, that argument is no longer valid, and I expected KDE folks to request parity there as well.
No, we are comfortable with the current state there, and we like that flexibility, so we will retain it.
1 Like
I don’t think it’s a panacea. I do think it gives us benefits. Comps groups aren’t very well maintained, and we don’t test them as groups.
Yes, we’ll definitely need end-to-end integration tests.
Well, the Fedora Atomic Desktops are heavy users of comps groups so while we certainly don’t test them independently of one another, they are maintained and work well for this use case at least.
I think the maintenance of the composition groups is improving, especially as we increase our reliance on them with things like kiwi, atomic desktops, etc.
Some of the basic tests added to comps have helped a lot, and kiwi descriptions CI on every change to the descriptions (which implicitly verify the comps groups too).
3 Likes
We discussed this at length at today’s Council meeting. We haven’t made a decision but do have next steps. You can read the meeting log here:
4 Likes
Can anyone vote on this? If not, what are the specific requirements to vote?
Only Fedora Council members are allowed to vote. Votes occur over on the original ticket. However, the Council intends to split this into two separate decisions:
- Should the policy around Edition promotion change to allow this? If not, the Council feels they will need to grant an exception for Fedora Personal Systems’ KDE Desktop Edition.
- Should Fedora KDE be promoted to Edition status under the Personal Systems WG? That is the question posed in this thread.
I have requested that the decisions be made before Fedora 41 GA, and it was indicated that will be possible to accommodate.
1 Like
Hi, as a KDE dev I would love to see this happen.
Fedora KDE has been the perfect dev platform for me when working on KDE software (and my gamedev projects!). It’s also been awesome for gaming. I went to use Arch for a while, but I enjoyed Fedora KDE experience so much I hopped right back to it!
I believe if Fedora KDE can be shown on the front page like the Workstation edition is, this would help more users to find our software. Which in turn helps with more bug reports and testing, which turns into better software. 
I hope I didn’t disturb this post with unnecessary noise or anything. Just wanted to mention that having more visibility for distros that have KDE software running from the get-go is very helpful for us, too!
So thanks for considering this!
2 Likes
Looks like this passed! How exciting! Issue #504: Request to upgrade Fedora KDE Desktop Spin to Edition status under the Personal Systems WG - tickets - Pagure.io
6 Likes
Wow that’s big
Great. I know many Fedora KDE users that will be happy.
Ah. Let’s pay attention to announce it in the proper way. I’ve already read comments like: “why? What happened?”, “wasn’t GNOME sponsored by Red Hat?”, “is it related to recent news about GNOME financial woes?” and the classic speculations and conspiracy 
3 Likes