-----BEGIN PGP SIGNED MESSAGE-----
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
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?
I'm sure there are other questions that people will come up with on
this thread, but this should provide a good framework for the discussion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----