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

[Josh Boyer]

On Thu, Dec 2, 2010 at 10:14 AM, Bill Nottingham <notting at redhat.com> wrote:
> Adam Williamson (awilliam at redhat.com) said:
>> > (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.
>
> I'd prefer to see this model too; it's sort of what spins was originally
> conceived as. However, it was suggested in this thread that this isn't
> good enough for people (or just may not be working right), so I was trying
> to propose other options that I think would work better than the suggested
> 'have the project's resources split entirely across all spins, however
> many there are'.

You could reduce it to not providing them at release time entirely.
Very loose thoughts below.

When I spun the Spins originally, it started more as a service.
Someone would have a kickstart and request a spin and I'd go off and
spin it on some machine.  That obviously doesn't scale, but it was
simple in process.  Or at least it was until we got into the whole
official Spins, hosting, QA, doing it for multiple localized
languages, etc.

However, the project could spend some resources creating a web
framework where people could upload a kickstart and an automated
machine would spit out a composed image from that and store it for 2-3
days for download.  Then Fedora the distro could continue to focus on
its primary Spins, and the remainder could be auto-generated in such a
fashion.  If the compose failed, the requester could ask the Spin
owner to investigate why, etc etc.

This is somewhat akin to a SuSE Studio type service, or revisor, or
wevisor, etc.  It does present a bit of user driven fragmentation, but
Remixes do that already and at a base level Spins boil down to a Remix
that simply uses only content already contained within the Fedora
distro.  Also, from a support standpoint It's not much different from
a user installing a default spin and then modifying it via yum
remove/install.

Something to consider anyway.

josh