-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/29/2014 03:30 PM, 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?
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.
[1]
https://fedoraproject.org/wiki/Remix
So, as I read through the replies to this thread, it becomes clear to
me that the language I selected for this original post implied
"Something must be done about Spins!". This was an oversight on my
part. The intent here was not to read as "Spins are going away unless
people fight over it."
That being said, as we go forward as Fedora.NEXT, we start to see more
clearly defined divisions between Products, Spins and Remixes. Since
these discussions needed to happen, we (FESCo) felt it was best to try
to move the conversation public.
Right now, the vision essentially looks like:
Fedora Products: This *is* Fedora. It comes in three flavors.
Fedora Spins: These are additional custom package sets, comprised ONLY
of Fedora packages and hosted by the Fedora Project that you can
choose to run as a live image or install. They should coexist cleanly
in the Fedora environment
Fedora Remixes: These are separate projects like Korora and Pidora
that are derived from Fedora, using many of our packages but making
modifications to them.
I think it's clear from the conversation so far that question 2) above
is answered "No". People see plenty of value in offering at least some
of the Spins as installable/live package sets. That's perfectly fine.
Another question that I didn't think to raise in the original post was
this: Does it make sense and/or should we have a process for merging
some of the more useful spins together into a new Product?
For example, right now there exists a Fedora Scientific spin that is
quite popular. To me, this would be a clear candidate for a future
Product (perhaps merged with the KDE desktop spin). This then becomes
something clearly worth some marketing and promotion time.
So that's one case for at least some of the current-day Spins to have
a process to "promote" to a Product.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlLqd1kACgkQeiVVYja6o6PVtgCglGtvhVEam6k8oeQTRdOkcXlx
goUAniUOBipFPy0LYpkkUSglJ+v7TBWL
=d2H8
-----END PGP SIGNATURE-----