Fedora.NEXT Products and the fate of Spins
awilliam at redhat.com
Fri Jan 31 22:37:02 UTC 2014
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
> 2) Should Spins be eliminated entirely in favor of Fedora Remixes.
> 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
> 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
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
* 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
* 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
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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
More information about the devel