On Thursday, December 02, 2010 04:26:03 pm Josh Boyer wrote: > On Thu, Dec 2, 2010 at 10:14 AM, Bill Nottingham <notting@xxxxxxxxxx> wrote: > > Adam Williamson (awilliam@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/advisory-board -- Jaroslav ÅeznÃk <jreznik@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
