Fedora.NEXT Products and the fate of Spins

Tue Feb 4 09:03:59 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/03/2014 11:06 PM, Brendan Jones wrote:
> On 01/31/2014 12:28 PM, Ian Malone wrote:
>> On 30 January 2014 23:07, Josh Boyer <jwboyer at fedoraproject.org>
>> wrote:
>>> On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski 
>>> <przemek.klosowski at nist.gov> wrote:
>>>> On 01/29/2014 07:10 PM, Ian Malone wrote:
>>>> 
>>>> On 29 January 2014 23:58, Josh Boyer
>>>> <jwboyer at fedoraproject.org> 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).
> 

This is the domain of Fedora Remixes, not Fedora Spins. Downstreams
are permitted (naturally) to use Fedora packages for whatever
distribution they want to create. The catch is that they have to
follow the policies on this page: https://fedoraproject.org/wiki/Remix

The primary difference is that Fedora Remixes have to provide their
own website and image hosting, as they are Fedora-derived, not
Fedora-provided.

> 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?
> 

The sort of person who does that in Fedora in the first place is
likely to do so for a Remix if they're using it as well.