On Fri, 2014-01-31 at 16:22 -0700, Kevin Fenzi wrote: > > The desktop spins are the ones that seem most important to keep. I > > think there's a reasonable argument for dropping most or all of the > > non-desktop spins, because they're essentially just vehicles for > > delivering package groups, when you look at them. Games provides a > > bunch of games. Electronics Lab provides a bunch of electronics > > tools. There's nothing particularly compelling about shipping these > > particular bundles of packages as live images, or as images at all; > > we can come up with any number of other mechanisms for letting people > > get at them, very trivially. Hell, it's not particularly difficult to > > do it right now. > > I went down this same path a few years ago, but there are actually use > cases for the non desktop spins that aren't served by just installing > and then installing the packages. For example: > > * Using the security spin booted live to examine a compromised install. > You don't want to attach it to a real install thats r/w. Booting off > a read only media means if something messes it up, you can just > reboot. > > * You have 30 machines in a lab you can use for your electronics lab or > design class or gamer gathering. You're allowed to reboot them, but > not install anything on them (they have windows on them or something). > You can just walk around before class and boot them all up on live > dvd/cd's. If someone messes up their setup in the class, they just > reboot and get back to the desktop. > > Now perhaps these are cases where we just say: hey, make your own for > this, but they are valid use cases not easily handled by dropping those > spins. Thanks for the examples - I think you've given them before, and I've forgotten them. Yup: they're valid use cases, and they strengthen the argument for those spins *as* spins. But indeed you can still make the case that there just isn't enough value in doing it as part of Fedora, and viewed in the context of these fairly 'niche' uses, the argument about making them into remixes or something seems less alarming. I'm not sure I'd be onboard with hiving off KDE, Xfce and Sugar as non-Fedora stuff (or requiring them to become fully-fledged Products), but I can certainly see saying 'look, if you want to take Fedora and build a security forensics live image on top of it, that's awesome, but call it something else and maintain it yourself' - I'm rather more on-board with that argument *as applied to these somewhat niche cases* than just applied to, you know, everything we currently cover with Spins. I'm not sure I have a definite opinion on whether we need to / should do that or not, but I know I wouldn't be incredibly sad/angry if it happened. I do think there's some mileage in the argument that, if you go all the back to the original Spins conception as this wide-open field to create ANY PRODUCT YOU LIKE from Fedora bits and it'd be part of the Fedora project in *some* form, that's probably biting off more than we can realistically chew, especially given what releng has said about resources. Right now we're kinda between two stools on that: Spins didn't take off like wildfire and produce hundreds of awesome things like maybe it was originally expected to, but it wasn't a complete and utter dead loss either - so now we're in, I guess, a slightly weird situation where we have this very heavyweight conception of Spins which is maybe not providing us enough value to justify its weight. If you want to take a "market" view of it, you can make the argument that SUSE Studio is rather eating our lunch on the original Spins concept: http://susestudio.com/browse zoiks. Kind of beats our 'well, first figure out the way livecd-creator is duct taped together, then submit a kickstart file to this SIG thing that barely exists any more, then...' process into a cocked hat. <snip last section - I think all your ideas there were sound> -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
