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

Adam Williamson awilliam at redhat.com
Thu Dec 2 02:58:06 UTC 2010


On Wed, 2010-12-01 at 21:32 -0500, Bill Nottingham wrote:

> (Now, if we want each spin to fork off their own subproject, with their
> own rel-eng, their own QA, and maybe even their own SCM branches?
> That's more likely to scale.)

This is the model I *really* want to avoid, because it defeats the whole
purpose of having a project. What I'd prefer to see is the model where
we have project-wide general groups, but SIGs contribute actual work.

As I said, this worked well for QA for F14; QA group (i.e. me) set the
framework, by providing test cases and a test matrix and notifying when
builds were available. The spin SIGs contributed the actual testing. If
we have each spin group have its own QA and its own releng, it's going
to add a lot of unnecessary overhead with each group designing its own
releng and QA processes when there's no need for these to be
differentiated between groups; only the *work* is different.
 
> And frankly, one of ideas behind spins was that it was a way to showcase
> the exciting, innovative work that can be done in Fedora. If the only
> exciting, innovative stuff we can come with as a community is just
> 10 different implementations of a panel, terminal, window manager, and file
> manager... that's pretty sad. 

It clearly isn't, given the range of spins we have at the moment, but
the desktop spins do appear to be the most popular. And there's the
special-case sorta desktop spins, Sugar and Meego; these are desktop
spins, in a way, but characterizing them as just a panel, terminal,
window manager and file manager kinda misses the point :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



More information about the advisory-board mailing list