On 01/31/2014 12:28 PM, Ian Malone wrote:
On 30 January 2014 23:07, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski
<przemek.klosowski@xxxxxxxx> wrote:
On 01/29/2014 07:10 PM, Ian Malone wrote:
On 29 January 2014 23:58, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
I consider myself squarely in the middle of those two camps. I think
they have value to people. I think they fill a niche, however large
or small it might be. I also think they can be done by the people
wishing to provide them without relying on Fedora resources for
hosting and creation (outside of leveraging existing packages and
repositories).
I don't consider that "getting rid of them" at all. On the contrary,
I think it lets people have more control over their spins, allows them
to refresh them as they see fit throughout the release, and allows
them to market and promote them beyond a token mention on a Fedora
website.
Some care is needed, if there are things getting packaged to fill a
role in a spin they may disappear from Fedora if the spin in question
does.
On one hand, I am impressed by many spins as an excellent technology
demonstration. On the other hand, what should existing users of a base
Fedora do if they find an useful spin with a superior functionality? If its
function is not integrated and easily accessible from the base system, they
must either dual-boot or re-install from the spin.
Therefore I prefer that the spins ultimate goal is to include the
functionality into generic Fedora. The same goes for other bundling schemes
discussed here. It's not that I object to them per se, but I do think that
there's an opportunity cost involved: the person caring about the spin has
to chose between working on integrating the spin functionality in generic
Fedora, and developing the spin separately. I do recognize that the former
is harder, but the opposite tack has a potential to fragment Fedora. Spins
should be like branches in a VCS: let's not turn them into forks.
I think the strength of Fedora comes from it being an excellent platform for
all kinds of FOSS software, and the associated network effect---the better
the platform is, the faster it gets better.
"Spins" is a loaded term in Fedora that means exactly what you
suggest. An approved Spin, by definition, must only include packages
(and functionality) that is contained in the generic Fedora
repositories. So the project seems to very much agree with you.
Remixes can contain external packages and have the pluses and minuses
that you highlight. Some of the discussion to date has been
suggesting or implying that "Spins" become "Remixes", but I think that
things that are already Spins would likely retain the qualities you
desire. The discussion has a lot of tribal knowledge behind it, so if
you aren't overly familiar with the history behind these concepts I
can see how it would be confusing.
Indeed what Przemek Klosowski described (forking fedora) is what
making all spins remixes might do. Concrete example: real-time audio.
If left to its own devices a music production spin would probably do a
realtime kernel and set priorites for jack on its own. However since
whatever change was made had to apply to all fedora the result was
that the default RT priority for jack was changed in the package (a
realtime kernel not being necessarily required
http://jackaudio.org/realtime_vs_realtime_kernel), so all Fedora JACK
users get a better chosen default (though they still need to make
manual changes to groups to benefit from it).
I can certainly see the benefits of forking in the domain of audio.
However I would also be a little concerned that maintainers of said
spins, might just stop bothering to package new audio software in
upstream Fedora repositories at all. If they are going to the trouble of
of hosting there spins, I can't see why they wouldn't just host there
own packages as well (with custom compiler flags and whatever).
I'd worry that this is going to result in a poorer quality audio
experience in Fedora (for example have those nice arch guys come along
and provide patches to audio software that doesn't build). Who's going
to do that on 3rd party repos?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
