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

[Jaroslav Reznik]

On Thursday, December 02, 2010 04:26:03 pm Josh Boyer wrote:
> 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.

Yes, we are back to my post - we have two kinds of spins. We do not differ now.

R.

> 
> 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
> _______________________________________________
> advisory-board mailing list
> advisory-board at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/advisory-board

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