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