On Thu, 2010-12-02 at 10:26 -0500, 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. > 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. One question we were hoping for the Board to consider is whether we want to refine the 'spins' concept to differentiate between spins (as Jaroslav did in his post). After all, as my initial post notes, we have come to do this to some degree already, even if it wasn't universally discussed/agreed: we place the three primary non-default desktop live spins, KDE, XFCE, LXDE, on a pedestal by having them available right from the main project download page. As things stand this is kind of a symptom of inconsistency, but if we *want* to, there's no reason we can't decide to have some 'primary' spins and some 'secondary' spins and have different policies apply to each. This is the kind of high-level question we really wanted Board involvement to settle. Maybe we want to officially put a bit more weight behind the primary desktop spins (I'd quite like to see Sugar and Meego there too), and officially separate them out from the other spins. I do also agree with Jaroslav's distinction between different types of spin; from my area of interest, desktop spins inherently benefit more from the QA process because of what they do. The Electronics Lab spin, for instance, doesn't present a vastly different appearance out of the box than the Desktop spin - it's just a different selection of apps. Our testing process mostly concerns itself with stuff like 'does it boot, do basic operations work' which wouldn't actually differ much between the Desktop spin and the Electronics Lab spin - but certainly *do* differ between desktop and KDE, or desktop and LXDE. It would be difficult for us to mess things up such that the desktop spin fundamentally 'works' but the electronics lab spin doesn't, but we certainly can mess things up such that the desktop spin works but the LXDE spin doesn't (we've done it before). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
