Peter Boy wrote:
> I'm probably not the right person to comment on this, because I completely
> abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That
> destroyed my daily workflow and work routines and made it unusable (for
> me), or at least barely usable for serious professional work not related
> to software development (and I ended up using MacOS to this day).
Which is exactly why I proposed back then to make Plasma (which actually
operates more similarly to GNOME 2 than GNOME 3 does) the default. :-)
>> == Summary ==
>> Switch the default desktop experience for Workstation to KDE Plasma.
>> The GNOME desktop is moved to a separate spin / edition, retaining
>> release-blocking status.
>
> This is an absolute no-go! It would break everyone’s usage of Fedora
> Workstation
It would be a major change, yes. Though not really different from the
aforementioned upgrade to GNOME 3 with its completely redesigned user
experience, which was also done.
If Workstation were never allowed to change its user experience, it would be
shipping MATE nowadays, not GNOME.
> and is in irreconcilable contradiction to the characteristics of an
> „Edition" as defined with Fedora.next.
How so?
> And that is not „just“ a technical issue (the FESCo domain), but a basic
> Fedora principle.
If you believe a basic Fedora principle is being violated, please bring that
up with the Council.
> Another proposal is to make it an „Edition“. But basically, a merely KDE
> Desktop is not „edition-able“. Among others, an edition is meant to cover
> a specific use case and a long-term and (more or less) perfectly designed
> and engineered solution for this. So we have desktop (Workstation) and
> server. Among server we have several Editions, the universal Fedora
> Server, container centric CoreOS, edge centric IoT and Cloud. Each of the
> server-like Editions covers a destined, specific use case without
> overlapping.
>
> For the desktop area I don’t see a non-overlapping use case between Gnome
> and KDE. It’s just a different tool for the same use case.
This exact argument was already used 10 years ago to reject our (that was
before I left the KDE SIG, though this issue was one of the triggers for me
leaving the SIG) request for a Plasma Edition. 10 years later, we still have
no way out of this dilemma. The definition of an Edition needs to be refined
or completely replaced to get out of this catch-22.
As part of the process to look for a non-overlapping use case, there was an
attempt to focus specifically on scientific applications, which eventually
lead to the Scientific Lab, but that did not make it to an Edition either,
just to a Lab.
The overlap issue is also going to hinder other deliverables' efforts to
become Editions. E.g., Silverblue mostly overlaps with Workstation and
CoreOS: Workstation for the general use cases (workstation/desktop usage),
CoreOS for the atomic and container-oriented use cases.
> And if we are willing to accept an exception and accept KDE desktop as an
> Edition, I don’t see that the current SIG qualifies as an edition-capable
> working group. Given the recent discussion about Wayland / X11, I don’t
> see any obligation/commitment to ensure long-term reliability and
> trouble-free usability. Instead, I see in the discussion an unbridled
> desire to introduce something new (that's good) without regard for
> backwards compatibility and uninterrupted usability (that's bad, we need
> both). And obviously the resources to manage both (Wayland and X11) in one
> working group are also lacking (and given the schism, possibly also the
> willingness to do so).
That particular concern, however, is one that I also share. The working
group should be required to accept at least one of us plasma-workspace-x11
maintainers (it can be Sérgio M. Basto or Steven A. Falco if they do not
accept me) into the working group.
> That may change and can change, of course. But that’s nothing for F42,
> rather for F52.
It just requires creating a new working group. That can be done instantly.
> This is a failure to understand (or to commit to) what we have decided to
> do with Fedora.next. We don't want to DIY piece together a solution.
But one of the big strengths of Fedora is that you can do exactly that.
> And it is a plain false promise. You can't install CoreOS, IoT, silverblue
> with it, not even Server, which is offered in the menu (because a lot of
> presets are missing).
The presets thing is something that should be fixed. Maybe an entry "server
presets" in the list of checkboxes that will install a metapackage that then
uses boolean Requires to drag in the individual preset packages for whatever
the user actually installs during or after the installation.
The inability to install an atomic system using Everything is inherent to
what atomic systems are and what the Everything ISO is, and should be
obvious to anyone who actually understands what they want to install.
> Basically, we have one domain *now*: fedoraproject.org
But that domain has subdomains such as spins.fedoraproject.org,
labs.fedoraproject.org, etc. distinct from the main fedoraproject.org domain
(though technically the subdomains redirect to pages on the main domain
these days).
> If you have a look on the statistics Matthew reported on Flock last year,
> you would know that the numbers for Workstation were declining, whereas
> the numbers for Server raised steeply and for CoreOS and IoT steadily up.
The numbers for Workstation might be declining because people are installing
other desktop Spins, or a custom selection from Everything, instead. :-)
None of those will have fedora-release-workstation installed.
Kevin Kofler
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
