[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
From: Leslie Satenstein via devel <devel () lists ! fedoraproject ! org>
Date: 2024-04-05 12:47:46
Message-ID: 1221846383.3459988.1712321266459 () mail ! yahoo ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I am an old geezer with about 60 years of IT experience, from mainframe to \
cellphone.I am self-convinced that dropping gnome for KDE as a default would be \
BAD.Why?Today, everyone who ones a cellphone, has on his phone a set of icons. Some \
are there by default, some are there as extra applications that the user added.
The Cellphone user is very comfortable with Gnome. So much so, that I believe that if \
he was given KDE as the interface, two things would happen. a) The user will switch \
to Gnome, or b) The user will find a way to add his favourite applications to the \
desktop. What then is a compromise that will satisfy the Gnome and KDE "bigots"?
Consider:
The Fedora 41/42 installation program can ask the user if he prefers "Menu" or \
"icon" interface. The above approach satisfied both camps.
Leslie Satenstein
On Friday, April 5, 2024 at 08:16:54 a.m. EDT, Kevin Kofler via devel \
<devel@lists.fedoraproject.org> wrote:
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
[Attachment #5 (text/html)]
<html><head></head><body><div class="ydp13d88d50yahoo-style-wrap" \
style="font-family:Helvetica Neue, Helvetica, Arial, \
sans-serif;font-size:16px;"><div><div dir="ltr" data-setdir="false">I am an old \
geezer with about 60 years of IT experience, from mainframe to cellphone.</div><div \
dir="ltr" data-setdir="false">I am self-convinced that dropping gnome for KDE as a \
default would be BAD.</div><div dir="ltr" data-setdir="false">Why?</div><div \
dir="ltr" data-setdir="false">Today, everyone who ones a cellphone, has on his phone \
a set of icons. Some are there by default, some are there as extra applications that \
the user added.<br><br>The Cellphone user is very comfortable with Gnome. So much so, \
that I believe that if he was given KDE as the interface, two things would happen. a) \
The user will switch to Gnome, or b) The user will find a way to add his favourite \
applications to the desktop.</div><div dir="ltr" data-setdir="false"><br></div><div \
dir="ltr" data-setdir="false">What then is a compromise that will satisfy the Gnome \
and KDE "bigots"? <br></div><div dir="ltr" \
data-setdir="false">Consider:</div><div dir="ltr" data-setdir="false"><br></div><div \
dir="ltr" data-setdir="false">The Fedora 41/42 installation program can ask the user \
if he prefers "Menu" or "icon" interface. </div><div dir="ltr" \
data-setdir="false"> <br></div><div class="ydp13d88d50signature"><div \
style="font-family:Helvetica, Arial, sans-serif;font-size:16px;"><div dir="ltr" \
data-setdir="false">The above approach satisfied both camps.</div><div dir="ltr" \
data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><br></div><div \
dir="ltr">Leslie Satenstein </div><br></div></div></div> \
<div><br></div><div><br></div>
</div><div id="ydp7ab8d80fyahoo_quoted_3243382859" \
class="ydp7ab8d80fyahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, \
sans-serif;font-size:13px;color:#26282a;">
<div>
On Friday, April 5, 2024 at 08:16:54 a.m. EDT, Kevin Kofler \
via devel <devel@lists.fedoraproject.org> wrote: </div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Peter Boy wrote:<br></div><div dir="ltr">> I'm \
probably not the right person to comment on this, because I completely<br></div><div \
dir="ltr">> abandoned Fedora Desktop when it was hit (badly) by Gnome 3. \
That<br></div><div dir="ltr">> destroyed my daily workflow and work routines and \
made it unusable (for<br></div><div dir="ltr">> me), or at least barely usable for \
serious professional work not related<br></div><div dir="ltr">> to software \
development (and I ended up using MacOS to this day).<br></div><div \
dir="ltr"><br></div><div dir="ltr">Which is exactly why I proposed back then to make \
Plasma (which actually <br></div><div dir="ltr">operates more similarly to GNOME 2 \
than GNOME 3 does) the default. :-)<br></div><div dir="ltr"><br></div><div \
dir="ltr">>> == Summary ==<br></div><div dir="ltr">>> Switch the default \
desktop experience for Workstation to KDE Plasma.<br></div><div dir="ltr">>> \
The GNOME desktop is moved to a separate spin / edition, retaining<br></div><div \
dir="ltr">>> release-blocking status.<br></div><div dir="ltr">> \
<br></div><div dir="ltr">> This is an absolute no-go! It would break everyone's \
usage of Fedora<br></div><div dir="ltr">> Workstation<br></div><div \
dir="ltr"><br></div><div dir="ltr">It would be a major change, yes. Though not really \
different from the <br></div><div dir="ltr">aforementioned upgrade to GNOME 3 with \
its completely redesigned user <br></div><div dir="ltr">experience, which was also \
done.<br></div><div dir="ltr"><br></div><div dir="ltr">If Workstation were never \
allowed to change its user experience, it would be <br></div><div dir="ltr">shipping \
MATE nowadays, not GNOME.<br></div><div dir="ltr"><br></div><div dir="ltr">> and \
is in irreconcilable contradiction to the characteristics of an<br></div><div \
dir="ltr">> „Edition" as defined with Fedora.next.<br></div><div \
dir="ltr"><br></div><div dir="ltr">How so?<br></div><div dir="ltr"><br></div><div \
dir="ltr">> And that is not „just" a technical issue (the FESCo domain), but a \
basic<br></div><div dir="ltr">> Fedora principle.<br></div><div \
dir="ltr"><br></div><div dir="ltr">If you believe a basic Fedora principle is being \
violated, please bring that <br></div><div dir="ltr">up with the \
Council.<br></div><div dir="ltr"><br></div><div dir="ltr">> Another proposal is to \
make it an „Edition". But basically, a merely KDE<br></div><div dir="ltr">> \
Desktop is not „edition-able". Among others, an edition is meant to \
cover<br></div><div dir="ltr">> a specific use case and a long-term and (more or \
less) perfectly designed<br></div><div dir="ltr">> and engineered solution for \
this. So we have desktop (Workstation) and<br></div><div dir="ltr">> server. Among \
server we have several Editions, the universal Fedora<br></div><div dir="ltr">> \
Server, container centric CoreOS, edge centric IoT and Cloud. Each of \
the<br></div><div dir="ltr">> server-like Editions covers a destined, specific use \
case without<br></div><div dir="ltr">> overlapping.<br></div><div dir="ltr">> \
<br></div><div dir="ltr">> For the desktop area I don't see a non-overlapping use \
case between Gnome<br></div><div dir="ltr">> and KDE. It's just a different tool \
for the same use case.<br></div><div dir="ltr"><br></div><div dir="ltr">This exact \
argument was already used 10 years ago to reject our (that was <br></div><div \
dir="ltr">before I left the KDE SIG, though this issue was one of the triggers for me \
<br></div><div dir="ltr">leaving the SIG) request for a Plasma Edition. 10 years \
later, we still have <br></div><div dir="ltr">no way out of this dilemma. The \
definition of an Edition needs to be refined <br></div><div dir="ltr">or completely \
replaced to get out of this catch-22.<br></div><div dir="ltr"><br></div><div \
dir="ltr">As part of the process to look for a non-overlapping use case, there was an \
<br></div><div dir="ltr">attempt to focus specifically on scientific applications, \
which eventually <br></div><div dir="ltr">lead to the Scientific Lab, but that did \
not make it to an Edition either, <br></div><div dir="ltr">just to a \
Lab.<br></div><div dir="ltr"><br></div><div dir="ltr">The overlap issue is also going \
to hinder other deliverables' efforts to <br></div><div dir="ltr">become Editions. \
E.g., Silverblue mostly overlaps with Workstation and <br></div><div \
dir="ltr">CoreOS: Workstation for the general use cases (workstation/desktop usage), \
<br></div><div dir="ltr">CoreOS for the atomic and container-oriented use \
cases.<br></div><div dir="ltr"><br></div><div dir="ltr">> And if we are willing to \
accept an exception and accept KDE desktop as an<br></div><div dir="ltr">> \
Edition, I don't see that the current SIG qualifies as an \
edition-capable<br></div><div dir="ltr">> working group. Given the recent \
discussion about Wayland / X11, I don't<br></div><div dir="ltr">> see any \
obligation/commitment to ensure long-term reliability and<br></div><div \
dir="ltr">> trouble-free usability. Instead, I see in the discussion an \
unbridled<br></div><div dir="ltr">> desire to introduce something new (that's \
good) without regard for<br></div><div dir="ltr">> backwards compatibility and \
uninterrupted usability (that's bad, we need<br></div><div dir="ltr">> both). And \
obviously the resources to manage both (Wayland and X11) in one<br></div><div \
dir="ltr">> working group are also lacking (and given the schism, possibly also \
the<br></div><div dir="ltr">> willingness to do so).<br></div><div \
dir="ltr"><br></div><div dir="ltr">That particular concern, however, is one that I \
also share. The working <br></div><div dir="ltr">group should be required to accept \
at least one of us plasma-workspace-x11 <br></div><div dir="ltr">maintainers (it can \
be Sérgio M. Basto or Steven A. Falco if they do not <br></div><div dir="ltr">accept \
me) into the working group.<br></div><div dir="ltr"><br></div><div dir="ltr">> \
That may change and can change, of course. But that's nothing for F42,<br></div><div \
dir="ltr">> rather for F52.<br></div><div dir="ltr"><br></div><div dir="ltr">It \
just requires creating a new working group. That can be done instantly.<br></div><div \
dir="ltr"><br></div><div dir="ltr">> This is a failure to understand (or to commit \
to) what we have decided to<br></div><div dir="ltr">> do with Fedora.next. We \
don't want to DIY piece together a solution.<br></div><div dir="ltr"><br></div><div \
dir="ltr">But one of the big strengths of Fedora is that you can do exactly \
that.<br></div><div dir="ltr"><br></div><div dir="ltr">> And it is a plain false \
promise. You can't install CoreOS, IoT, silverblue<br></div><div dir="ltr">> with \
it, not even Server, which is offered in the menu (because a lot of<br></div><div \
dir="ltr">> presets are missing).<br></div><div dir="ltr"><br></div><div \
dir="ltr">The presets thing is something that should be fixed. Maybe an entry "server \
<br></div><div dir="ltr">presets" in the list of checkboxes that will install a \
metapackage that then <br></div><div dir="ltr">uses boolean Requires to drag in the \
individual preset packages for whatever <br></div><div dir="ltr">the user actually \
installs during or after the installation.<br></div><div dir="ltr"><br></div><div \
dir="ltr">The inability to install an atomic system using Everything is inherent to \
<br></div><div dir="ltr">what atomic systems are and what the Everything ISO is, and \
should be <br></div><div dir="ltr">obvious to anyone who actually understands what \
they want to install.<br></div><div dir="ltr"><br></div><div dir="ltr">> \
Basically, we have one domain *now*: fedoraproject.org<br></div><div \
dir="ltr"><br></div><div dir="ltr">But that domain has subdomains such as \
spins.fedoraproject.org, <br></div><div dir="ltr">labs.fedoraproject.org, etc. \
distinct from the main fedoraproject.org domain <br></div><div dir="ltr">(though \
technically the subdomains redirect to pages on the main domain <br></div><div \
dir="ltr">these days).<br></div><div dir="ltr"><br></div><div dir="ltr">> If you \
have a look on the statistics Matthew reported on Flock last year,<br></div><div \
dir="ltr">> you would know that the numbers for Workstation were declining, \
whereas<br></div><div dir="ltr">> the numbers for Server raised steeply and for \
CoreOS and IoT steadily up.<br></div><div dir="ltr"><br></div><div dir="ltr">The \
numbers for Workstation might be declining because people are installing \
<br></div><div dir="ltr">other desktop Spins, or a custom selection from Everything, \
instead. :-) <br></div><div dir="ltr">None of those will have \
fedora-release-workstation installed.<br></div><div dir="ltr"><br></div><div \
dir="ltr"> Kevin Kofler<br></div> </div> </div>
</div></body></html>
[Attachment #6 (text/plain)]
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic