Request: please consider clarifying the project's position on Spins

[Adam Williamson]

On Wed, 2010-12-01 at 11:31 -0800, Adam Williamson wrote:
> Hi, Board!

I'm not going to reply to anyone else's specific reply here, as the
discussion branched and twisted a lot. :) So, three general things in
reply:

1) the point that we currently ship spins with no idea whether they work
or not, and do in fact sometimes (often?) ship completely broken spins,
is an important one. There's actually an argument that this is OK, and
that should be considered, though it's counter-intuitive. But it's
important to realize that this is entirely a part of the present system
and if we don't want that to happen we do need to change the system.
Right now, we would never ship a broken Desktop spin, we would almost
certainly never ship a broken KDE spin, and it's quite unlikely, since
F14, that we would ship a broken LXDE or Xfce spin. Beyond that, all
bets are off. There is currently no official testing coverage for the
spins beyond those four (I'm trying to cover Sugar, but we didn't quite
manage it for F14). As a project, we have no real clue whether they work
at all when we ship and to some degree publicise them. The current
policy, as Jesse described it, is that we build them, we publish them,
and if we find out they're broken, we pull them. That's it.

There's various ways we can handle this:

a) declare it not a problem, as is the current policy
b) require QA to do some minimal 'does it work?' testing of all spins,
and don't publish ones that are totally broken
c) require the SIG (or whatever) that owns each spin to do the basic
testing and sign off on the spin before release: if they don't sign off
on the spin, it's not published. QA and releng can help facilitate this
process if required (just by providing test builds and pointers for
testing).

those are the ones I can think of.

2) I think there is a significant element to the wide question that Greg
and Mairin were discussing which may not yet have been addressed: we
have to take into account the changing nature of the whole world we
operate in. Perhaps three or four years ago, the question was only
GNOME, KDE, Xfce, LXDE: they're four different approaches to essentially
the same problem. They have different philosophies and each may think
it's right and the others aren't, but they're all more or less trying to
answer the same question.

If you throw Sugar and Meego, especially, into the pot, things become
much less clear. Sugar and Meego are fundamentally not trying to answer
the same questions as GNOME, KDE, Xfce and LXDE. Implicit in this is
that it's harder to say 'if we prioritize and focus on a single desktop
we can provide a more refined answer to everyone's needs; they may think
one of the other desktops is a better answer, but at least our nice
focused streamlined solution is *an* answer'. That's really pretty
unconvincing when it comes to the *different* questions Sugar and Meego
are trying to answer. I think it'd be extremely difficult to sell
someone on GNOME being a good functional learning environment, or a good
interface for a tablet or cellphone (yes, we don't ship the Meego
cellphone UX yet, but I know some of us would *like* to).

So here's the new factor: it is now at least theoretically possible for
the Fedora project to provide environments that are fundamentally
different from GNOME, and are aimed at answering completely different
needs, which we realistically cannot answer within the context of our
single preferred desktop/spin/build/whatever you want to call it. To do
this we have to take a wider conception of the Fedora project. Some
people within the project are already doing this, which is why we have
Sugar and Meego packaged (and as spins) at all. Do we embrace that wider
function and start to think of Fedora as a broad-based platform on which
we can build and provide *different* user experiences? Or do we
explicitly say that's too high a goal, Fedora should still focus on
providing a traditional desktop environment first and foremost, and
markedly different environments are a completely secondary and optional
priority, and should probably be done at 'arm's length', as
semi-independent projects or child distros, as SoaS used to be before it
became an official spin?

3), and possibly somewhat in contradiction to 2) :), I do hope we can
put at least some focus on simply solving the active practical issues
here. I know there are interesting wide theoretical discussions to be
had - like 2)! - but we should at least look in the short-term at
smoothing out our story specifically about spins, resolving the
practical inconsistencies I identified in my initial post, at least in
the short term.

Thanks for all the discussion so far!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net