----- Original Message -----
-----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
Spins are useful especially as they makes our community inclusive,
one thing we should be proud about (and sometimes it was harder, could
cause issues but everything is solvable).
For spins quality - it differs, it will differ but recent changes to
process were for good, more updates are still needed. Long time ago
we released what was build, I like how big step we did last few years.
It's not reason it wasn't functional before to ban spins.
If there's interest in spins like product, someone is willing to lead
this effort, I think in some way, it can stay.
2) Should Spins be eliminated entirely in favor of Fedora
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.
It's possible but much more resource hungry. The way how spins are set
helps these sub-projects deliver interesting piece of software.
But there are two questions:
- does every single spin makes sense as standalone spin? I really liked
the idea of Fedora Formulas, it's exactly the way we should go. If for
some reason formulas would not be enough for desired use case -> remix.
aka products + add-ons as formulas = spin
For people who missed it https://fedoraproject.org/wiki/Fedora_formulas
- or we could go even further and ask ourselves, do we want to call
products Fedora? Or do we want products as remixes too? Based on
underlying Fedora infrastructure? This could for example solve issues
with our values - 3rd party repos etc.
3) Should Spins be considered Products-in-development? In other
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
For target audience spins, see above Formulas. And once we have this,
I think spins as we know them right now could go then.
I'd like to avoid calling LXDE/MATE other tech spins as products in
development but we would have to product categories
- Release blocking products
- Non release blocking products with limited support
And to promote other products to be release blocking, WG would have to
be formally established, team should prove sustainability, willingness
to work on it and have resources allocated (own resources or get agreement
from other teams on help, doesn't matter).
Keep it simple and stupid.
So my two cents are - revive Formulas (or now let's call it Stacks now?),
have two categories of products but make it fair to be promoted...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
devel mailing list
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct