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

[Jaroslav Reznik]

On Monday, December 06, 2010 02:52:17 am Adam Williamson wrote:
> 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).

Some combination of b) and c) should work - be as higher level QA - if someone 
is using Fedora brand - we have to be sure it's using Fedora brand in that way 
we can be proud of it ;-) But not in the way how Firefox enforces this rule :) 
c) needs again some coordination - someone has to poke folks with built image 
etc. (it was a problem before Validation tests - it was somehow releases and 
everyone was prying it works). 

> 
> 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?

See my reply in this thread with Fedora Platform idea - I think it's the only 
way how to achieve this (although it doesn't solve independent, not independent 
(sub)projects etc.).

It's wonderful time now for Linux based solutions! Nearly all set-top boxes are 
Linux based (except the cheapest ones), ever fridges are now Linux-powered. I 
know - this is more embedded world but it's a huge market for us -> more 
contributors. 

Jaroslav

> 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!

-- 
Jaroslav Řezník <jreznik at redhat.com>
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.                               http://cz.redhat.com/