Stephen Gallagher wrote:
> By all means, if there are user experience problems, highlight those. Just
> don't draw the conclusion that the whole system is unsalvageable. Let the
> team that's working on it figure out if there's a way to fix the UX or if
> it truly does mean that a structural flaw exists in the design. The
> Modularity Team is reading these threads and is keeping notes on all of
> the legitimate issues raised. As of right now, we don't feel that the
> situation is unrecoverable.
>
> Please keep your suggestions constructive. Tell us where we are falling
> short. We are listening. We're just not ready to throw away years of work
> because it isn't perfect yet. If we did that every time, we'd never get
> anywhere. We wouldn't have taken projects like systemd, KDE 4,
> NetworkManager, and GNOME 3 from their rocky starts to where they are now.
> All of those examples were hard-fought changes that brought considerable
> instability to Fedora when they initially landed and now are cornerstones
> of the Fedora story.
You are pointing out here only those major transitions that ultimately
succeeded after a bumpy start. But you are filtering away the much less
successful examples, such as (and yes, those are mostly upstream decisions,
but so were KDE 4 and GNOME 3 that you used as "good" examples):
* Akonadi, the backend behind the current KMail. In KDE 3 and early KDE 4
times, we used to have KMail 1, a fast and reliable mail program. Then,
during the KDE 4 phase (actually, it was initially planned for KDE 4.0,
but then delayed for several releases due to all sorts of issues with it),
upstream designed a new backend called Akonadi and made KMail use it,
calling the new version KMail 2. Unlike KMail 1 (which they discontinued),
KMail 2 was extremely slow and buggy. I and others pointed out several
inherent design flaws in Akonadi that are the source of both the poor
performance and the unreliability. Upstream refused to listen, never
accepted the reality that Akonadi was unsalvageable, and kept releasing
new "fixed" versions that were not noticeably faster or less buggy. To
this day, KMail still uses Akonadi and is still infamous for its poor
performance and bugginess. Most users switched to non-KDE alternatives
such as Thunderbird, Evolution, Trojitá (which is Qt-based) or web mail
clients. (E.g., I use Trojitá now.) Some even abandoned KDE Plasma
entirely due to Akonadi.
* software getting replaced again and again because the new, better software
turned out not to be all that great after all. The main example I can
think of is the hardware detection layer, where we have had, in
chronological order:
- Kudzu
- HAL
- DeviceKit (and udev, taking over some of its tasks already)
- the "u* stack": udev, libudev, udisks, upower
- systemd's udev and libudev, udisks2, upower
(and udisks2 was actually forked to storaged and later unforked). Another
example is the handling of device ACLs for locally logged in users, which
has gone through:
- POSIX groups that users had to be manually and statically added to
- pam_console
- ConsoleKit with HAL integration
- ConsoleKit + udev-acl (corresponding to the DeviceKit move above)
- systemd-logind + udev-acl (corresponding to the systemd move above)
Each of these solutions was touted to be the great modern way that fixes
all the problems of the previous obsolete solution. But it was often only
a matter of months until the "great modern way" has become the next
"previous obsolete solution".
So, in short, newer is not always better, and sometimes, something is really
unsalvageable, and denying that fact will only make you lose users.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
