On Wed, 2014-01-29 at 15:30 -0500, Stephen Gallagher wrote: > Apologies for the slightly alarmist $SUBJECT, but I want to make sure > that this gets read by the appropriate groups. > > During today's FESCo meeting, there was the start of a discussion on > how to approve new Products into the Fedora family. As part of this, > it naturally strayed into discussion of what we do about Spins as they > currently exist. > > Several ideas were raised (which I'll go through below), but we didn't > feel that this was something that FESCo should answer on its own. We'd > prefer community input on how to handle spins going forward. > > So, in no particular order (because it's difficult to say which > questions are the most important): > > 1) Are Spins useful as they currently exist? There are many problems > that have been noted in the Spins process, most notably that it is > very difficult to get a Spin approved and then has no ongoing > maintenance requiring it to remain functional. We've had Spins at > times go through entire Fedora release cycles without ever being > functional. > > 2) Should Spins be eliminated entirely in favor of Fedora Remixes[1]. > The effect here would be that Spins are no longer an official part of > The Fedora Project but are instead projects unto themselves which are > permitted to consume (possibly large) portions of our tools, packages > and ecosystem. Maintenance and upkeep of these spins then becomes > entirely the responsibility of the downstream community that > constructs them and has no mandatory draw on Fedora's marketing, > ambassadors or quality assurance resources. > > 3) Should Spins be considered Products-in-development? In other words, > should we only approve Spins that are targeted or destined for > "promotion" to a fully-supported Fedora Product? This is a nuanced > question, as it means different things for different Spins, for > example Spins focusing on a target-audience (Security Spin, Design > Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz > Spin). > > 3b) If we treat Spins as Products-in-development, what do we do with > those Spins that don't fit that criteria? So in my new constructive spirit ;) let me take a crack at some answers to this: I think the Spins process as it currently exists has a lot of problems. We've been saying this for years, long before we even thought about Fedora.next. You identify some of them above, and there are others - we've never had coherent messaging about the spins, for instance. This is especially silly with the desktop spins, where there are all kinds of mixed messages. * Desktop is a spin, but it's also our default deliverable. * KDE is a spin, and considered a release-blocking deliverable. * Xfce, LXDE, MATE and SoaS are spins, aren't considered release-blocking deliverables, but they *are* shipped in the same directory as the Desktop and KDE spins on the mirrors (since F20), and they're broken out and given special status on the download page as "Desktops" - https://fedoraproject.org/get-fedora#desktops . * Security Lab, Design Suite, Scientific-KDE and Electronics Lab aren't shipped in the same directory as Desktop, KDE, LXDE, MATE and SoaS (the directory they're in isn't carried by all mirrors, I don't think), and they're not "Desktops", but they're shown on a Spins tab on the download page. * All the other spins are spins, but they're not the default deliverable, they don't block the release, they're shipped in the same directory as Security Lab etc, but they're not shown directly on the download page at all. * https://spins.fedoraproject.org/ shows all the spins *except Desktop* in a co-equal way. There's an ad-hoc method to all this madness - there's a sort of ranking system going on there that is intentional - but it's all been rather thrown together as we've gone along and tweaked from release to release with no great overarching plan. So it's a good idea to look at the Spins space and see if there are opportunities for improvement, almost regardless of the Products plan, in fact (though obviously it is relevant to some questions here). Despite the problems with the process, though, I think some of our actual Spins manage to be excellent small-p products that provide good solid value to the Fedora project and we should find a way to keep them within the Fedora space even in a Product-ified world. 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. The desktop spins, though, do have a reasonable amount of value to users of those desktops. People do use live media *just as live media*, and we know there are Fedora users who want to use desktops other than our default desktop, and Fedora contributors willing to do the work of maintaining and testing live image deliverables for those desktops. The desktop spins we have have mostly managed to meet reasonable quality expectations in recent releases without imposing a burden on the QA team. I just don't see any major problems to solve in the area of the existing desktop spins *as small-p products that are a part of the Fedora project*, though I certainly respect the releng team's statement that their work scales more or less linearly with the number of deliverables we decide to make a part of the Fedora space. Even if we want to keep the alternative desktop live images as a part of the Fedora space, though, that affords us quite a bit of flexibility to change other things about this process. As I said, I personally would be fine with us dropping the non-desktop spins with just a bit of effort to make sure those package groups are nice and easy to access from whatever generic installation media we wind up continuing to ship (I'm assuming for now we'll at least still have netinst.iso) and from the software deployments tools associated with each Product. The .next effort certainly gives us an opportunity to fix all the mixed messaging. We could, for instance, give up on the initial idea of spins as this big open space for all kinds of small-p products to be built, drop spins.fp.o entirely (and save whatever work that saves), and just have a particular set of alternative desktop live images as Fedora release deliverables, maybe drop the whole Spins name. I'd certainly find it reasonable to generally message them as being a 'second tier' set after the big-p Product deliverables: the download page would heavily push the Product deliverables, as it currently mainly pushes the desktop live image, and have all the alternative-desktop deliverables shown less prominently. tl;dr summary: I do think it's important to keep the alternative-desktop live image deliverables within the Fedora tent, but there are lots of ways we can look at doing that that are different from the way we currently do it. The non-desktop spins, I think there's a strong argument for losing. -- 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
