Fedora.NEXT Products and the fate of Spins

[Stephen Gallagher]

> On Jan 31, 2014, at 3:30 AM, Les Howell <hlhowell at pacbell.net> wrote:
> 
>> On Thu, 2014-01-30 at 07:47 -0500, Christian Schaller wrote:
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: "Jaroslav Reznik" <jreznik at redhat.com>
>>> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
>>> Sent: Thursday, January 30, 2014 1:25:10 PM
>>> Subject: Re: Fedora.NEXT Products and the fate of Spins
>>> 
>>> ----- Original Message -----
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> 
>>>> 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.
>>> 
>>> 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 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.
>>> 
>>> 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
>> 
>> Well I think this idea is interesting and we have discussed something along these
>> lines in the Workstation working group. I mean at the end of the day we all want as much 
>> software as possible packaged for Fedora/Product. The question to me lies in the details
>> of how this is done. For instance the idea we hope to explore are we develop the technical 
>> specification for the workstation is what kind of rules should apply to these potential
>> 'formulas'. There are some obvious ones like, you can't for instance in a 'formula' to  replace a package 
>> that would break the core product for instance due to replacing a version of a package with one that
>> got a different ABI. (This specific idea is quite well covered in existing Fedora guidelines, but I wanted to
>> avoid derailing this discussion by choosing an example that I hope would generate discussion in itself :)
>> 
>> 
>>> - 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.
>> 
>> Using the Fedora brand to only define a set of 'white box' packagesets is an option, 
>> but in some sense it means the end of 'Fedora' as a user facing brand.
>> 
>>>> 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).
>>> 
>>> 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...
>> 
>> The general issue with this secondary products is that they would lead to an endless
>> debate about how they get promoted/not promoted by 'Fedora' on the Fedora web pages, by 
>> Fedora conference booths etc. Remixes in my opinion are better here as they make the division 
>> clear and should actually empower the communities in question to more effectively drive and market 
>> their specific product as opposed to spend time arguing over their placement or lack of placement on important 
>> fedoraproject.org pages and simmilar.
>> 
>> Christian
> I use FEL for my projects, and for personal research.  I guess, then the
> issue I see is what you consider the use of a "workstation"?  I do
> embedded projects, personal research for embedded projects, hardware
> design, spice simulations, DSP work, programming language research and
> 3d design with OpenSCAD and have just finished my design for a personal
> milling machine I expect to use for some new projects.  I use LO writer
> for documentation, and Impress for presentations, as well as Evolution
> to handle my email.  I use Gscheme to draw schematics, MPLABX for
> projects on PIC parts, and several other environments for experiments
> and self development.
> 
> Most of this is supported by the packages from the FEL spin, and the
> advantage is I don't have to search all over the web to find them or
> keep them current.  How is it beneficial to Fedora to lose that sort of
> power tool used by professionals, students, researchers and others?  I
> am not sure I would stay with Fedora if that spin went away, because
> plain vanilla Fedora, without the tools I use the most is not really the
> tool I want, it is like a carpenters hammer without the claw to pull and
> straighten nails, that is for me, only half a tool.
> 

This statement makes a faulty assumption that the FEL spin is the only way to get the Electronics Lab packages onto a system. This is patently false. Part of the mandate for spins is that their packages must always be part of the Fedora repositories. This means that at worst, a "vanilla" install of Fedora can always be turned into something resembling the FEL purely with yum commands. Now, there's certainly an argument to be made that installing in this manner is more difficult, of course. Some of that could be mitigated by package groups or meta-packages, of course.

What this does reveal is a bigger problem: that the audiences of at least some of the spins are not aware of this relationship to the larger Fedora ecosystem. This would indicate that the "dropping" or de-promoting the spins might lead the users of them to believe that the functionality they provided was removed from Fedora. While it is not a correct perception, it is nonetheless one that will occur (to some degree no matter how we advertise things) if some or all spins go away. It's a point that clearly merits consideration.