Fedora.NEXT Products and the fate of Spins
ibmalone at gmail.com
Thu Jan 30 00:01:40 UTC 2014
On 29 January 2014 22:44, Stephen John Smoogen <smooge at gmail.com> wrote:
> On 29 January 2014 15:01, inode0 <inode0 at gmail.com> wrote:
>> On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer <jwboyer at fedoraproject.org>
>> > On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0 at gmail.com> wrote:
>> >> On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar at fedoraproject.org>
>> >>> Something like => proposal => crop (aka product-to-be) => validation
>> >>> =>
>> >>> product
>> >>> When we'll have that, drop the whole spin thing, any spin that isn't
>> >>> fit to
>> >>> be a product should be reclassified as remix.
>> >> I can't really imagine this ever working. Do you imagine a day where
>> >> Fedora has 20, 30, 50 official products? I don't.
>> > That's fair. From a resource and quality perspective though, I'd
>> > rather not burden rel-eng and QA with having to maintain, create, and
>> > test spins. They can be done entirely outside of Fedora. They can be
>> > created and hosted on their own sites, etc.
>> I don't accept the blanket assertion that the spins have little
>> benefit. Do we actually have any idea how many people install Fedora
>> from spins?
> It is more than just running a script. There is the 'why the heck didn't
> this spin build this time when it did the last 20 times?' that shows up for
> about every spin at least once every release cycle. Most of that is usually
> a couple hours of work here and there, but it isn't 0 maintenance (and
> people like Dan Marshal have recently pitched in to help here )
> Then there is that the QA of some of the spins is simple 'Does it
> boot?'/'Does it install' and other parts aren't like when a spin had various
> apps underneath the desktop didn't work but wasn't found until after we had
> shipped for a while.
<ruthlessly snipped the above down to the points I think I might respond to>
I think the last two releases, certainly the last release, there's
been more focus on shifting that responsibility. If you look at the
spins release page on https://fedoraproject.org/wiki/Releases/20/Spins
that matrix was filled in by spin participants on the understanding
that spins that didn't follow that process (and ensure successful
compose) would be dropped. Which is a good model if spins are to
continue as-is. Regardless of the task/technology split most focus on
a set of packages (really, that's all a spin *can* do) and this means
they get a bit more testing by people who know the domain.
Regardless, that task-technology split is a little important. As Dan
Mashal pointed out the 'live system' is a spin thing. That's quite
good for new users (Ubuntu's early popularity was partly down to
pioneering this), especially as a promotion for different desktops or
particular things like security/rescue discs. Going down the
everything is a product route means you have to decide whether
'Desktop' means gnome and whether kde, cinnamon, xfce and the rest
could ever be products (probably not all of them if the overhead is
going to be more than for a spin).
>From the trenches, over at Jam there is some discussion over whether
it's worth continuing with it as a spin anyway. (I don't think I'm
selling anyone out here, since the discussion is on a fedora mailing
list...) For what we're doing the scope of a spin is a bit limiting in
any case and at the same time we're actually making it harder for
people using stock fedora who'd just like a package collection they
could install. So, to contradict my first two paragraphs, there are a
few spins that could go, perhaps even willingly, but there are some
that are still important.
1. Is there scope for a spin to be a particular sub-focus of a product?
. desktop gnome
. desktop kde
. desktop twm (maybe not)
. server web
. server fileserver (or whatever might make sense)
The idea being that everything under one product should be a
subdivision of what would be included anyway. I realise there's the
potential there to snowball again.
2. Does the new application gui thing understand package groups or
collections? Without wishing to spread the whole cli vs gui package
debate (it's quite happy in the other thread), it seems it might be
relatively intuitive for someone to understand a 'give me a whole lot
of music applications' button. That might provide the equivalent of
what things like design and jam do currently (with the exception of
availability to areas with poor net access).
More information about the devel