Updated Fedora Workstation PRD draft

[Adam Williamson]

On Sun, 2013-12-01 at 20:01 +0100, Marcel Oliver wrote:

> OK, this was a long post, but I have the impression that there is
> actually an audience of Fedora developers somewhat appreciative of
> such ideas.  I think it would buy Fedora a lot of trust if things were
> thought through from the workflows and needs across the spectrum of
> existing users, including specialists and "power users".  I.e., be
> inclusive in your approach to the extent possible with honest effort,
> it's going to benefit ALL users.

With respect, I don't think this is really what you've outlined in your
post; you haven't identified uncontroversial ways in which we could
achieve what you suggest, but you've outlined a single particular
approach to building a distribution which comes - like any such approach
- with both advantages and drawbacks.

What you described is the old-school approach to building a distro. It's
how RHL started and more or less the approach Fedora took for several
releases, and it's how Mandrake used to work, and old-school SUSE. I
guess I'll outline it again for clarity's sake and to make sure we're
talking about the same thing:

You think it ought to be the *distribution's* role to build a coherent
environment. Distributions shouldn't follow the designs of upstream
desktops, but pick and choose bits between them, and either write their
own 'desktop independent' configuration tools or force one set of
configuration tools, pulled together by the distribution from the
various desktops, on users of all desktops. The distribution should see
itself as the product, and tweak upstream code and configuration where
appropriate to make it look that way.

Like I said, this is how many distros used to work. That's where all the
system-config-* tools on Fedora come from; Fedora used to attempt to
maintain a comprehensive set of 'configuration tools' named
system-config-(something), and strongly encourage the use of those by
all Fedora users, whatever desktop they used. We used to try and
implement a coherent theme across all desktops and brand the entire
bootup series so everything looked like you were running Fedora OS.
Other distros did/do this too; Mandrake with the Mandrake Control
Center, SUSE with YAST, and so on.

I worked on (and for) Mandrake/iva for years, so I'm pretty familiar
with the approach. It certainly has its advantages: if the distro
strongly encourages use of a single set of configuration tools, for
instance, it gives a consistent experience for that distro's users and
makes the support situation clear for users and developers: they have to
make sure the distro's blessed set of tools works in all situations that
are supported. Some people, like you, believe that there's some 'best
set of applications' pulled from different desktops - using k3b as the
default disk burner in all desktops, for instance.

But...it has disadvantages as well, and those disadvantages are the
reason Fedora moved away from it. It's a pretty inefficient way to build
an operating system, really: distributions are not really where
development expertise tends to concentrate, yet the approach places a
very heavy burden of development on distributions. They have to write an
entire suite of configuration tools and keep it working across multiple
desktops. This is an arduous effort; IIRC, probably more than half of
Mandrake's entire engineering staff worked full-time on the
configuration tools. That's an awful lot of work being done at a rather
odd point in the upstream<->downstream chain, and being duplicated by X
distributions. It makes it just about impossible to ever design a
_really_ cohesive experience: the distribution's configuration tools
will inevitably be a major part of the user experience, but they
inevitably will not fit in perfectly with how any of the desktops on
which they are run are designed. The Fedora config tools never felt
quite native in GNOME, KDE or anything else. It introduces more
possibilities for bugs to show up, and bugs that aren't simple to
resolve at that - the more a distribution 'customizes' upstream stuff,
the more likely bugs are to show up in the distro customizations that
don't exist upstream, and inevitably in some cases, you get arguments
about whether the bug is in the distro customizations or the upstream
code, and who ought to fix them. It makes it difficult to develop tight
integration between configuration tools and desktops; it requires some
kind of abstraction that all the desktops can agree upon. To give a
concrete example - distro-implemented config tools typically do okay at
configuring systemwide, permanent settings in shared components. But
take a look, for instance, at how current GNOME and KDE handle input
methods. This is something GNOME has pushed a lot of work into lately.
If you happen to want to use Linux in Japanese, GNOME since 3.8 gives
you a pretty awesome experience: you pick Japanese during
gnome-initial-setup and it configures a very good ibus input method for
you. If you pick many other languages that require an input method to
type, it handles that very smoothly too. You can switch between input
methods for multiple languages and xkb keyboard layouts from the GNOME
top panel with a neat little switcher icon.

It would be very, very difficult for Fedora to have something like that
if we were still sticking to the distribution-developed,
desktop-agnostic configuration tool paradigm, because the plumbing for
that just doesn't exist in any other desktop. You couldn't write a tool
that worked by poking systemwide config files which every desktop
respects which would work in the same way, the capacity just doesn't
exist. When GNOME considers it GNOME's responsibility to build a
coherent environment, and Fedora doesn't try to override GNOME's design
and force its own design and configuration tools on it, treating GNOME
as just a single element of the 'product called Fedora' to be poked and
fiddled into place, this kind of improvement is much more viable.

So, I'm not saying you're necessarily wrong, but I think what you're
suggesting may be more radical than you may think, and it is not a
straightforward decision. Different approaches to distribution design
have advantages and disadvantages, there isn't clearly one that is
correct. And to go back to my 'prototype' point, I'd argue that the
approach Fedora currently uses is probably the best approach for such a
'prototype' distribution. If Fedora still sees it as our goal to drive
innovation and improvement of F/OSS software as a whole, to push the
envelope and help get new stuff done, then it is appropriate for Fedora
*not* to follow the old-school distribution integration approach,
because it uses a lot of development resources in writing
distribution-level modifications and tools and fixing distribution-level
bugs - all resources that could otherwise go to _building better F/OSS
software_ - and having such an infrastructure at the distribution level
tends to act as a *brake* on rapid development, because you can't land
changes into the distro until they are reconciled with the distro's own
customizations.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net