Fedora.NEXT Products and the fate of Spins

[Stephen Gallagher]

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

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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLpZMwACgkQeiVVYja6o6NOIwCeP6Kr6FGVYLCdU9Uofv7Xrqm1
> e3oAoIEky2/IjoGBF9MqVlEbkG0jd4vv
> =KDoO
> -----END PGP SIGNATURE-----

[Haïkel]

Hi,

I think we should keep spins as long as we don't have a formal process to
accept new products.
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.

btw, it wouldn't be wise to define that process while we're still in
Fedora.Next early stages, it'll just had more entropy.
First we should work to release our sample products, then use that
experience to define the process to bring a new product.

H.

[Stephen Gallagher]

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

On 01/29/2014 03:57 PM, H. Guémar wrote:
>  Hi,
>  
>  I think we should keep spins as long as we don't have a formal
>  process to accept new products. 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.
>  
>  btw, it wouldn't be wise to define that process while we're still
>  in Fedora.Next early stages, it'll just had more entropy. First we
>  should work to release our sample products, then use that 
>  experience to define the process to bring a new product.
>   
Well, one of the things we need to decide is whether we address Spins
at all during the F21 timeframe. I suspect that QA will ask for a
reprieve on that score.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLpbIwACgkQeiVVYja6o6NAOwCfeqNOwmikrZgS2uuVYbSSGmY2
> bgAAoKDiszJp7pvgIv8Yn7gBf6Ryu21W
> =YCP4
> -----END PGP SIGNATURE-----

[Frank Murphy]

On Wed, 29 Jan 2014 16:03:08 -0500
Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  Well, one of the things we need to decide is whether we address
> Spins
>  at all during the F21 timeframe. I suspect that QA will ask for a
>  reprieve on that score.
>   
By "Spins" do you mean
1: http://fedoraproject.org/en/get-fedora#desktops
or 
2: http://fedoraproject.org/en/get-fedora#spins


___
Regards,
Frank 
www.frankly3d.com

[inode0]

On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt; wrote:
>  Hi,
>
>  I think we should keep spins as long as we don't have a formal process to
>  accept new products.
>  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. 
Why do we expect spins to be any more official products than they are now?

I can't really imagine this ever working. Do you imagine a day where
Fedora has 20, 30, 50 official products? I don't.

I'd rather not confuse what is made from Fedora bits with what is
based on Fedora bits but includes other bits. The remix branding does
not seem appropriate for spins that are made purely from Fedora bits.

John

[Haïkel]

Hi,

I agree that we can't support more than a limited number of products.
The point is to make a validation process sufficiently strict so we can
guarantee that the would-be product would be sustainable.
After all, if there are people willing to maintain it on the long term
*and* our infrastructure can handle it (rel-eng, QA, etc.), why should we
prevent them ?

H.

[Josh Boyer]

On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt; wrote:
>  On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar
> <hguemar(a)fedoraproject.org&gt; wrote:
> > Hi,
> >
> > I think we should keep spins as long as we don't have a formal process to
> > accept new products.
> > 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.
>
>  Why do we expect spins to be any more official products than they are now?
>
>  I can't really imagine this ever working. Do you imagine a day where
>  Fedora has 20, 30, 50 official products? I don't.
>
>  I'd rather not confuse what is made from Fedora bits with what is
>  based on Fedora bits but includes other bits. The remix branding does
>  not seem appropriate for spins that are made purely from Fedora bits. 
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.

F20 improved spins overall, but that was because of a concerted effort
with our existing resources.  If Fedora.next is going to succeed,
those resources are already going to be overwhelmed with the 3
products.  Spreading them thinner for little benefit in most cases
seems irresponsible.

josh

[inode0]

On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt;
> wrote:
> > On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt; wrote:
> >> Hi,
> >>
> >> I think we should keep spins as long as we don't have a formal process to
> >> accept new products.
> >> 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.
> >
> > Why do we expect spins to be any more official products than they are now?
> >
> > I can't really imagine this ever working. Do you imagine a day where
> > Fedora has 20, 30, 50 official products? I don't.
> >
> > I'd rather not confuse what is made from Fedora bits with what is
> > based on Fedora bits but includes other bits. The remix branding does
> > not seem appropriate for spins that are made purely from Fedora bits.
>
>  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.
>
>  F20 improved spins overall, but that was because of a concerted effort
>  with our existing resources.  If Fedora.next is going to succeed,
>  those resources are already going to be overwhelmed with the 3
>  products.  Spreading them thinner for little benefit in most cases
>  seems irresponsible. 
So I am being pulled in both directions on this. One of the goals of
agility is to facilitate more things being made from Fedora (at least
that was a discussed goal at various times). I agree with that and
pushing aside the best things we have built from Fedora now
(understanding they have been problematic in various ways in the past)
seems to work against that goal.

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?

Irresponsible is bit loaded. I don't know that rel-eng will be
overburdened by running the script that builds them. I also don't know
that there aren't other creative arrangements that could be made to
facilitate the creation and distribution of spins largely or entirely
under the control of those creating them without pushing them entirely
outside of Fedora infrastructure.

I guess I'd like those active in the spin community to make
suggestions here. I imagine spins and other new creations built on
Fedora to be things the project wants to promote, not push away. The
reality may be that we can't do what we do now in support of spins,
but I hope we can continue to do something that helps and encourages
those making them.

John

[Josh Boyer]

On Wed, Jan 29, 2014 at 5:01 PM, inode0 <inode0(a)gmail.com&gt; wrote:
>  On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; wrote:
> > On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt; wrote:
> >> On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt;
> wrote:
> >>> Hi,
> >>>
> >>> I think we should keep spins as long as we don't have a formal process
> to
> >>> accept new products.
> >>> 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.
> >>
> >> Why do we expect spins to be any more official products than they are now?
> >>
> >> I can't really imagine this ever working. Do you imagine a day where
> >> Fedora has 20, 30, 50 official products? I don't.
> >>
> >> I'd rather not confuse what is made from Fedora bits with what is
> >> based on Fedora bits but includes other bits. The remix branding does
> >> not seem appropriate for spins that are made purely from Fedora bits.
> >
> > 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.
> >
> > F20 improved spins overall, but that was because of a concerted effort
> > with our existing resources.  If Fedora.next is going to succeed,
> > those resources are already going to be overwhelmed with the 3
> > products.  Spreading them thinner for little benefit in most cases
> > seems irresponsible.
>
>  So I am being pulled in both directions on this. One of the goals of
>  agility is to facilitate more things being made from Fedora (at least
>  that was a discussed goal at various times). I agree with that and
>  pushing aside the best things we have built from Fedora now
>  (understanding they have been problematic in various ways in the past)
>  seems to work against that goal. 
There is a difference between "things being made from Fedora" and
"Fedora making things for people".  I'm concerned that Spins have
transformed into the latter.  There is nothing preventing someone from
taking Fedora and making a spin and hosting it themselves.

>  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? 
We had download statistics at one point that showed most of the spins
were not downloaded much.  Maybe the Infra group still collects them.

>  Irresponsible is bit loaded. I don't know that rel-eng will be
>  overburdened by running the script that builds them. I also don't know
>  that there aren't other creative arrangements that could be made to
>  facilitate the creation and distribution of spins largely or entirely
>  under the control of those creating them without pushing them entirely
>  outside of Fedora infrastructure. 
Growing rel-eng could help with the resource issues (similar with QA).
 If the people doing spins want to step up and do that, then some of
my concerns are alleviated.  At least in terms of people resources.

>  I guess I'd like those active in the spin community to make
>  suggestions here. I imagine spins and other new creations built on
>  Fedora to be things the project wants to promote, not push away. The
>  reality may be that we can't do what we do now in support of spins,
>  but I hope we can continue to do something that helps and encourages
>  those making them. 
Promote is an interesting word there too.  I think we want to
encourage people to create things with and on Fedora.  I'm not sure
_promoting_ those things simply because someone made this is the right
idea with Fedora.next.  This isn't specific to Spins though.  It's
part of a much larger branding conversation that we need to have.

josh

[inode0]

On Wed, Jan 29, 2014 at 4:11 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Wed, Jan 29, 2014 at 5:01 PM, inode0 <inode0(a)gmail.com&gt;
> wrote:
> > So I am being pulled in both directions on this. One of the goals of
> > agility is to facilitate more things being made from Fedora (at least
> > that was a discussed goal at various times). I agree with that and
> > pushing aside the best things we have built from Fedora now
> > (understanding they have been problematic in various ways in the past)
> > seems to work against that goal.
>
>  There is a difference between "things being made from Fedora" and
>  "Fedora making things for people".  I'm concerned that Spins have
>  transformed into the latter.  There is nothing preventing someone from
>  taking Fedora and making a spin and hosting it themselves. 
Fedora isn't making the spins for people. The spins are putting up
with Fedora's current requirements that this group do X and that group
do Y on top of what the spins do in order to host the spins. At least
that is my impression of how it has worked so far.

And, of course, there are things preventing people from just going off
and doing everything on their own. The new Workstation product could
make that choice too and make the Workstation product they envision
outside of Fedora.

> > 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?
>
>  We had download statistics at one point that showed most of the spins
>  were not downloaded much.  Maybe the Infra group still collects them. 
Those numbers were horrible but also not very informative.
Approximately 150,000 copies of the desktop spins are distributed
directly on pressed media each year and just that dwarfs the download
numbers for the spins.

> > Irresponsible is bit loaded. I don't know that rel-eng will
> be
> > overburdened by running the script that builds them. I also don't know
> > that there aren't other creative arrangements that could be made to
> > facilitate the creation and distribution of spins largely or entirely
> > under the control of those creating them without pushing them entirely
> > outside of Fedora infrastructure.
>
>  Growing rel-eng could help with the resource issues (similar with QA).
>   If the people doing spins want to step up and do that, then some of
>  my concerns are alleviated.  At least in terms of people resources.
>
> > I guess I'd like those active in the spin community to make
> > suggestions here. I imagine spins and other new creations built on
> > Fedora to be things the project wants to promote, not push away. The
> > reality may be that we can't do what we do now in support of spins,
> > but I hope we can continue to do something that helps and encourages
> > those making them.
>
>  Promote is an interesting word there too.  I think we want to
>  encourage people to create things with and on Fedora.  I'm not sure
>  _promoting_ those things simply because someone made this is the right
>  idea with Fedora.next.  This isn't specific to Spins though.  It's
>  part of a much larger branding conversation that we need to have. 
I agree and while it isn't what I said I did mean promote the idea of
making stuff with Fedora. I suspect promoting that idea will involve
examples of cool things made with Fedora though so it is muddled a
bit. I completely agree about the branding conversation but I'm not
sure we are ready to make some decisions without having the branding
conversation first.

John

[Howard Howell]

On Wed, 2014-01-29 at 17:11 -0500, Josh Boyer wrote:
>  On Wed, Jan 29, 2014 at 5:01 PM, inode0 <inode0(a)gmail.com&gt;
> wrote:
>  > On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt;
> wrote:
>  >> On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt; wrote:
>  >>> On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt;
> wrote:
>  >>>> Hi,
>  >>>>
>  >>>> I think we should keep spins as long as we don't have a formal
> process to
>  >>>> accept new products.
>  >>>> 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.
>  >>>
>  >>> Why do we expect spins to be any more official products than they are now?
>  >>>
>  >>> I can't really imagine this ever working. Do you imagine a day where
>  >>> Fedora has 20, 30, 50 official products? I don't.
>  >>>
>  >>> I'd rather not confuse what is made from Fedora bits with what is
>  >>> based on Fedora bits but includes other bits. The remix branding does
>  >>> not seem appropriate for spins that are made purely from Fedora bits.
>  >>
>  >> 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.
>  >>
>  >> F20 improved spins overall, but that was because of a concerted effort
>  >> with our existing resources.  If Fedora.next is going to succeed,
>  >> those resources are already going to be overwhelmed with the 3
>  >> products.  Spreading them thinner for little benefit in most cases
>  >> seems irresponsible.
>  >
>  > So I am being pulled in both directions on this. One of the goals of
>  > agility is to facilitate more things being made from Fedora (at least
>  > that was a discussed goal at various times). I agree with that and
>  > pushing aside the best things we have built from Fedora now
>  > (understanding they have been problematic in various ways in the past)
>  > seems to work against that goal.
>  
>  There is a difference between "things being made from Fedora" and
>  "Fedora making things for people".  I'm concerned that Spins have
>  transformed into the latter.  There is nothing preventing someone from
>  taking Fedora and making a spin and hosting it themselves.
>  
>  > 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?
>  
>  We had download statistics at one point that showed most of the spins
>  were not downloaded much.  Maybe the Infra group still collects them.
>  
>  > Irresponsible is bit loaded. I don't know that rel-eng will be
>  > overburdened by running the script that builds them. I also don't know
>  > that there aren't other creative arrangements that could be made to
>  > facilitate the creation and distribution of spins largely or entirely
>  > under the control of those creating them without pushing them entirely
>  > outside of Fedora infrastructure.
>  
>  Growing rel-eng could help with the resource issues (similar with QA).
>   If the people doing spins want to step up and do that, then some of
>  my concerns are alleviated.  At least in terms of people resources.
>  
>  > I guess I'd like those active in the spin community to make
>  > suggestions here. I imagine spins and other new creations built on
>  > Fedora to be things the project wants to promote, not push away. The
>  > reality may be that we can't do what we do now in support of spins,
>  > but I hope we can continue to do something that helps and encourages
>  > those making them.
>  
>  Promote is an interesting word there too.  I think we want to
>  encourage people to create things with and on Fedora.  I'm not sure
>  _promoting_ those things simply because someone made this is the right
>  idea with Fedora.next.  This isn't specific to Spins though.  It's
>  part of a much larger branding conversation that we need to have.
>  
>  josh 
I use and promote the use of the FEL spin.  I did a presentation on it
at the RSSC (Robotics Society of Southern California) and gave away 10
disks with the software on them.  I know that that is not much in the
grand scheme of things, but Electronics engineering and hobby uses of
electronics is a relatively small market compared to consumer uses.
However these are the guys that will build the next generation of users.
Robotics are at least one of the real growing sectors of Electronics and
software, and hasn't even reached much more than about 3% of the total
market that will soon be felt. Add the Internet of things, and all the
3d printing of all kinds that are being developed, home built milling
machines and other things that would probably be considered science
fiction even 10 years ago.  Linux is at the core of all those
developments, and I think the FEL spin is a great contribution to those
efforts.

Yes, it is a niche market, but it is one that introduces the power of
linux at a crucial inflection point on the next several generations of
products.

[Jóhann B. Guðmundsson]

On 01/29/2014 10:01 PM, inode0 wrote:
>  So I am being pulled in both directions on this. One of the goals of
>  agility is to facilitate more things being made from Fedora (at least
>  that was a discussed goal at various times). I agree with that and
>  pushing aside the best things we have built from Fedora now
>  (understanding they have been problematic in various ways in the past)
>  seems to work against that goal. 
The fact is the .next and wg's are working *against* making Fedora agile 
again so there is no wonders you are conflicted and you seem to have 
realized
that's spins are not being considered the *right* products ( while the 
output from the wg's are ).

Just bare in mind in relation with Fedora.next and the WG effort that 
thou you are making a change it does not mean you are making progress....

JBG

[Stephen John Smoogen]

On 29 January 2014 15:01, inode0 <inode0(a)gmail.com&gt; wrote:

>  On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer
> <jwboyer(a)fedoraproject.org&gt;
>  wrote:
>  > On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt; wrote:
>  >> On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt;
>  wrote:
>  >>> Hi,
>  >>>
>  >>> I think we should keep spins as long as we don't have a formal process
>  to
>  >>> accept new products.
>  >>> 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.
>  >>
>  >> Why do we expect spins to be any more official products than they are
>  now?
>  >>
>  >> I can't really imagine this ever working. Do you imagine a day where
>  >> Fedora has 20, 30, 50 official products? I don't.
>  >>
>  >> I'd rather not confuse what is made from Fedora bits with what is
>  >> based on Fedora bits but includes other bits. The remix branding does
>  >> not seem appropriate for spins that are made purely from Fedora bits.
>  >
>  > 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.
>  >
>  > F20 improved spins overall, but that was because of a concerted effort
>  > with our existing resources.  If Fedora.next is going to succeed,
>  > those resources are already going to be overwhelmed with the 3
>  > products.  Spreading them thinner for little benefit in most cases
>  > seems irresponsible.
>
>  So I am being pulled in both directions on this. One of the goals of
>  agility is to facilitate more things being made from Fedora (at least
>  that was a discussed goal at various times). I agree with that and
>  pushing aside the best things we have built from Fedora now
>  (understanding they have been problematic in various ways in the past)
>  seems to work against that goal.
>
>  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?
>
>  
We have little knowledge about any installations. We can see that a lot of
spins are downloaded, but there is no way after that to say whether Spin A,
Spin B, or Regular DVD was the method a system was installed. Getting that
information in the past has been one of those 'bridge too far' in privacy.


>  Irresponsible is bit loaded. I don't know that rel-eng will be
>  overburdened by running the script that builds them. I also don't know
>  that there aren't other creative arrangements that could be made to
>  facilitate the creation and distribution of spins largely or entirely
>  under the control of those creating them without pushing them entirely
>  outside of Fedora infrastructure.
>
>  
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.

-- 
Stephen J Smoogen.

[Ian Malone]

On 29 January 2014 22:44, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On 29 January 2014 15:01, inode0 <inode0(a)gmail.com&gt; wrote:
> >
> > On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt;
> > wrote:
> > > On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt; wrote:
> > >> On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt;
> > >>> 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.

Two thoughts:
1. Is there scope for a spin to be a particular sub-focus of a product?
Desktop (all)
. desktop gnome
. desktop kde
. desktop twm (maybe not)
Server (all)
. 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).

-- 
imalone
http://ibmalone.blogspot.co.uk

[Ian Malone]

On 30 January 2014 00:01, Ian Malone <ibmalone(a)gmail.com&gt; wrote:

>  Two thoughts:
>  1. Is there scope for a spin to be a particular sub-focus of a product?
>  Desktop (all)
>  . desktop gnome
>  . desktop kde
>  . desktop twm (maybe not)
>  Server (all)
>  . 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).
>  
And pie in the sky for number 3:
Easier composes so people can share things like embedded system spins
without adding to mirroring or QA overhead. (Composes are not
incredibly difficult if you know what you're doing, but that means
knowing about things like needing to get pre-release kickstarts from
git, set up a mock root (or ideally VM), mess about with selinux). Yes
you can say "host it outside fedora", but it's much easier for someone
to put a .ks up on a blog, github or google code than find decent
hosting for a 500MB image.
(Also I've realised I didn't use the word 'regardless' nearly enough
in my last email.)

-- 
imalone
http://ibmalone.blogspot.co.uk

[Matthew Miller]

On Thu, Jan 30, 2014 at 12:01:40AM +0000, Ian Malone wrote:
>  Two thoughts:
>  1. Is there scope for a spin to be a particular sub-focus of a product?
>  Desktop (all)
>  . desktop gnome
>  . desktop kde
>  . desktop twm (maybe not)
>  Server (all)
>  . 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. 
It looks like the Cloud and Server WGs are both going this way, with Server
offering a base plus different "roles" (like your web and fileserver
examples), and Cloud offering a generic image plus several tailored for
specific uses (docker, big data, etc.). The Workstation WG is going in a
different direction, but I also think the situation is legitimately a bit
different, as the intention is for the server roles to have fundamentally
the same interface/experience, and it's likely that basic things like
cloud-init will remain in the different cloud... uh... spins.

-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Haïkel]

I'm not fond of keeping spins around when we're focusing on products.
That gives the message that they are second-class citizens in Fedora.

I'd rather define a process that allows current spins to become either
sub-products or full-featured products
when they meet a set of requirements (that is to be defined yet).

In a contributor-driven community, it shouldn't be a problem to accept new
products if it is backed appropriately.


H.

[Stephen Gallagher]

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

On 02/04/2014 11:11 AM, H. Guémar wrote:
>  I'm not fond of keeping spins around when we're focusing on
>  products. That gives the message that they are second-class
>  citizens in Fedora.
>   
To be fair, spins have always been second-class citizens (to a point).
They've always been relegated to a secondary page from the "standard"
install media.

>  I'd rather define a process that allows current spins to become
>  either sub-products or full-featured products when they meet a set
>  of requirements (that is to be defined yet).
>  
>  In a contributor-driven community, it shouldn't be a problem to
>  accept new products if it is backed appropriately.
>   
This I agree with completely. We need to define a process for how to
promote new Products. I *will* say that such a process will probably
include a requirement that it must be more than just a technology
deliverable (i.e. Just the XFCE Spin renamed). A product will likely
need to define a target not currently served by one of the existing
products (or the overlap will need to be justified).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLwwyUACgkQeiVVYja6o6NmsQCfTUCY2q3bUKON4vo+J1j9Qnqx
> OboAnixXUmp0HGNqqwBtjVv1cth05B2d
> =TxoF
> -----END PGP SIGNATURE-----

[Adam Williamson]

On Tue, 2014-02-04 at 11:11 +0100, H. Guémar wrote:
>  I'm not fond of keeping spins around when we're focusing on
> products.
>  
>  That gives the message that they are second-class citizens in Fedora. 
We already have about sixteen 'citizen classes' within the spin system,
as I pointed out in another mail. Exactly one spin is our default
deliverable. Exactly two spins block the release. Exactly six spins are
considered 'desktops' and given increased prominence on the download
page. Etc etc.

There is basically nowhere except https://spins.fedoraproject.org/ ,
which I don't think is a particularly high traffic page, that actually
treats all spins as equal.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miloslav Trmač]

On Tue, Feb 4, 2014 at 11:11 AM, H. Guémar <hguemar(a)fedoraproject.org&gt;wrote:

>  I'm not fond of keeping spins around when we're focusing on
> products.
>  That gives the message that they are second-class citizens in Fedora.
>  
In my view, this not supposed to be a discussion about numbering classes /
keeping score.

Rather, I view spins and products as _substantially_ different: spins are
more or less focused on providing upstream software (perhaps with fixed
bugs, or with good curation); products are much more focused on doing extra
new work to integrate, work that doesn't have any non-Fedora upstream.  So,
saying that every spin is/should be a product-in-making doesn't match with
the way I think about this.

Note that this distinction does not automatically imply anything as to
visibility, promotion, or being release blocking: We could easily promote a
specific spin _more_ than a specific product (say, promote Fedora Audio
Product, Fedora Rails 4 spin, Fedora Cloud Product, Fedora KDE spin, Fedora
Desktop, Fedora Server - the order is obviously nonsense but you get the
idea).
    Mirek

[Jóhann B. Guðmundsson]

On 01/29/2014 09:33 PM, Josh Boyer wrote:
>  On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt;
> wrote:
> > On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt; wrote:
> >> Hi,
> >>
> >> I think we should keep spins as long as we don't have a formal process to
> >> accept new products.
> >> 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.
> > Why do we expect spins to be any more official products than they are now?
> >
> > I can't really imagine this ever working. Do you imagine a day where
> > Fedora has 20, 30, 50 official products? I don't.
> >
> > I'd rather not confuse what is made from Fedora bits with what is
> > based on Fedora bits but includes other bits. The remix branding does
> > not seem appropriate for spins that are made purely from Fedora bits.
>  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. 
You do realize that you are faced with exact same problem as are with 
spins with " wg product(s)" and the resolution is the same.

The sub-community producing it will have to put up the QA resources to 
manage and test whatever is put on top of core/base and I would think 
the same applies from releng perspective.

To put this differently as I see it both communities QA and Releng only 
serve as overseers and guiding forces but wont put *any* resources 
themselves into spins nor wg product(s) since those resources will have 
to come from the sub communities producing spins or wg product(s).

JBG

[Dan Mashal]

On Wed, 2014-01-29 at 16:33 -0500, Josh Boyer wrote:
>  On Wed, Jan 29, 2014 at 4:03 PM, inode0 <inode0(a)gmail.com&gt;
> wrote:
>  > On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar <hguemar(a)fedoraproject.org&gt; wrote:
>  >> Hi,
>  >>
>  >> I think we should keep spins as long as we don't have a formal process to
>  >> accept new products.
>  >> 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.
>  >
>  > Why do we expect spins to be any more official products than they are now?
>  >
>  > I can't really imagine this ever working. Do you imagine a day where
>  > Fedora has 20, 30, 50 official products? I don't.
>  >
>  > I'd rather not confuse what is made from Fedora bits with what is
>  > based on Fedora bits but includes other bits. The remix branding does
>  > not seem appropriate for spins that are made purely from Fedora bits.
>  
>  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.
>  
>  F20 improved spins overall, but that was because of a concerted effort
>  with our existing resources.  If Fedora.next is going to succeed,
>  those resources are already going to be overwhelmed with the 3
>  products.  Spreading them thinner for little benefit in most cases
>  seems irresponsible. 
Hi,

Spin maintainer here. 

1) Are spins useful question: 

I have gotten many emails from users that enjoy spins. I was also
thinking about introducing 2 new spins for F21 (Cinnamon and
Enlightenment). 

Spins offer a things that the netinstall and DVD don't:

1) Boot Fedora without installing it
2) Install fedora without having to download the entire DVD or connect
to the internet.

2) In regards to the resources consumed by spins:

I disagree that Spins use a lot of releng/QA resources.

Releng has scripts to compose spins. They have been doing this every
release for a long time.

QAing a spin is simple. Grab the ISO, boot it. Does it work? Does
installation complete. QA done.

Design team is also involved in the spins process. They create artwork
and the webpage for the spin itself.

Again, I don't think that the resource consumption is significant at all

3) Should spins be made into remixes.

Absolutely not in my opinion. This would probably just kill them off.

Dan

[Luya Tshimbalanga]

Spin maintainer as well sharing Dan's view about spin used to display 
Fedora uses of FOSS applications without needing to download either DVD 
or netinstall. Remixes like Korora for example are completely different 
because of the use of software outside Fedora repository.

I think Workstation Group should consult spin maintainers for those 
issues before moving on.

Luya

[Josh Boyer]

On Wed, Jan 29, 2014 at 8:12 PM, Luya Tshimbalanga
<luya(a)fedoraproject.org&gt; wrote:
>  Spin maintainer as well sharing Dan's view about spin used to
> display Fedora
>  uses of FOSS applications without needing to download either DVD or
>  netinstall. Remixes like Korora for example are completely different because
>  of the use of software outside Fedora repository.
>
>  I think Workstation Group should consult spin maintainers for those issues
>  before moving on. 
I'm unsure of why you're addressing the Workstation WG.  This
discussion was generated by FESCo, not the Workstation WG.  The
Workstation WG has made no proposals or comments around Spins at all.

If you mean you wish to collaborate with the Workstation WG on doing
alternative spins, then great.  Please bring that up on the desktop@
list.

josh

[Ankur Sinha]

Hi,

I'm just throwing "jigdo" into the mix[1]. 

From the infrastructure side, jigdo only needs templates to be hosted.
It picks rpms from the mirrors just like $package_manager. Would it be
feasible to host jigdo files for spins instead of ISO files? The users
would be downloading the same amount, only they'll be downloading
individual packages instead of the finished ISO. It comes in handy if
you're downloading more than one spin, since the already downloaded
packages needn't be downloaded again.

Issues with this:
1. I'm not certain if jigdo composes liveCDs
2. Upstream seems dead[2]
3. Does it run on windows/mac/not linux?
4. QA?

A brain fart at best, lots of details to be fleshed out.

There's also "Dorrie"[3], but I don't think it solves any issues.
Rather, it'll probably increase infra/QA load since it is meant to be a
"generate an ISO on demand" service. 

[1] http://fedoraproject.org/wiki/Features/JigdoRelease
[2] http://atterer.net/jigdo/
[3] https://fedoraproject.org/wiki/Remixes_Web_Interface

-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG

[Ankur Sinha]

On Thu, 2014-01-30 at 12:47 +1100, Ankur Sinha wrote:
>  2. Upstream seems dead[2] 
Not really dead moved from .net to .org

http://atterer.org/jigdo/

We've got 

jigdo-gui.x86_64 : Jigdo graphical interface
pyjigdo.noarch : Python version of Jigdo, slightly modified
jigdo.x86_64 : Ease distribution of large files over the Internet

in the repos.
-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG

[Ankur Sinha]

On Thu, 2014-01-30 at 12:47 +1100, Ankur Sinha wrote:
>  I'm just throwing "jigdo" into the mix[1].  
And pyjigdo:
https://fedorahosted.org/pyjigdo/

-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG

[Luya Tshimbalanga]

On 29/01/14 05:17 PM, Josh Boyer wrote:
>  On Wed, Jan 29, 2014 at 8:12 PM, Luya Tshimbalanga
>  <luya(a)fedoraproject.org&gt; wrote:
> > Spin maintainer as well sharing Dan's view about spin used to display Fedora
> > uses of FOSS applications without needing to download either DVD or
> > netinstall. Remixes like Korora for example are completely different because
> > of the use of software outside Fedora repository.
> >
> > I think Workstation Group should consult spin maintainers for those issues
> > before moving on.
>  I'm unsure of why you're addressing the Workstation WG.  This
>  discussion was generated by FESCo, not the Workstation WG.  The
>  Workstation WG has made no proposals or comments around Spins at all.
>
>  If you mean you wish to collaborate with the Workstation WG on doing
>  alternative spins, then great.  Please bring that up on the desktop@
>  list.
>
>  josh 
My bad. I mean FESCo.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net

[Adam Williamson]

On Wed, 2014-01-29 at 16:33 -0500, Josh Boyer wrote:

>  > I'd rather not confuse what is made from Fedora bits with
> what is
>  > based on Fedora bits but includes other bits. The remix branding does
>  > not seem appropriate for spins that are made purely from Fedora bits.
>  
>  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. 
The 'burden' they create on QA is precisely zero, as we explicitly do
not block releases on spins other than desktop and KDE. I don't believe
releng considers the spins much of a burden, either - it's more just
that they don't like building and pushing out stuff that no-one's even
done a sanity check on. However, we have several high quality spins that
people *do* care about and *do* test: at least the desktop spins, but I
know for e.g. finalzone puts a lot of work into the design spin.

I think it's fairly presumptuous to suggest chucking all that stuff in
favour of something that doesn't even *exist* yet.

>  F20 improved spins overall, but that was because of a concerted
> effort
>  with our existing resources.  If Fedora.next is going to succeed,
>  those resources are already going to be overwhelmed with the 3
>  products. 
Again, there is no 'burden' on QA due to spins.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[piruthiviraj natarajan]

On Thu, Jan 30, 2014 at 9:42 AM, Adam Williamson <awilliam(a)redhat.com&gt;wrote:

>  On Wed, 2014-01-29 at 16:33 -0500, Josh Boyer wrote:
>
>  > > I'd rather not confuse what is made from Fedora bits with what is
>  > > based on Fedora bits but includes other bits. The remix branding does
>  > > not seem appropriate for spins that are made purely from Fedora bits.
>  >
>  > 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.
>
>  The 'burden' they create on QA is precisely zero, as we explicitly do
>  not block releases on spins other than desktop and KDE. I don't believe
>  releng considers the spins much of a burden, either - it's more just
>  that they don't like building and pushing out stuff that no-one's even
>  done a sanity check on. However, we have several high quality spins that
>  people *do* care about and *do* test: at least the desktop spins, but I
>  know for e.g. finalzone puts a lot of work into the design spin.
>
>  I think it's fairly presumptuous to suggest chucking all that stuff in
>  favour of something that doesn't even *exist* yet.
>
>  > F20 improved spins overall, but that was because of a concerted effort
>  > with our existing resources.  If Fedora.next is going to succeed,
>  > those resources are already going to be overwhelmed with the 3
>  > products.
>
>  Again, there is no 'burden' on QA due to spins.
>  

As a user of Fedora I like to say that Fedora spins give so much value to
Fedora.
I know a lot of people who use spins rather than the default
Gnome-desktop-Live.
 Please don't gutter the spins !

[Josh Boyer]

On Jan 29, 2014 11:13 PM, "Adam Williamson" <awilliam(a)redhat.com&gt; wrote:
>  On Wed, 2014-01-29 at 16:33 -0500, Josh Boyer wrote:
>
>  > > I'd rather not confuse what is made from Fedora bits with what is
>  > > based on Fedora bits but includes other bits. The remix branding does
>  > > not seem appropriate for spins that are made purely from Fedora bits.
>  >
>  > 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.
>
>  The 'burden' they create on QA is precisely zero, as we explicitly do
>  not block releases on spins other than desktop and KDE. I don't believe
>  releng considers the spins much of a burden, either - it's more just
>  that they don't like building and pushing out stuff that no-one's even
>  done a sanity check on. However, we have several high quality spins that
>  people *do* care about and *do* test: at least the desktop spins, but I
>  know for e.g. finalzone puts a lot of work into the design spin. 
QA does no testing of spins at all?  If that's the case then I
misunderstood.  If QA does test, even if they don't block the release, it
takes time and effort.

>  I think it's fairly presumptuous to suggest chucking all that
> stuff in
>  favour of something that doesn't even *exist* yet. 
I didn't suggest chucking.  I suggested moving the work to the people most
invested.  Chucking would be "sorry you can use Fedora to make a different
spin" and that would be bad indeed.

Also, even if Fedora.next dies, QA had talked about lack of time to tool
and automate in general.  If QA doesn't test spins today then you gain
nothing but if you do then that's at least some time back.

Spins are not free of cost.  You might find it to be of little cost but
there is still cost.

josh

[Luya Tshimbalanga]

On 30/01/14 03:45 AM, Josh Boyer wrote:
>  > The 'burden' they create on QA is precisely zero, as we explicitly do
>  > not block releases on spins other than desktop and KDE. I don't believe
>  > releng considers the spins much of a burden, either - it's more just
>  > that they don't like building and pushing out stuff that no-one's even
>  > done a sanity check on. However, we have several high quality spins that
>  > people *do* care about and *do* test: at least the desktop spins, but I
>  > know for e.g. finalzone puts a lot of work into the design spin.
>
>  QA does no testing of spins at all?  If that's the case then I 
>  misunderstood.  If QA does test, even if they don't block the release, 
>  it takes time and effort.
>
>  
FYI, Design Suite directly uses default desktop spin (GNOME) template as 
the base with some configurations like app-folders and additions art and 
design related FOSS software. Are those really time consuming for testing?

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net

[Adam Williamson]

On Thu, 2014-01-30 at 06:45 -0500, Josh Boyer wrote:

>  QA does no testing of spins at all?  If that's the case then I
>  misunderstood.  If QA does test, even if they don't block the release,
>  it takes time and effort.   
No testing of spins is required on the part of QA. People who contribute
to QA may choose to test spins, if they like - but then, if they
consider that valuable work, presumbly they'd still consider it valuable
work if spins were outside of the main Fedora process, and want to
contribute to it there.

I don't think anyone is testing spins out of a sense of obligation
rather than because they *want* to.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Thu, 2014-01-30 at 11:17 -0800, Adam Williamson wrote:
>  On Thu, 2014-01-30 at 06:45 -0500, Josh Boyer wrote:
>  
>  > QA does no testing of spins at all?  If that's the case then I
>  > misunderstood.  If QA does test, even if they don't block the release,
>  > it takes time and effort.  
>  
>  No testing of spins is required on the part of QA. 
Sorry, nirik points out that I was assuming 'obvious' knowledge here
that I shouldn't have: I meant 'non-blocking' spins. The two blocking
spins - Desktop and KDE - obviously are tested by QA.

Theoretically, therefore - *I STRESS THEORETICALLY!* - there is a case
where changing spins reduces QA's workload, yes: by removing the
obligation to test KDE. I personally like that KDE is a blocking
desktop, but that's a personal opinion.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Jon]

On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  -----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. 
[snip]


>  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.
>  
Putting on my rel-eng hat I can say that any spin that fails to
compose will be dropped.

I believe we also encourage or even require the spin maintainers to
test their spin as functional.
(To work out if the spin succeeds to compose but fails to actually work)

The idea is to encourage active spin process, inactive spins will auto
retire by policy if they fail.

Another aspect I worry about is the mirroring stuff.
With the coming WGs I fear the rsync mirroring will grow very large,
and spins are an attractive piece of fat to cut.
Reducing size is something we worry about on the infra, rel-eng side of things.

>  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. 
Again, from the rel-eng perspective... this proposal sounds nice.
(removing spins in favor of remix)
It would reduce the complexity of my work flow.
So selfishly speaking removing spins sounds great.

However, they are an important part of our community, and I'd feel sad
to see them disappear.
There is a nice aspect of them being partially hooked into the rel-eng
process that adds value.
The community comes together, spin maintainers have a list they talk
to each other.
We push them to provide quality product, etc.

In my view a remix is something that contains stuff that Fedora cannot.
Say for example, my chromebook remixes in F19... those broke with
Fedora principles by using evil vendor tree kernels.
So in my thinking that is what a remix is for..... but spins 100% stay
with the Fedora way of things, our four foundations or whatever.

In my opinion the WGs are big giant uber-spins.



[snip]
...


-Jon Disnard
FAS: parasense
IRC: masta

[inode0]

On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard(a)gmail.com&gt; wrote:
>  On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher
> <sgallagh(a)redhat.com&gt; wrote:
> > -----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.
>
>  [snip]
>
>
> >
> > 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.
> >
>
>  Putting on my rel-eng hat I can say that any spin that fails to
>  compose will be dropped.
>
>  I believe we also encourage or even require the spin maintainers to
>  test their spin as functional.
>  (To work out if the spin succeeds to compose but fails to actually work)
>
>  The idea is to encourage active spin process, inactive spins will auto
>  retire by policy if they fail.
>
>  Another aspect I worry about is the mirroring stuff.
>  With the coming WGs I fear the rsync mirroring will grow very large,
>  and spins are an attractive piece of fat to cut. 
You probably didn't mean for that to sound so negative but a piece of
fat to cut is how rel-eng thinks of spins?

I recall being assured at the beginning that some interested company
was willing to provide the necessary support for us to give this a
fair try.

>  Reducing size is something we worry about on the infra, rel-eng side
> of things. 
That is pragmatic but be a dreamer while dreaming is in style. Give
worrying about how to increase the capacity of infra a try instead.

John

[Stephen John Smoogen]

On 29 January 2014 15:49, inode0 <inode0(a)gmail.com&gt; wrote:

>  On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard(a)gmail.com&gt;
> wrote:
>  > On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt;
>  wrote:
>  >> -----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.
>  >
>  > [snip]
>  >
>  >
>  >>
>  >> 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.
>  >>
>  >
>  > Putting on my rel-eng hat I can say that any spin that fails to
>  > compose will be dropped.
>  >
>  > I believe we also encourage or even require the spin maintainers to
>  > test their spin as functional.
>  > (To work out if the spin succeeds to compose but fails to actually work)
>  >
>  > The idea is to encourage active spin process, inactive spins will auto
>  > retire by policy if they fail.
>  >
>  > Another aspect I worry about is the mirroring stuff.
>  > With the coming WGs I fear the rsync mirroring will grow very large,
>  > and spins are an attractive piece of fat to cut.
>
>  You probably didn't mean for that to sound so negative but a piece of
>  fat to cut is how rel-eng thinks of spins?
>
>  I recall being assured at the beginning that some interested company
>  was willing to provide the necessary support for us to give this a
>  fair try.
>
>  
How long is a fair try? It would help to define that before people go on a
rant about doing it for a couple of years now.


-- 
Stephen J Smoogen.

[inode0]

On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On 29 January 2014 15:49, inode0 <inode0(a)gmail.com&gt; wrote:
> > On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard(a)gmail.com&gt; wrote:
> > > Putting on my rel-eng hat I can say that any spin that fails to
> > > compose will be dropped.
> > >
> > > I believe we also encourage or even require the spin maintainers to
> > > test their spin as functional.
> > > (To work out if the spin succeeds to compose but fails to actually work)
> > >
> > > The idea is to encourage active spin process, inactive spins will auto
> > > retire by policy if they fail.
> > >
> > > Another aspect I worry about is the mirroring stuff.
> > > With the coming WGs I fear the rsync mirroring will grow very large,
> > > and spins are an attractive piece of fat to cut.
> >
> > You probably didn't mean for that to sound so negative but a piece of
> > fat to cut is how rel-eng thinks of spins?
> >
> > I recall being assured at the beginning that some interested company
> > was willing to provide the necessary support for us to give this a
> > fair try.
> >
>
>  How long is a fair try? It would help to define that before people go on a
>  rant about doing it for a couple of years now. 
I meant giving our new adventure a fair try, not giving spins a fair
try. I also really did not mean to go on a rant.

I think we have a group that sees little benefit to spins and another
that sees a lot of benefit to spins. The former wants to get rid of
them, the latter wants to keep them. We won't ever quantify the amount
of benefit they bring so we are probably at a stalemate on the benefit
question.

On the resources question we can either ask for them in order to allow
us to do both or we can look for new ways to reduce the cost of spins
to those complaining about the burden they impose. I'm open to either
of those approaches. Getting rid of them to me would be an admission
that are unwilling or unable to continue supporting something that is
valuable to our users and our community (just my subjective opinion
and I know not everyone shares it).

John

[Josh Boyer]

On Wed, Jan 29, 2014 at 6:48 PM, inode0 <inode0(a)gmail.com&gt; wrote:
>  On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen
> <smooge(a)gmail.com&gt; wrote:
> > On 29 January 2014 15:49, inode0 <inode0(a)gmail.com&gt; wrote:
> >> On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard(a)gmail.com&gt; wrote:
> >> > Putting on my rel-eng hat I can say that any spin that fails to
> >> > compose will be dropped.
> >> >
> >> > I believe we also encourage or even require the spin maintainers to
> >> > test their spin as functional.
> >> > (To work out if the spin succeeds to compose but fails to actually work)
> >> >
> >> > The idea is to encourage active spin process, inactive spins will auto
> >> > retire by policy if they fail.
> >> >
> >> > Another aspect I worry about is the mirroring stuff.
> >> > With the coming WGs I fear the rsync mirroring will grow very large,
> >> > and spins are an attractive piece of fat to cut.
> >>
> >> You probably didn't mean for that to sound so negative but a piece of
> >> fat to cut is how rel-eng thinks of spins?
> >>
> >> I recall being assured at the beginning that some interested company
> >> was willing to provide the necessary support for us to give this a
> >> fair try.
> >>
> >
> > How long is a fair try? It would help to define that before people go on a
> > rant about doing it for a couple of years now.
>
>  I meant giving our new adventure a fair try, not giving spins a fair
>  try. I also really did not mean to go on a rant.
>
>  I think we have a group that sees little benefit to spins and another
>  that sees a lot of benefit to spins. The former wants to get rid of
>  them, the latter wants to keep them. We won't ever quantify the amount
>  of benefit they bring so we are probably at a stalemate on the benefit
>  question. 
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.

Is it asking spin owners to shoulder more of the burden than today?
Yes.  Is it unreasonable to ask that of them?  In my opinion, no.
Does it provide them with more freedom while still gaining the
majority of the benefit of leveraging Fedora?  In my opinion, yes.

josh

[Ian Malone]

On 29 January 2014 23:58, Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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.

-- 
imalone
http://ibmalone.blogspot.co.uk

[Przemek Klosowski]

On 01/29/2014 07:10 PM, Ian Malone wrote:
>  On 29 January 2014 23:58, Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; 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.

[Josh Boyer]

On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski
<przemek.klosowski(a)nist.gov&gt; wrote:
>  On 01/29/2014 07:10 PM, Ian Malone wrote:
>
>  On 29 January 2014 23:58, Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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.

josh

[Ian Malone]

On 30 January 2014 23:07, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski
>  <przemek.klosowski(a)nist.gov&gt; wrote:
> > On 01/29/2014 07:10 PM, Ian Malone wrote:
> >
> > On 29 January 2014 23:58, Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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).

-- 
imalone
http://ibmalone.blogspot.co.uk

[Brendan Jones]

On 01/31/2014 12:28 PM, Ian Malone wrote:
>  On 30 January 2014 23:07, Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; wrote:
> > On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski
> > <przemek.klosowski(a)nist.gov&gt; wrote:
> >> On 01/29/2014 07:10 PM, Ian Malone wrote:
> >>
> >> On 29 January 2014 23:58, Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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?

[Stephen Gallagher]

-----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(a)fedoraproject.org&gt;
> > wrote:
> >> On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski 
> >> <przemek.klosowski(a)nist.gov&gt; wrote:
> >>> On 01/29/2014 07:10 PM, Ian Malone wrote:
> >>> 
> >>> On 29 January 2014 23:58, Josh Boyer
> >>> <jwboyer(a)fedoraproject.org&gt; 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.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLwrP8ACgkQeiVVYja6o6MANgCdGyTAVy+HS7Ie8DJhMFtiuPOa
> 5LIAoIPQpmOLSmTZhfaDthuLLaW34f2J
> =gZFu
> -----END PGP SIGNATURE-----

[Dan Mashal]

On Tue, Feb 4, 2014 at 1:03 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  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.
>
>  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. 
Hi,

So where do we currently stand with this?

Are we leaning towards spins going away?

Are we leaning towards keeping some spins and getting rid of others?

What about proposals for new spins?

Dan

[Stephen Gallagher]

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

On 02/04/2014 10:34 AM, Dan Mashal wrote:
>  On Tue, Feb 4, 2014 at 1:03 AM, Stephen Gallagher
>  <sgallagh(a)redhat.com&gt; wrote:
> > 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.
> > 
> > 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.
>  
>  Hi,
>  
>  So where do we currently stand with this?
>  
>  Are we leaning towards spins going away?
>  
>  Are we leaning towards keeping some spins and getting rid of
>  others?
>  
>  What about proposals for new spins? 

I won't speak for all of FESCo, but I'm leaning towards: "Spins can
continue just as they are, while being aware that they continue to be
secondary to our primary deliverables". (Yes, I'm aware of the
KDE-as-release-blocker rule and we'll address that individually).

So new spins and existing Spins are fine (in my opinion) as long as
someone is caring for and feeding them.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLww5YACgkQeiVVYja6o6PtYACfUeW9oYycRD7n9b3+kc593KFu
> gFoAni0WVryNnZp2M7WTioqYXudwFTp2
> =GfMO
> -----END PGP SIGNATURE-----

[Robert Mayr]

2014-02-04 Stephen Gallagher <sgallagh(a)redhat.com&gt;:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>
>  I won't speak for all of FESCo, but I'm leaning towards: "Spins can
>  continue just as they are, while being aware that they continue to be
>  secondary to our primary deliverables". 
[snip]

Yes, in my eyes that's the reason why spins should not become a
separate product. They can/should be part of a product, such as
Workstation, and maybe only Security is worth a discussion apart.
How we will call the spins in fedora.ext is not important, but we
should have a clear idea soon about them.

Personally I wouldn't either keep any of them as release blocking
(except GNOME probably), only products should be able to block a
release.
Just my personal thought about this topic ;)

Cheers.

[Dan Mashal]

On Tue, Feb 4, 2014 at 2:40 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  I won't speak for all of FESCo, but I'm leaning towards:
> "Spins can
>  continue just as they are, while being aware that they continue to be
>  secondary to our primary deliverables". (Yes, I'm aware of the
>  KDE-as-release-blocker rule and we'll address that individually).
>
>  So new spins and existing Spins are fine (in my opinion) as long as
>  someone is caring for and feeding them. 
Thanks, that's good news.

Dan

[Matthew Miller]

On Tue, Feb 04, 2014 at 01:34:09AM -0800, Dan Mashal wrote:
>  So where do we currently stand with this? 
So, here's what *I'm* thinking.....

Spins clearly have enough popularity and importance that we either need to
keep them or have some alternative that fills the same space and makes
people at least as happy or happier. Since I don't know of any idea for
alternatives, we clearly should keep that.

Some spins might want to investigate alternative delivery methods. I'm
thinking particularly of the non-desktop-environment spins. Some of them
could maybe be delivered as groups of applications in Gnome Software
(although that's also clearly not appropriate for all), or maybe there's
interest in pushing the Fedora Formulas idea futher.

I'd also like to see some of the restrictions on spins loosened a little
bit. I think the spin/remix distinction (Fedora-only software vs. combined
with other things) is good, but, for example, spins, maybe it *would* be
okay to change software defaults in a way that isn't currently allowed.

I think some spins are completely fine staying as spins forever. Other
groups might be interested in becoming a Fedora capital-P Product. *I* don't
think we want more than a handful of these, but maybe it turns out that we
actually do collectively. So, for spins that are interested in targeting a
particular target space, there should be a process to get there.

Earlier I had suggested that I was thinking that this would parallel what
Fedora does with primary and secondary architectures, and that current spins
might all become "secondary products". This discussion makes me think that
that's not quite right. Stanislav Ochotnický suggested that "incubating
products" might be better, in line with the Apache process:
https://incubator.apache.org/incubation/Process_Description.html (Although
we're structured somewhat differently from Apache, so we can't just lift
that wholesale). Not all spins would be interested in this (again, fine),
but the ones that are could have a clear path to follow.


-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Miloslav Trmač]

On Tue, Feb 4, 2014 at 2:02 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;wrote:

>  I'd also like to see some of the restrictions on spins loosened a
> little
>  bit. I think the spin/remix distinction (Fedora-only software vs. combined
>  with other things) is good, but, for example, spins, maybe it *would* be
>  okay to change software defaults in a way that isn't currently allowed.
>  
Is there a "way that isn't currently allowed" actually?  Spins can
put
anything into %post, and some do modify configuration.  (If nothing else,
the desktop spins change the default desktop...)
    Mirek

[Matthew Miller]

On Tue, Feb 04, 2014 at 02:38:32PM +0100, Miloslav Trmač wrote:
>  > I'd also like to see some of the restrictions on spins
> loosened a little
>  > bit. I think the spin/remix distinction (Fedora-only software vs.
>  > combined with other things) is good, but, for example, spins, maybe it
>  > *would* be okay to change software defaults in a way that isn't
>  > currently allowed.
>  Is there a "way that isn't currently allowed" actually?  Spins can put
>  anything into %post, and some do modify configuration.  (If nothing else,
>  the desktop spins change the default desktop...) 
I don't know to what degree this is enforced, but
https://fedoraproject.org/wiki/Spins_Guidelines contains a big warning:

  Do NOT change the default behavior of applications. An example is to
  configure Nautilus to use the "Browser mode" by default. There may be
  valid reasons to change parts of the application, but you'll need to
  discuss them with the Spin SIG in your proposal.

Although that is only in the "Live Spins" section. "Installation
Spins" says
"No notes on Installation Spins yet" (as it has for at least the last four
years). Not that I'm one to talk -- documenting stuff is hard. :)


-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Jaroslav Reznik]

----- Original Message -----
>  On Tue, Feb 04, 2014 at 02:38:32PM +0100, Miloslav Trmač wrote:
>  > > I'd also like to see some of the restrictions on spins loosened a little
>  > > bit. I think the spin/remix distinction (Fedora-only software vs.
>  > > combined with other things) is good, but, for example, spins, maybe it
>  > > *would* be okay to change software defaults in a way that isn't
>  > > currently allowed.
>  > Is there a "way that isn't currently allowed" actually?  Spins can
> put
>  > anything into %post, and some do modify configuration.  (If nothing else,
>  > the desktop spins change the default desktop...)
>  
>  I don't know to what degree this is enforced, but
>  https://fedoraproject.org/wiki/Spins_Guidelines contains a big warning:
>  
>    Do NOT change the default behavior of applications. An example is to
>    configure Nautilus to use the "Browser mode" by default. There may be
>    valid reasons to change parts of the application, but you'll need to
>    discuss them with the Spin SIG in your proposal. 
Seems to be pretty outdated (*), we're past many things written there aka Live
CD size - for example for desktop and KDE spins. So the CD part could be removed,
I know several spins doing changes in defaults and it's really up to SIG 
standing behind spin than Spins SIG.

(*) last edit March 2011

>  Although that is only in the "Live Spins" section.
> "Installation Spins" says
>  "No notes on Installation Spins yet" (as it has for at least the last four
>  years). Not that I'm one to talk -- documenting stuff is hard. :) 
It needs updates :). Any volunteer?

Jaroslav

>  
>  
>  --
>  Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Rahul Sundaram]

Hi


On Tue, Feb 4, 2014 at 8:54 AM, Jaroslav Reznik wrote:

>  ----- Original Message -----
>
>  It needs updates :). Any volunteer?
>  
I have updated it just to remove the obsolete content for now.  Ideally,
it needs a good rewrite

Rahul

[Kevin Fenzi]

On Tue, 4 Feb 2014 11:09:15 -0500
Rahul Sundaram <metherid(a)gmail.com&gt; wrote:

>  Hi
>  
>  
>  On Tue, Feb 4, 2014 at 8:54 AM, Jaroslav Reznik wrote:
>  
>  > ----- Original Message -----
>  >
>  > It needs updates :). Any volunteer?
>  >
>  
>  I have updated it just to remove the obsolete content for now.
>  Ideally, it needs a good rewrite 
Agreed. 

Also, mentions of steps involving a 'spins sig' when there's not one
thats at all active probibly need to be re-worked. 

kevin

[Bruno Wolff III]

On Tue, Feb 04, 2014 at 08:54:15 -0500,
   Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
> Seems to be pretty outdated (*), we're past many things written there aka Live
> CD size - for example for desktop and KDE spins. So the CD part could be removed,
> I know several spins doing changes in defaults and it's really up to SIG
> standing behind spin than Spins SIG. 
The intention was that the Spins SIG would set these standards and enforce 
them. However, when participation in the Spins SIG stopped (even though 
someone from each spin was supposed to be participating), this became 
impracticle.

[Jaroslav Reznik]

----- Original Message -----
>  On Tue, Feb 4, 2014 at 2:02 PM, Matthew Miller <
> mattdm(a)fedoraproject.org >
>  wrote:
>  
>  
>  I'd also like to see some of the restrictions on spins loosened a little
>  bit. I think the spin/remix distinction (Fedora-only software vs. combined
>  with other things) is good, but, for example, spins, maybe it *would* be
>  okay to change software defaults in a way that isn't currently allowed.
>  Is there a "way that isn't currently allowed" actually? Spins can put
>  anything into %post, and some do modify configuration. (If nothing else, the
>  desktop spins change the default desktop...) 
And sendmail/rsyslog was one example. So yes, spin already do so. But stating
this formally/documented way would be worthy.

Jaroslav

>  Mirek
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Matthew Miller]

On Tue, Feb 04, 2014 at 08:48:12AM -0500, Jaroslav Reznik wrote:
>  > I'd also like to see some of the restrictions on spins
> loosened a little
>  > bit. I think the spin/remix distinction (Fedora-only software vs. combined
>  > with other things) is good, but, for example, spins, maybe it *would* be
>  > okay to change software defaults in a way that isn't currently allowed.
>  > Is there a "way that isn't currently allowed" actually? Spins can put
>  > anything into %post, and some do modify configuration. (If nothing else, the
>  > desktop spins change the default desktop...)
>  And sendmail/rsyslog was one example. So yes, spin already do so. But stating
>  this formally/documented way would be worthy. 
That was a particularly gray area because it's simply a matter of installing
a package or not. Installing rsyslog but configuring it to log differently
than the standard is another level of change (although of course also murky
when other applications change their behavior based on the presence or
absence of some other package).

-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Bill Nottingham]

Matthew Miller (mattdm(a)fedoraproject.org) said: 
>  On Tue, Feb 04, 2014 at 08:48:12AM -0500, Jaroslav Reznik wrote:
>  > > I'd also like to see some of the restrictions on spins loosened a little
>  > > bit. I think the spin/remix distinction (Fedora-only software vs. combined
>  > > with other things) is good, but, for example, spins, maybe it *would* be
>  > > okay to change software defaults in a way that isn't currently allowed.
>  > > Is there a "way that isn't currently allowed" actually? Spins can
> put
>  > > anything into %post, and some do modify configuration. (If nothing else, the
>  > > desktop spins change the default desktop...)
>  > And sendmail/rsyslog was one example. So yes, spin already do so. But stating
>  > this formally/documented way would be worthy.
>  
>  That was a particularly gray area because it's simply a matter of installing
>  a package or not. Installing rsyslog but configuring it to log differently
>  than the standard is another level of change (although of course also murky
>  when other applications change their behavior based on the presence or
>  absence of some other package). 
Yeah; the idea behind the guideline is that you want documentation to be
generally valid, for example - if you have resources that have to say "if
you're on X, do A, if you're on Y, do B..." it gets very unwieldy very fast,
and makes it much harder for users as well. We obviously are going to have
some of this with the assorted desktop spins, but imagine that level of
differences spread to yum vs apt (as a theoretical bad example.)

Bill

[Matthew Miller]

On Wed, Feb 05, 2014 at 10:27:44AM +0100, Bill Nottingham wrote:
>  > That was a particularly gray area because it's simply a
> matter of
>  > installing a package or not. Installing rsyslog but configuring it to
>  > log differently than the standard is another level of change (although
>  > of course also murky when other applications change their behavior based
>  > on the presence or absence of some other package).
>  Yeah; the idea behind the guideline is that you want documentation to be
>  generally valid, for example - if you have resources that have to say "if
>  you're on X, do A, if you're on Y, do B..." it gets very unwieldy very
> fast,
>  and makes it much harder for users as well. We obviously are going to have
>  some of this with the assorted desktop spins, but imagine that level of
>  differences spread to yum vs apt (as a theoretical bad example.) 
Agreed -- I think changes should be in proportion to the amount of separate
branding the spin has. If I'm running something which configures the system
in a very different way, I should *know*.

-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Frank Murphy]

On Thu, 30 Jan 2014 17:47:04 -0500
Przemek Klosowski <przemek.klosowski(a)nist.gov&gt; wrote:

>  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. 
Currently it is possible to:
yum grouplist
Available environment groups:
install what you want.
As long as it is(will be?) easy for Spin maintainers to do this.
There should be no problems 


___
Regards,
Frank 
www.frankly3d.com

[Frank Murphy]

On Wed, 29 Jan 2014 18:58:22 -0500
Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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). 
That doesn't sound right, 
logically below would also be true.
Gnome is a fairly big Spin,
and can eat up quite a lot of resources.
Maybe it should be outsourced.


___
Regards,
Frank 
www.frankly3d.com

[Christian Schaller]

The difference here is that the resources for GNOME (or anything else Red Hat needs for
future versions of RHEL) are 
provided by Red Hat. So if you want the spins to the logically the same in terms of
resources we should start demanding 
that any spin set up needs to provide an annual monetary contribution to help pay for the
Fedora infrastructure and team.

Christian

----- Original Message -----
>  From: "Frank Murphy" <frankly3d(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Thursday, January 30, 2014 9:06:24 AM
>  Subject: Re: Fedora.NEXT Products and the fate of Spins
>  
>  On Wed, 29 Jan 2014 18:58:22 -0500
>  Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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).
>  
>  That doesn't sound right,
>  logically below would also be true.
>  Gnome is a fairly big Spin,
>  and can eat up quite a lot of resources.
>  Maybe it should be outsourced.
>  
>  
>  ___
>  Regards,
>  Frank
>  www.frankly3d.com
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[piruthiviraj natarajan]

On Thu, Jan 30, 2014 at 4:10 PM, Christian Schaller <cschalle(a)redhat.com&gt;wrote:

>  The difference here is that the resources for GNOME (or anything else
> Red
>  Hat needs for future versions of RHEL) are
>  provided by Red Hat. So if you want the spins to the logically the same in
>  terms of resources we should start demanding
>  that any spin set up needs to provide an annual monetary contribution to
>  help pay for the Fedora infrastructure and team.
>  
So you mean to say the software(already existing in the repos)  which is
not of interest for red hat should pay to stay for fedora infrastructure
and Team to stay in the fedora repos?

This looks like clear business motive and no point in calling it a
community project at all.

[Christian Schaller]

----- Original Message -----
>  From: "piruthiviraj natarajan"
> <piruthiviraj(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Thursday, January 30, 2014 11:45:51 AM
>  Subject: Re: Fedora.NEXT Products and the fate of Spins
>  
>  
>  On Thu, Jan 30, 2014 at 4:10 PM, Christian Schaller < cschalle(a)redhat.com >
>  wrote:
>  
>  
>  
>  The difference here is that the resources for GNOME (or anything else Red Hat
>  needs for future versions of RHEL) are
>  provided by Red Hat. So if you want the spins to the logically the same in
>  terms of resources we should start demanding
>  that any spin set up needs to provide an annual monetary contribution to help
>  pay for the Fedora infrastructure and team.
>  
>  So you mean to say the software(already existing in the repos) which is not
>  of interest for red hat should pay to stay for fedora infrastructure and
>  Team to stay in the fedora repos?
>  
>  This looks like clear business motive and no point in calling it a community
>  project at all.
>   
What I mean to say is that Red Hat has a business motive to support the Fedora community,
if supporting Fedora was a pure act of charity then I think organizations like the Red
Cross
or Unicef would have a much better chance of getting the money.

So if the Fedora community wants to not care about why Red Hat invests in Fedora they are
of course free to do so,
but it becomes quite disingenuous to later be surprised if Red Hat loses interest in
Fedora.

Christian

[piruthiviraj natarajan]

On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller <cschalle(a)redhat.com&gt;wrote:

>  What I mean to say is that Red Hat has a business motive to support
> the
>  Fedora community,
>  if supporting Fedora was a pure act of charity then I think organizations
>  like the Red Cross
>  or Unicef would have a much better chance of getting the money.
>
>  So if the Fedora community wants to not care about why Red Hat invests in
>  Fedora they are of course free to do so,
>  but it becomes quite disingenuous to later be surprised if Red Hat loses
>  interest in Fedora.
>  
well this kind of strategy towards the community is not very inspiring for
the new contributors, is it?
I think there is interest in the fedora community for Gnome as well as
other DE which RHEL doesn't ship.
But since this thread has been moving in a direction where the Fedora spins
are under threat to exist in the repos doesn't bode well for the packages
that is not of interest to red hat.

[Richard Hughes]

On 30 January 2014 11:29, piruthiviraj natarajan <piruthiviraj(a)gmail.com&gt; wrote:
>  ...doesn't bode well for the packages that is not of interest to
> red hat. 
I think you're misinterpreting the words of Christian. Red Hat (also
my employer, but speaking for myself here) can't and shouldn't be pay
to fix and QA spins like LXDE or MATE. If keeping a MATE spin makes it
harder or slower for the people developing GNOME (which Red Hat should
sponsor) then I don't see the problem in his statement. Red Hat spends
a ton of money on Fedora, and I think a lot of the community seem to
forget that.

Richard

[piruthiviraj natarajan]

On Thu, Jan 30, 2014 at 5:16 PM, Richard Hughes <hughsient(a)gmail.com&gt; wrote:

>  I think you're misinterpreting the words of Christian. Red Hat (also
>  my employer, but speaking for myself here) can't and shouldn't be pay
>  to fix and QA spins like LXDE or MATE. If keeping a MATE spin makes it
>  harder or slower for the people developing GNOME (which Red Hat should
>  sponsor) then I don't see the problem in his statement. Red Hat spends
>  a ton of money on Fedora, and I think a lot of the community seem to
>  forget that. 

The QA already doesn't have blockers for spins. As adam has mentioned spins
don't affect QA's work or progress at all.

I understand red hat spends a lot of money on fedora, but wielding the
spins away is definitely a bad rapport for the community and it in turn a
negative thing to participate for the project too.

[Christian Schaller]

My statements was directly targeted at the often repeated attitude on this list which
seems to be that Red Hat should shut up and pay for whatever the given poster think should
be payed
for without having any expectations or requirements of the Fedora community in return.

The relationship between Red Hat and Fedora is very different from that of for instance
Debian and Ubuntu,
with Red Hat being a lot more directly involved in both contributing to Fedora and paying
for the
general upkeep of Fedora. Personally I always felt that this symbiotic relationship was a
big part of
what made Fedora interesting.

So in regards to the spins, which my original response didn't really try to address, I
think they should all become remixes
and I think we should try to build an infrastructure where doing a remix is as easy as
possible.
For example, in theory I think the Fedora project could provide some kind of web hosting
space for the remixes, to reduce the burden/threshold
for remix maintainers, but I do also see that there are legal and administrative reasons
for why that could be a bad idea, but I am sure that with
some discussion and investigation there are solutions that can be found to these practical
challenges.


Christian


----- Original Message -----
>  From: "piruthiviraj natarajan"
> <piruthiviraj(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Thursday, January 30, 2014 12:29:43 PM
>  Subject: Re: Fedora.NEXT Products and the fate of Spins
>  
>  
>  On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller < cschalle(a)redhat.com >
>  wrote:
>  
>  
>  
>  What I mean to say is that Red Hat has a business motive to support the
>  Fedora community,
>  if supporting Fedora was a pure act of charity then I think organizations
>  like the Red Cross
>  or Unicef would have a much better chance of getting the money.
>  
>  So if the Fedora community wants to not care about why Red Hat invests in
>  Fedora they are of course free to do so,
>  but it becomes quite disingenuous to later be surprised if Red Hat loses
>  interest in Fedora.
>  
>  well this kind of strategy towards the community is not very inspiring for
>  the new contributors, is it?
>  I think there is interest in the fedora community for Gnome as well as other
>  DE which RHEL doesn't ship.
>  But since this thread has been moving in a direction where the Fedora spins
>  are under threat to exist in the repos doesn't bode well for the packages
>  that is not of interest to red hat.
>  
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Jaroslav Reznik]

----- Original Message -----
>  My statements was directly targeted at the often repeated attitude on
> this
>  list which
>  seems to be that Red Hat should shut up and pay for whatever the given poster
>  think should be payed
>  for without having any expectations or requirements of the Fedora community
>  in return.
>  
>  The relationship between Red Hat and Fedora is very different from that of
>  for instance Debian and Ubuntu,
>  with Red Hat being a lot more directly involved in both contributing to
>  Fedora and paying for the
>  general upkeep of Fedora. Personally I always felt that this symbiotic
>  relationship was a big part of
>  what made Fedora interesting. 
+1 and I still think it works pretty well - Red Hat has a nice space to
do work on the future RHELs in open way (not like other so called open 
companies), community can contribute where there's interest.

Btw. I'm not saying there are no issues, or sometimes more misunderstandings
that always could be resolved.

>  So in regards to the spins, which my original response didn't
> really try to
>  address, I think they should all become remixes
>  and I think we should try to build an infrastructure where doing a remix is
>  as easy as possible.
>  For example, in theory I think the Fedora project could provide some kind of
>  web hosting space for the remixes, to reduce the burden/threshold
>  for remix maintainers 
And we call these spins now.

>  , but I do also see that there are legal and
>  administrative reasons for why that could be a bad idea, but I am sure that
>  with
>  some discussion and investigation there are solutions that can be found to
>  these practical challenges. 
That's one idea behind remixes - make it as easy as possible to remix Fedora
outside of Fedora space to avoid legal issues. 

Jaroslav

>  
>  Christian
>  
>  
>  ----- Original Message -----
>  > From: "piruthiviraj natarajan" <piruthiviraj(a)gmail.com&gt;
>  > To: "Development discussions related to Fedora"
>  > <devel(a)lists.fedoraproject.org&gt;
>  > Sent: Thursday, January 30, 2014 12:29:43 PM
>  > Subject: Re: Fedora.NEXT Products and the fate of Spins
>  > 
>  > 
>  > On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller < cschalle(a)redhat.com >
>  > wrote:
>  > 
>  > 
>  > 
>  > What I mean to say is that Red Hat has a business motive to support the
>  > Fedora community,
>  > if supporting Fedora was a pure act of charity then I think organizations
>  > like the Red Cross
>  > or Unicef would have a much better chance of getting the money.
>  > 
>  > So if the Fedora community wants to not care about why Red Hat invests in
>  > Fedora they are of course free to do so,
>  > but it becomes quite disingenuous to later be surprised if Red Hat loses
>  > interest in Fedora.
>  > 
>  > well this kind of strategy towards the community is not very inspiring for
>  > the new contributors, is it?
>  > I think there is interest in the fedora community for Gnome as well as
>  > other
>  > DE which RHEL doesn't ship.
>  > But since this thread has been moving in a direction where the Fedora spins
>  > are under threat to exist in the repos doesn't bode well for the packages
>  > that is not of interest to red hat.
>  > 
>  > 
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[piruthiviraj natarajan]

On Thu, Jan 30, 2014 at 6:04 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:

>  And we call these spins now.
>
>  > , but I do also see that there are legal and
>  > administrative reasons for why that could be a bad idea, but I am sure
>  that
>  > with
>  > some discussion and investigation there are solutions that can be found
>  to
>  > these practical challenges.
>
>  That's one idea behind remixes - make it as easy as possible to remix
>  Fedora
>  outside of Fedora space to avoid legal issues.
>  
Why is it a legal issue to have remix or spins in fedora space when they
are already shipping only free software?
I am not sure I really follow you here.

[Jaroslav Reznik]

----- Original Message -----
>  
>  On Thu, Jan 30, 2014 at 6:04 PM, Jaroslav Reznik < jreznik(a)redhat.com >
>  wrote:
>  
>  
>  
>  And we call these spins now.
>  
>  > , but I do also see that there are legal and
>  > administrative reasons for why that could be a bad idea, but I am sure that
>  > with
>  > some discussion and investigation there are solutions that can be found to
>  > these practical challenges.
>  
>  That's one idea behind remixes - make it as easy as possible to remix Fedora
>  outside of Fedora space to avoid legal issues.
>  
>  Why is it a legal issue to have remix or spins in fedora space when they are
>  already shipping only free software?
>  I am not sure I really follow you here. 
Spins are ok but we want to make easy to remix Fedora outside if you don't
want to follow Fedora rules - bad content, even that different name could be
an issue... So we let people outside to deal with it, just we ask them to
be polite and say they are based on our amazing work.

Jaroslav

>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Christian Schaller]

----- Original Message -----
>  From: "Jaroslav Reznik" <jreznik(a)redhat.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Thursday, January 30, 2014 1:34:45 PM
>  Subject: Re: Fedora.NEXT Products and the fate of Spins
>  
>  ----- Original Message -----
>  > My statements was directly targeted at the often repeated attitude on this
>  > list which
>  > seems to be that Red Hat should shut up and pay for whatever the given
>  > poster
>  > think should be payed
>  > for without having any expectations or requirements of the Fedora community
>  > in return.
>  > 
>  > The relationship between Red Hat and Fedora is very different from that of
>  > for instance Debian and Ubuntu,
>  > with Red Hat being a lot more directly involved in both contributing to
>  > Fedora and paying for the
>  > general upkeep of Fedora. Personally I always felt that this symbiotic
>  > relationship was a big part of
>  > what made Fedora interesting.
>  
>  +1 and I still think it works pretty well - Red Hat has a nice space to
>  do work on the future RHELs in open way (not like other so called open
>  companies), community can contribute where there's interest.
>  
>  Btw. I'm not saying there are no issues, or sometimes more misunderstandings
>  that always could be resolved.
>  
>  > So in regards to the spins, which my original response didn't really try to
>  > address, I think they should all become remixes
>  > and I think we should try to build an infrastructure where doing a remix is
>  > as easy as possible.
>  > For example, in theory I think the Fedora project could provide some kind
>  > of
>  > web hosting space for the remixes, to reduce the burden/threshold
>  > for remix maintainers
>  
>  And we call these spins now. 
Not exactly, to be clear what I was talking about here was fedora providing
hosting for someone to point their 'SuperDuperLinux.org' domain to. So that the
remixes wouldn't need to find separate web hosting. But as I think you also refer
to in your response, if we do that then there are probably similar legal restrictions
put on the remixes as are currently put on the spins.

>  
>  > , but I do also see that there are legal and
>  > administrative reasons for why that could be a bad idea, but I am sure that
>  > with
>  > some discussion and investigation there are solutions that can be found to
>  > these practical challenges.
>  
>  That's one idea behind remixes - make it as easy as possible to remix Fedora
>  outside of Fedora space to avoid legal issues.
>  
>  Jaroslav
>  
>  > 
>  > Christian
>  > 
>  > 
>  > ----- Original Message -----
>  > > From: "piruthiviraj natarajan" <piruthiviraj(a)gmail.com&gt;
>  > > To: "Development discussions related to Fedora"
>  > > <devel(a)lists.fedoraproject.org&gt;
>  > > Sent: Thursday, January 30, 2014 12:29:43 PM
>  > > Subject: Re: Fedora.NEXT Products and the fate of Spins
>  > > 
>  > > 
>  > > On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller < cschalle(a)redhat.com
>  > > >
>  > > wrote:
>  > > 
>  > > 
>  > > 
>  > > What I mean to say is that Red Hat has a business motive to support the
>  > > Fedora community,
>  > > if supporting Fedora was a pure act of charity then I think organizations
>  > > like the Red Cross
>  > > or Unicef would have a much better chance of getting the money.
>  > > 
>  > > So if the Fedora community wants to not care about why Red Hat invests in
>  > > Fedora they are of course free to do so,
>  > > but it becomes quite disingenuous to later be surprised if Red Hat loses
>  > > interest in Fedora.
>  > > 
>  > > well this kind of strategy towards the community is not very inspiring
>  > > for
>  > > the new contributors, is it?
>  > > I think there is interest in the fedora community for Gnome as well as
>  > > other
>  > > DE which RHEL doesn't ship.
>  > > But since this thread has been moving in a direction where the Fedora
>  > > spins
>  > > are under threat to exist in the repos doesn't bode well for the packages
>  > > that is not of interest to red hat.
>  > > 
>  > > 
>  > > --
>  > > devel mailing list
>  > > devel(a)lists.fedoraproject.org
>  > > https://admin.fedoraproject.org/mailman/listinfo/devel
>  > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Lukáš Tinkl]

Dne 30.1.2014 13:08, Christian Schaller napsal(a):
>  My statements was directly targeted at the often repeated attitude on
> this list which
>  seems to be that Red Hat should shut up and pay for whatever the given poster think
> should be payed
>  for without having any expectations or requirements of the Fedora community in return.
>
>  The relationship between Red Hat and Fedora is very different from that of for instance
> Debian and Ubuntu,
>  with Red Hat being a lot more directly involved in both contributing to Fedora and paying
> for the
>  general upkeep of Fedora. Personally I always felt that this symbiotic relationship was a
> big part of
>  what made Fedora interesting.
>
>  So in regards to the spins, which my original response didn't really try to address,
> I think they should all become remixes
>  and I think we should try to build an infrastructure where doing a remix is as easy as
> possible.
>  For example, in theory I think the Fedora project could provide some kind of web hosting
> space for the remixes, to reduce the burden/threshold
>  for remix maintainers, but I do also see that there are legal and administrative reasons
> for why that could be a bad idea, but I am sure that with
>  some discussion and investigation there are solutions that can be found to these
> practical challenges.
>
>
>  Christian
>  
I think dumping the spins is a very bad and dangerous idea for the whole 
Fedora/RHEL ecosystem. This will only drive the contributors away, and 
speaking of the KDE spin here, also a substantial user base.

-- 
Lukáš Tinkl <ltinkl(a)redhat.com&gt;
Software Engineer - KDE desktop team, Brno
KDE developer <lukas(a)kde.org&gt;
Red Hat Inc.                               http://cz.redhat.com

[Jóhann B. Guðmundsson]

On 01/30/2014 12:08 PM, Christian Schaller wrote:
>  My statements was directly targeted at the often repeated attitude on
> this list which
>  seems to be that Red Hat should shut up and pay for whatever the given poster think
> should be payed
>  for without having any expectations or requirements of the Fedora community in return.
Care to reference to what you get at here in you futile attempt of 
damage control?

By all means point me to the post and the places where our community 
members are demanding anything from Red Hat.

JBG

[Christian Schaller]

I can do better, I can provide you with one of these people to look at.
If you send me your postal address I will send you a mirror :)

Christian

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Thursday, January 30, 2014 1:39:11 PM
>  Subject: Re: Fedora.NEXT Products and the fate of Spins
>  
>  
>  On 01/30/2014 12:08 PM, Christian Schaller wrote:
>  > My statements was directly targeted at the often repeated attitude on this
>  > list which
>  > seems to be that Red Hat should shut up and pay for whatever the given
>  > poster think should be payed
>  > for without having any expectations or requirements of the Fedora community
>  > in return.
>  
>  Care to reference to what you get at here in you futile attempt of
>  damage control?
>  
>  By all means point me to the post and the places where our community
>  members are demanding anything from Red Hat.
>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Jóhann B. Guðmundsson]

On 01/30/2014 12:57 PM, Christian Schaller wrote:
>  I can do better, I can provide you with one of these people to look
> at.
>  If you send me your postal address I will send you a mirror:) 
Oh a funny man after this insult put up and point me to those post or 
shut up.

JBG

[Tomasz Torcz]

On Thu, Jan 30, 2014 at 07:08:16AM -0500, Christian Schaller wrote:
>  The relationship between Red Hat and Fedora is very different from
> that of for instance Debian and Ubuntu,
>  with Red Hat being a lot more directly involved in both contributing to Fedora and paying
> for the
>  general upkeep of Fedora. Personally I always felt that this symbiotic relationship was a
> big part of
>  what made Fedora interesting. 
  Yes, but please don't paint Red Hat bussiness goals as "Fedora community
goals".
There is some intersection, but not equality.

-- 
Tomasz Torcz       ,,(...) today's high-end is tomorrow's embedded
processor.''
xmpp: zdzichubg(a)chrome.pl                      -- Mitchell Blank on LKML

[Frank Murphy]

On Thu, 30 Jan 2014 14:15:56 +0100
Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:

>  Personally I always felt that this symbiotic relationship was a big
>  part of
>  > what made Fedora interesting.  
>  
>    Yes, but please don't paint Red Hat bussiness goals as "Fedora
>  community goals". There is some intersection, but not equality. 
I would love to see alt Desktops stay,
but at the end of the day.
The old saying comes to mind:
http://dictionary.cambridge.org/dictionary/british/he-who-pays-the-piper-...

That's a fact of life in any business relationship.




___
Regards,
Frank 
www.frankly3d.com

[Johannes Lips]

On Thu, Jan 30, 2014 at 2:33 PM, Frank Murphy <frankly3d(a)gmail.com&gt; wrote:

>  On Thu, 30 Jan 2014 14:15:56 +0100
>  Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
>
>  > Personally I always felt that this symbiotic relationship was a big
>  > part of
>  > > what made Fedora interesting.
>  >
>  >   Yes, but please don't paint Red Hat bussiness goals as "Fedora
>  > community goals". There is some intersection, but not equality.
>
>  I would love to see alt Desktops stay,
>  but at the end of the day.
>  The old saying comes to mind:
>
>  http://dictionary.cambridge.org/dictionary/british/he-who-pays-the-piper-...
>
>  That's a fact of life in any business relationship.
>  
Well, but it's not only about money and a lot of contributors use their
spare time to contribute, so I wouldn't stress this money thing too much.



>  ___
>  Regards,
>  Frank
>  www.frankly3d.com
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

[Frank Murphy]

On Thu, 30 Jan 2014 14:59:44 +0100
Johannes Lips <johannes.lips(a)gmail.com&gt; wrote:

>  Well, but it's not only about money and a lot of contributors
> use
>  their spare time to contribute, so I wouldn't stress this money thing
>  too much.
>   
I didn't introduce the money angle,
just putting into Common language,
what has been inferred.

___
Regards,
Frank 
www.frankly3d.com

[Jóhann B. Guðmundsson]

On 01/30/2014 02:02 PM, Frank Murphy wrote:
>  On Thu, 30 Jan 2014 14:59:44 +0100
>  Johannes Lips <johannes.lips(a)gmail.com&gt; wrote:
>
> > Well, but it's not only about money and a lot of contributors use
> > their spare time to contribute, so I wouldn't stress this money thing
> > too much.
> >
>  I didn't introduce the money angle,
>  just putting into Common language,
>  what has been inferred. 
One would think that Red Hat's community sponsorship is not a “venture 
capital” or "Investment" sponsorship but that it is a community 
sponsorship as it so clearly states everywhere but apparently Red Hat 
looks at it that way that it "owns" the community.

JBG

[Paul W. Frields]

On Thu, Jan 30, 2014 at 02:22:59PM +0000, "Jóhann B. Guðmundsson" wrote:
>  
>  On 01/30/2014 02:02 PM, Frank Murphy wrote:
>  >On Thu, 30 Jan 2014 14:59:44 +0100
>  >Johannes Lips <johannes.lips(a)gmail.com&gt; wrote:
>  >
>  >>Well, but it's not only about money and a lot of contributors use
>  >>their spare time to contribute, so I wouldn't stress this money thing
>  >>too much.
>  >>
>  >I didn't introduce the money angle,
>  >just putting into Common language,
>  >what has been inferred.
>  
>  One would think that Red Hat's community sponsorship is not a
>  “venture capital” or "Investment" sponsorship but that it is a
>  community sponsorship as it so clearly states everywhere but
>  apparently Red Hat looks at it that way that it "owns" the
>  community. 
> From your posts I undersetand that you believe that there is an entity
"Red Hat" that has a single thought process and attitude.  This is
patently untrue since Red Hat is a company made up of many people and
they have differing opinions.  Please stop painting everyone with one
brush.  It's not only non-constructive but it makes it less likely
over time that people interested in constructive discussion will
listen or participate.  It would have been nice had the conversation
started with a less incendiary idea than "pay to play," but hyperbole
doesn't help.

Now, that being said, I can tell you from personal experience that
past Boards have debated the value of Spins too, and there's nothing
sacred about questioning that value.  One could argue OLPC, a Fedora
Remix, achieved better visibilty and prominence than any Fedora spin.
A million laptops out there boot with "Fedora Remix" on their startup
screen, after all -- although certainly they are aging out.  Coupled
with better hosting and creation options, along with solving potential
legal issues, I think a community could be just as easily built (maybe
more so) around a Remix.

So let's not start by putting too much sacred value on the term
"Spin."  Rather, let's think about what specific technical and
community-building problems are caused by using Remixes, how to solve
them, and then consider that effort on balance against status quo.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[inode0]

On Thu, Jan 30, 2014 at 9:31 AM, Paul W. Frields <stickster(a)gmail.com&gt; wrote:
>  So let's not start by putting too much sacred value on the term
>  "Spin."  Rather, let's think about what specific technical and
>  community-building problems are caused by using Remixes, how to solve
>  them, and then consider that effort on balance against status quo. 
Paul, my personal problem with all this remix talk is more of a
branding thing. While a spin can be called a remix in the same sense
that a square can be called a rectangle we lose important information
by doing that. Spins are special cases of remixes that assert values
about the spin and its creators that are important both to the
creators and to the consumers. Saying this image is all free software
from Fedora matters to people. And I think it matters to Fedora too
which is why we allow spins to use trademarks differently than
remixes.

I can imagine a new organization of things. Perhaps a different way to
build and distribute what we now call spins. But I'm having a real
hard time calling them remixes or treating them in the same way as
remixes. And I think deciding the "fate" of spins before we even see
the "product" that will be all that is left to replace them is putting
the cart before the horse.

John

[Paul W. Frields]

On Thu, Jan 30, 2014 at 09:58:51AM -0600, inode0 wrote:
>  On Thu, Jan 30, 2014 at 9:31 AM, Paul W. Frields
> <stickster(a)gmail.com&gt; wrote:
>  > So let's not start by putting too much sacred value on the term
>  > "Spin."  Rather, let's think about what specific technical and
>  > community-building problems are caused by using Remixes, how to solve
>  > them, and then consider that effort on balance against status quo.
>  
>  Paul, my personal problem with all this remix talk is more of a
>  branding thing. While a spin can be called a remix in the same sense
>  that a square can be called a rectangle we lose important information
>  by doing that. Spins are special cases of remixes that assert values
>  about the spin and its creators that are important both to the
>  creators and to the consumers. Saying this image is all free software
>  from Fedora matters to people. And I think it matters to Fedora too
>  which is why we allow spins to use trademarks differently than
>  remixes.
>  
>  I can imagine a new organization of things. Perhaps a different way to
>  build and distribute what we now call spins. But I'm having a real
>  hard time calling them remixes or treating them in the same way as
>  remixes. And I think deciding the "fate" of spins before we even see
>  the "product" that will be all that is left to replace them is putting
>  the cart before the horse. 
That's fair.  I'm not advocating at this point that such a fate even
needs to be decided immediately.  What I tried to advocate was that we
not proceed in discussions about change from presumptions that things
can't.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Reindl Harald]

Am 30.01.2014 15:22, schrieb Jóhann B. Guðmundsson:
>  On 01/30/2014 02:02 PM, Frank Murphy wrote:
> > On Thu, 30 Jan 2014 14:59:44 +0100
> > Johannes Lips <johannes.lips(a)gmail.com&gt; wrote:
> >
> >> Well, but it's not only about money and a lot of contributors use
> >> their spare time to contribute, so I wouldn't stress this money thing
> >> too much.
> >>
> > I didn't introduce the money angle,
> > just putting into Common language,
> > what has been inferred.
>  
>  One would think that Red Hat's community sponsorship is not a “venture capital” or
> "Investment" sponsorship but
>  that it is a community sponsorship as it so clearly states everywhere but apparently Red
> Hat looks at it that way
>  that it "owns" the community 
think about you are the only on that list saing that

fact is that Redhat has not endless budget and ressources
so if you have ressources for a limited work you have to
make decisions, frankly that is even the same with no look
at money at all

[Richard Hughes]

On 30 January 2014 20:19, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  fact is that Redhat 
Pet peeve of mine: Please call Red Hat by it's proper name, or people
will start calling you Reindlharald.

Richard.

[Reindl Harald]

Am 30.01.2014 21:23, schrieb Richard Hughes:
>  On 30 January 2014 20:19, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> > fact is that Redhat
>  
>  Pet peeve of mine: Please call Red Hat by it's proper name, or people
>  will start calling you Reindlharald 
besides that you know what i meant with my post and that language
as written has finally the goal to understand what someone liked
to express with his words - it would be enough not calling me with
my last name as it often happens :-) Harald would be enough and
in the case of "Reindl" please "Mr. Reindl" :-)

there where i grown up my father, his grandfather and the neigbours
of his grandfather where called and written <lastname firstname>

well, i say it again with the grammar you like
_________________________

fact is that Red Hat has not endless budget and ressources
so if you have ressources for a limited work you have to
make decisions, frankly that is even the same with no look
at money at all

[Dan Mashal]

On Thu, Jan 30, 2014 at 6:22 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:
>  On 01/30/2014 02:02 PM, Frank Murphy wrote:
> >
> > On Thu, 30 Jan 2014 14:59:44 +0100
> > Johannes Lips <johannes.lips(a)gmail.com&gt; wrote:
> >
> >> Well, but it's not only about money and a lot of contributors use
> >> their spare time to contribute, so I wouldn't stress this money thing
> >> too much.
> >>
> > I didn't introduce the money angle,
> > just putting into Common language,
> > what has been inferred.
>
>
>  One would think that Red Hat's community sponsorship is not a "venture
>  capital" or "Investment" sponsorship but that it is a community
> sponsorship
>  as it so clearly states everywhere but apparently Red Hat looks at it that
>  way that it "owns" the community. 
I too often get this feeling.

If this is a "community sponsored project" and the community obviously
wants to keep things the way they are (leaving spins alone), then why
are various Red Hat employees constantly saying things like "Red Hat
is a business, and sponsors Gnome" and "My statements was directly
targeted at the often repeated attitude on this list which
seems to be that Red Hat should shut up and pay for whatever the given
poster think should be payed
for without having any expectations or requirements of the Fedora
community in return."

Enough of this! Nobody from the community is demanding anything from Red Hat.

Now, I'm not saying EVERYBODY from Red Hat has this attitude. But this
sentiment is OFTEN expressed.

To quote a Red Hatter which I believe has it absolutely right: "I
think dumping the spins is a very bad and dangerous idea for the whole
Fedora/RHEL ecosystem. This will only drive the contributors away, and
speaking of the KDE spin here, also a substantial user base."

In fact, why don't we take this to a vote instead of arguing about it
on this list? Why don't make this a Fedora elections issue?

Dan

[Michael Scherer]

Le jeudi 30 janvier 2014 à 12:28 -0800, Dan Mashal a écrit :

>  In fact, why don't we take this to a vote instead of arguing
> about it
>  on this list? Why don't make this a Fedora elections issue? 
for the same reasons as usual, ie practical ones, like voting mean
deciding who vote, ie, only board, fesco, all people in the packager
group, all people with a FAS, anybody that come ?

And for philosophical reasons like the simple fact that voting is
divisive and that's going against the idea of building a consensus. 


-- 
Michael Scherer

[Robert Mayr]

2014-01-30 Johannes Lips <johannes.lips(a)gmail.com&gt;:
>  On Thu, Jan 30, 2014 at 2:33 PM, Frank Murphy <frankly3d(a)gmail.com&gt; wrote:
> >
> > On Thu, 30 Jan 2014 14:15:56 +0100
> > Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
> >
> > > Personally I always felt that this symbiotic relationship was a big
> > > part of
> > > > what made Fedora interesting.
> > >
> > >   Yes, but please don't paint Red Hat bussiness goals as "Fedora
> > > community goals". There is some intersection, but not equality.
> >
> > I would love to see alt Desktops stay,
> > but at the end of the day.
> > The old saying comes to mind:
> >
> >
> http://dictionary.cambridge.org/dictionary/british/he-who-pays-the-piper-...
> >
> > That's a fact of life in any business relationship.
>
>  Well, but it's not only about money and a lot of contributors use their
>  spare time to contribute, so I wouldn't stress this money thing too much. 
+1

I feel also it is not ok that people, who spend their spare time to
contribute *without* getting money for that, get treated without
respect. Persoanlly I read Christian's post as an insult, but I'm sure
he didn't want to be so rough.

About spins:
I think we should go for 3 products, spins are not really a product.
In my opinion, (main desktop) spins should still exist under the
"Workstation" product. The others are more 'remixes' in my eyes.

-- 
Robert Mayr
(robyduck)

[Paul W. Frields]

On Thu, Jan 30, 2014 at 04:09:11PM +0100, Robert Mayr wrote:
>  2014-01-30 Johannes Lips <johannes.lips(a)gmail.com&gt;:
>  >
>  >
>  >
>  > On Thu, Jan 30, 2014 at 2:33 PM, Frank Murphy <frankly3d(a)gmail.com&gt; wrote:
>  >>
>  >> On Thu, 30 Jan 2014 14:15:56 +0100
>  >> Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
>  >>
>  >> > Personally I always felt that this symbiotic relationship was a big
>  >> > part of
>  >> > > what made Fedora interesting.
>  >> >
>  >> >   Yes, but please don't paint Red Hat bussiness goals as "Fedora
>  >> > community goals". There is some intersection, but not equality.
>  >>
>  >> I would love to see alt Desktops stay,
>  >> but at the end of the day.
>  >> The old saying comes to mind:
>  >>
>  >>
> http://dictionary.cambridge.org/dictionary/british/he-who-pays-the-piper-...
>  >>
>  >> That's a fact of life in any business relationship.
>  >
>  > Well, but it's not only about money and a lot of contributors use their
>  > spare time to contribute, so I wouldn't stress this money thing too much.
>  
>  +1
>  
>  I feel also it is not ok that people, who spend their spare time to
>  contribute *without* getting money for that, get treated without
>  respect. Persoanlly I read Christian's post as an insult, but I'm sure
>  he didn't want to be so rough. 
[...snip...]

Knowing Christian personally, I don't think he intended it that way.
But I think some people (I don't know about Christian) are frustrated
by the idea that any discussion of change is motivated by trying to
disenfranchise people, rather than figure out how Fedora can generate
product that increases its relevance and value to the FOSS ecosystem.


-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Haïkel]

I disagree about keeping spins around in the long term.

Current spins:
* hinders our communication (each spin is supposed to get proper coverage
from marketing, ambassadors etc.), some users think that actually
installing KDE requires reinstalling from the spin !
* prevents spins with a striving community [1] to get proper love from the
project. One of the main point of the product is to get *more* QA, *more*
polish, *more* communication than our current offering.
If a SIG is able to sustain a long-term effort in that direction, they
deserve to be a product !
About the desktop spins, i think they should be considered as sub-products
as it will requires some coordination between all the desktop folks for
some features.
* demoting spins to remixes won't prevent them to ship installable images,
to get support from other SIG (ie: design) but they won't get coverage from
marketing and ambassadors.

We can't afford having products, spins and remixes, that's just a waste of
efforts and we're lacking in manpower already.
Sustainable spins should become (sub-)products, the others remixes.
Until we can sort out the process for the maintained spins to become
(sub-)products, we should keep them for convenience but no longer.

One more thing, commitment is the only metric we should consider for
promoting a (sub-)product, i don't give a shit about having people paid to
work on that (no offense meant here).
No matter who our employers are, it should *NEVER* matter in Fedora, we're
all contributors. PERIOD


H.


[1] I think KDE SIG, I'm no user of the K Desktop but kudos guys for making
Fedora a choice distro for KDE users. You did great !

[Frank Murphy]

On Thu, 30 Jan 2014 16:35:54 +0100
H. Guémar <hguemar(a)fedoraproject.org&gt; wrote:

>  but they won't get coverage from
>  marketing and ambassadors
>  
Please don't include me in that,
I will always talk about 
Fedora supplied Xfce to all who will listen.

and supply said media to those that ask, if I can.
___
Regards,
Frank 
www.frankly3d.com

[Matthew Miller]

On Thu, Jan 30, 2014 at 05:51:31AM -0500, Christian Schaller wrote:
>  What I mean to say is that Red Hat has a business motive to support
> the
>  Fedora community, if supporting Fedora was a pure act of charity then I
>  think organizations like the Red Cross or Unicef would have a much better
>  chance of getting the money. 
This is certainly true, but the benefits to Red Hat also go far beyond the
immediate return on investment. And, many of those benefits simply do not
happen for Red Hat if the company does not _genuinely_ invest in community
support, including beyond current, obvious product connections. I know you
know that, but it doesn't come across clearly in your statements.

And, of course, for many Red Hatters, it's deeper than the cold financial
calculus. We care about this project and its values, and that's why we're
here.

-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Haïkel]

It's also a negative message to the 1.4 k active contributors in fedora.
Or do you assume that most of them are paid by RH which is unlikely.
Don't forget that fp.o has been founded with two stakeholders: RH and the
community

H.

[Robert Mayr]

2014-02-04 Matthew Miller <mattdm(a)fedoraproject.org&gt;:
>  On Thu, Jan 30, 2014 at 05:51:31AM -0500, Christian Schaller wrote:
> > What I mean to say is that Red Hat has a business motive to support the
> > Fedora community, if supporting Fedora was a pure act of charity then I
> > think organizations like the Red Cross or Unicef would have a much better
> > chance of getting the money.
>
>  This is certainly true, but the benefits to Red Hat also go far beyond the
>  immediate return on investment. And, many of those benefits simply do not
>  happen for Red Hat if the company does not _genuinely_ invest in community
>  support, including beyond current, obvious product connections. I know you
>  know that, but it doesn't come across clearly in your statements.
>
>  And, of course, for many Red Hatters, it's deeper than the cold financial
>  calculus. We care about this project and its values, and that's why we're
>  here.
>
>  --
>  Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt; 
Thank you Matt, I was very concerned about this statement indeed.
Haikel, you got the point of my thought too :)


-- 
Robert Mayr
(robyduck)

[Peter Robinson]

>  > On Thu, Jan 30, 2014 at 4:10 PM, Christian Schaller <
cschalle(a)redhat.com >
>  > wrote:
>  >
>  >
>  >
>  > The difference here is that the resources for GNOME (or anything else 
Red Hat
>  > needs for future versions of RHEL) are
>  > provided by Red Hat. So if you want the spins to the logically the same 
in
>  > terms of resources we should start demanding
>  > that any spin set up needs to provide an annual monetary contribution 
to help
>  > pay for the Fedora infrastructure and team.
>  >
>  > So you mean to say the software(already existing in the repos) which is 
not
>  > of interest for red hat should pay to stay for fedora
> infrastructure and
>  > Team to stay in the fedora repos?
>  >
>  > This looks like clear business motive and no point in calling it a 
community
>  > project at all.
>  >
>
>  What I mean to say is that Red Hat has a business motive to support the 
Fedora
community,
>  if supporting Fedora was a pure act of charity then I think
> organizations 
like the Red Cross
>  or Unicef would have a much better chance of getting the money.
>
>  So if the Fedora community wants to not care about why Red Hat invests in 
Fedora
they are of course free to do so,
>  but it becomes quite disingenuous to later be surprised if Red Hat
> loses 
interest in Fedora.

I think one of the points you miss here is that one of the cost benefits to
red hat outside of RHEL is a user on boarding process. Use olpc as an
example where red hat invested money outside of its traditional paying
customer use case, the university out reach programs are another example of
this.

[Frank Murphy]

On Thu, 30 Jan 2014 05:40:40 -0500 (EST)
Christian Schaller <cschalle(a)redhat.com&gt; wrote:

>  The difference here is that the resources for GNOME (or anything
> else
>  Red Hat needs for future versions of RHEL) are provided by Red Hat.
>  So if you want the spins to the logically the same in terms of
>  resources we should start demanding that any spin set up needs to
>  provide an annual monetary contribution to help pay for the Fedora
>  infrastructure and team.
>  
>  Christian
>  
That does indeed make sense for Red Hat future needs.

___
Regards,
Frank 
www.frankly3d.com

[Jiri Eischmann]

Christian Schaller píše v Čt 30. 01. 2014 v 05:40 -0500:
>  The difference here is that the resources for GNOME (or anything else
> Red Hat needs for future versions of RHEL) are 
>  provided by Red Hat. So if you want the spins to the logically the same in terms of
> resources we should start demanding 
>  that any spin set up needs to provide an annual monetary contribution to help pay for the
> Fedora infrastructure and team.
>  
>  Christian 
Well, I think there are not only monetary contributions. There are also
non-monetary contributions and we should not forget about them. IMHO
spins provide enough non-monetary contributions to Fedora to justify
their existence within the Project and consumption of resources that are
primarily sponsored by Red Hat.

There is not any reliable data of desktop usage among Fedora users, but
according to different polls almost half of our user base is using other
desktops, hence spins. They are used by many contributors, their users
also use, test and file bugs against parts of Fedora that are highly
interesting to Red Hat. Getting them out of the Project or placing any
financial barriers to entry the Project would mostly harm Red Hat in the
end.

Although I'm all for having a default spin that is primarily advertised
and offered to people new to Linux or Fedora I think we should remain a
distribution of choice. Getting spins out of Fedora and offer them the
remix status is not the best path to a larger user base. I don't think
that remix users report bugs in Fedora bugzilla much, for example.

Jiri

>  ----- Original Message -----
>  > From: "Frank Murphy" <frankly3d(a)gmail.com&gt;
>  > To: devel(a)lists.fedoraproject.org
>  > Sent: Thursday, January 30, 2014 9:06:24 AM
>  > Subject: Re: Fedora.NEXT Products and the fate of Spins
>  > 
>  > On Wed, 29 Jan 2014 18:58:22 -0500
>  > Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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).
>  > 
>  > That doesn't sound right,
>  > logically below would also be true.
>  > Gnome is a fairly big Spin,
>  > and can eat up quite a lot of resources.
>  > Maybe it should be outsourced.
>  > 
>  > 
>  > ___
>  > Regards,
>  > Frank
>  > www.frankly3d.com
>  > 
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Josh Boyer]

On Jan 30, 2014 3:06 AM, "Frank Murphy" <frankly3d(a)gmail.com&gt; wrote:
>  On Wed, 29 Jan 2014 18:58:22 -0500
>  Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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).
>
>  That doesn't sound right,
>  logically below would also be true.
>  Gnome is a fairly big Spin,
>  and can eat up quite a lot of resources.
>  Maybe it should be outsourced. 
I'm going to assume you mean the Desktop spin here.  If the Fedora project
decided to use some other DE as the default offering, then sure there could
be a GNOME spin hosted elsewhere.

There's a difference between a spin and the primary thing the project ships.

josh

[Jon]

On Wed, Jan 29, 2014 at 5:48 PM, inode0 <inode0(a)gmail.com&gt; wrote:
>  On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen
> <smooge(a)gmail.com&gt; wrote:
> > On 29 January 2014 15:49, inode0 <inode0(a)gmail.com&gt; wrote:
> >> On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard(a)gmail.com&gt; wrote:
> >> > Putting on my rel-eng hat I can say that any spin that fails to
> >> > compose will be dropped.
> >> >
> >> > I believe we also encourage or even require the spin maintainers to
> >> > test their spin as functional.
> >> > (To work out if the spin succeeds to compose but fails to actually work)
> >> >
> >> > The idea is to encourage active spin process, inactive spins will auto
> >> > retire by policy if they fail.
> >> >
> >> > Another aspect I worry about is the mirroring stuff.
> >> > With the coming WGs I fear the rsync mirroring will grow very large,
> >> > and spins are an attractive piece of fat to cut.
> >>
> >> You probably didn't mean for that to sound so negative but a piece of
> >> fat to cut is how rel-eng thinks of spins?
> >>
> >> I recall being assured at the beginning that some interested company
> >> was willing to provide the necessary support for us to give this a
> >> fair try.
> >>
> >
> > How long is a fair try? It would help to define that before people go on a
> > rant about doing it for a couple of years now.
>
>  I meant giving our new adventure a fair try, not giving spins a fair
>  try. I also really did not mean to go on a rant.
>
>  I think we have a group that sees little benefit to spins and another
>  that sees a lot of benefit to spins. The former wants to get rid of
>  them, the latter wants to keep them. We won't ever quantify the amount
>  of benefit they bring so we are probably at a stalemate on the benefit
>  question.
>
>  On the resources question we can either ask for them in order to allow
>  us to do both or we can look for new ways to reduce the cost of spins
>  to those complaining about the burden they impose. I'm open to either
>  of those approaches. Getting rid of them to me would be an admission
>  that are unwilling or unable to continue supporting something that is
>  valuable to our users and our community (just my subjective opinion
>  and I know not everyone shares it).
>
>  John 

There is a lot of value in the desktop spins.

Most of the folks I know personally use one spin or another.
I myself REMIX all of the desktop spins for my embedded stuff, and I
personally use MATE and/or XFCE.

It would be disappointing to drop the spins now that we have got them
to such a lofty place in our community.
We now hold them accountable to ensure quality, and the composes are
mostly automated into koji, so burden to keep them going is not much.
Mostly the space they consume is a thing to consider.

I'd like to imagine a day when the KDE spin replaces gnome3 as our
default desktop!
Or even XFCE or whatever....

Do not believe Gnome3 should have lock to the default desktop offering.
I would even go so far to propose a vote from the community every once
in a while to decide what is our so-called default.
And repeat that vote every once in a while... based on merits.

So I'd rather not see the desktop spins go away.
Not sure about the other spins, the pen testing, or software-stack
type things....
Since the burden is mostly storage, and storage is cheap... I tend to
think we can keep them going for now.
There is the part about mirroring, and the time it takes to compose
these things.

My two cents.

-Jon Disnard
FAS: parasense
IRC: masta


-- 

-Jon

[Stephen John Smoogen]

On 29 January 2014 16:48, inode0 <inode0(a)gmail.com&gt; wrote:

>  On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen
> <smooge(a)gmail.com&gt;
>  wrote:
>  > On 29 January 2014 15:49, inode0 <inode0(a)gmail.com&gt; wrote:
>  >> On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard(a)gmail.com&gt; wrote:
>  >> > Putting on my rel-eng hat I can say that any spin that fails to
>  >> > compose will be dropped.
>  >> >
>  >> > I believe we also encourage or even require the spin maintainers to
>  >> > test their spin as functional.
>  >> > (To work out if the spin succeeds to compose but fails to actually
>  work)
>  >> >
>  >> > The idea is to encourage active spin process, inactive spins will auto
>  >> > retire by policy if they fail.
>  >> >
>  >> > Another aspect I worry about is the mirroring stuff.
>  >> > With the coming WGs I fear the rsync mirroring will grow very large,
>  >> > and spins are an attractive piece of fat to cut.
>  >>
>  >> You probably didn't mean for that to sound so negative but a piece of
>  >> fat to cut is how rel-eng thinks of spins?
>  >>
>  >> I recall being assured at the beginning that some interested company
>  >> was willing to provide the necessary support for us to give this a
>  >> fair try.
>  >>
>  >
>  > How long is a fair try? It would help to define that before people go on
>  a
>  > rant about doing it for a couple of years now.
>
>  I meant giving our new adventure a fair try, not giving spins a fair
>  try. I also really did not mean to go on a rant.
>
>  
My apologies, we were talking about spins so I figured that was what you
were asking. In any case, it will be an important point for us to pin down
for the .Next.. how long are we committed to doing it and figuring out it
is working? I figure a minimum of 18-24 months would be needed but if it
needs to be longer then it needs to be guessed at so that expectations up
and down the tree are the same.



>  I think we have a group that sees little benefit to spins and
> another
>  that sees a lot of benefit to spins. The former wants to get rid of
>  them, the latter wants to keep them. We won't ever quantify the amount
>  of benefit they bring so we are probably at a stalemate on the benefit
>  question.
>
>  
Well to quantify it, we need to measure it. First off that probably means
tieing in some sort of 'check-in' counter to know what ones are run, how
much they are run, how many are installed, and how long are they installed.
That gets pretty intrusive to a lot of people. Then we make it opt in and
we get a count so low and manipulative that it becomes worthless otherwise.



>  On the resources question we can either ask for them in order to
> allow
>  us to do both or we can look for new ways to reduce the cost of spins
>  to those complaining about the burden they impose. I'm open to either
>  of those approaches. Getting rid of them to me would be an admission
>  that are unwilling or unable to continue supporting something that is
>  valuable to our users and our community (just my subjective opinion
>  and I know not everyone shares it).
>
>
> From a pure infrastructure point of view, the spins have the following 
major costs:

1) Disk space. Disks are not cheap in the world of data-access ready disks.
The 4 TB SATAs sound nice but when you try serving FTP off them you find
that you have to raid more than you did of the expensive SAS disks and your
effective amount of disk space you can use is in the range of 1-10% of the
disk space before you end up losing to speed of access, time to send, and
general disk drive latency. After that you have to replace the disks quite
often as they fail much sooner than any manufacturer says they will.

2) Our disk space goal for mirrors is 1 TB of disk space for the main
releases. That means N-1, N, and N+1 (alpha/beta/release).  We skim that
and every iso, architecture, and extra makes it harder to keep.

3) Net access. Large file sharing (500+ MB iso)  costs more than small file
sharing (rpms). It takes up  'streams' for longer in modern
routers/firewalls and thus you can fill up your pipe without saturating
your pipe. This used to be gotten around via various file sharing
mechanisms but these are increasingly getting shut down at the ISP and
Universities for any content.

4) Many mirrors skip the spins. That means the cost gets eaten up by those
that do and then they run into the top issues above which makes it more
likely they don't want to mirror them.

These are costs that all the mirrors have to pay on this and those are
things that are 'hidden' when people think 'oh we can make another spin, it
only takes me an hour to spin it up and test it.'

By the way, I am not anti-spin and consider the above costs to be things
that can't be paid now or in the future.. I am just wanting people to
realize that even beyond releng/qa resources this is not a 'freebie'.

-- 
Stephen J Smoogen.

[Adam Williamson]

On Wed, 2014-01-29 at 18:17 -0700, Stephen John Smoogen wrote:

>  
>  1) Disk space. Disks are not cheap in the world of data-access ready
>  disks. The 4 TB SATAs sound nice but when you try serving FTP off them
>  you find that you have to raid more than you did of the expensive SAS
>  disks and your effective amount of disk space you can use is in the
>  range of 1-10% of the disk space before you end up losing to speed of
>  access, time to send, and general disk drive latency. After that you
>  have to replace the disks quite often as they fail much sooner than
>  any manufacturer says they will.
>  
>  
>  2) Our disk space goal for mirrors is 1 TB of disk space for the main
>  releases. That means N-1, N, and N+1 (alpha/beta/release).  We skim
>  that and every iso, architecture, and extra makes it harder to keep.
>  
>  
>  3) Net access. Large file sharing (500+ MB iso)  costs more than small
>  file sharing (rpms). It takes up  'streams' for longer in modern
>  routers/firewalls and thus you can fill up your pipe without
>  saturating your pipe. This used to be gotten around via various file
>  sharing mechanisms but these are increasingly getting shut down at the
>  ISP and Universities for any content. 
>  
>  
>  4) Many mirrors skip the spins. That means the cost gets eaten up by
>  those that do and then they run into the top issues above which makes
>  it more likely they don't want to mirror them.
>  
>  
>  These are costs that all the mirrors have to pay on this and those are
>  things that are 'hidden' when people think 'oh we can make another
>  spin, it only takes me an hour to spin it up and test it.' 
>  
>  
>  By the way, I am not anti-spin and consider the above costs to be
>  things that can't be paid now or in the future.. I am just wanting
>  people to realize that even beyond releng/qa resources this is not a
>  'freebie'. 
Of course, another way of looking at this is to see that all these
things are the work we would be downloading onto several disparate
groups, who would almost certainly not be capable of doing it as well
and efficiently as Fedora releng is, if we decided to wash our hands of
spins.

jwb has tried to characterize this as an 'opportunity' for spins, but I
really don't think that washes. It's much more a case of us dumping a
whole lot of extra work onto any who wants to maintain a spin:

* Get a domain
* Get a proper SSL cert for your domain
* Figure out a build process - hack up some scripts which inevitably
grow into a baroque horror? Deploy your own koji?
* Figure out a QA process (we have provided a QA process for spins; this
cost us - well, me, personally - a few hours I was happy to spend
several releases ago, and it's in place and it works)
* Cover the costs of hosting, or convince someone to distribute your
bits
* Do all your own marketing
* Somehow try to make sure that tools like liveusb-creator include your
bits

I'm not sure I can imagine a spin maintainer who would be *happy* about
all this.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Josh Boyer]

On Jan 29, 2014 11:24 PM, "Adam Williamson" <awilliam(a)redhat.com&gt; wrote:
>  On Wed, 2014-01-29 at 18:17 -0700, Stephen John Smoogen wrote:
>
>  >
>  > 1) Disk space. Disks are not cheap in the world of data-access ready
>  > disks. The 4 TB SATAs sound nice but when you try serving FTP off them
>  > you find that you have to raid more than you did of the expensive SAS
>  > disks and your effective amount of disk space you can use is in the
>  > range of 1-10% of the disk space before you end up losing to speed of
>  > access, time to send, and general disk drive latency. After that you
>  > have to replace the disks quite often as they fail much sooner than
>  > any manufacturer says they will.
>  >
>  >
>  > 2) Our disk space goal for mirrors is 1 TB of disk space for the main
>  > releases. That means N-1, N, and N+1 (alpha/beta/release).  We skim
>  > that and every iso, architecture, and extra makes it harder to keep.
>  >
>  >
>  > 3) Net access. Large file sharing (500+ MB iso)  costs more than small
>  > file sharing (rpms). It takes up  'streams' for longer in modern
>  > routers/firewalls and thus you can fill up your pipe without
>  > saturating your pipe. This used to be gotten around via various file
>  > sharing mechanisms but these are increasingly getting shut down at the
>  > ISP and Universities for any content.
>  >
>  >
>  > 4) Many mirrors skip the spins. That means the cost gets eaten up by
>  > those that do and then they run into the top issues above which makes
>  > it more likely they don't want to mirror them.
>  >
>  >
>  > These are costs that all the mirrors have to pay on this and those are
>  > things that are 'hidden' when people think 'oh we can make another
>  > spin, it only takes me an hour to spin it up and test it.'
>  >
>  >
>  > By the way, I am not anti-spin and consider the above costs to be
>  > things that can't be paid now or in the future.. I am just wanting
>  > people to realize that even beyond releng/qa resources this is not a
>  > 'freebie'.
>
>  Of course, another way of looking at this is to see that all these
>  things are the work we would be downloading onto several disparate
>  groups, who would almost certainly not be capable of doing it as well
>  and efficiently as Fedora releng is, if we decided to wash our hands of
>  spins.
>
>  jwb has tried to characterize this as an 'opportunity' for spins, but I
>  really don't think that washes. It's much more a case of us dumping a
>  whole lot of extra work onto any who wants to maintain a spin:
>
>  * Get a domain
>  * Get a proper SSL cert for your domain
>  * Figure out a build process - hack up some scripts which inevitably
>  grow into a baroque horror? Deploy your own koji?
>  * Figure out a QA process (we have provided a QA process for spins; this
>  cost us - well, me, personally - a few hours I was happy to spend
>  several releases ago, and it's in place and it works)
>  * Cover the costs of hosting, or convince someone to distribute your
>  bits
>  * Do all your own marketing
>  * Somehow try to make sure that tools like liveusb-creator include your
>  bits
>
>  I'm not sure I can imagine a spin maintainer who would be *happy* about
>  all this. 
Your other reply said there is no burden for spins.  Yet you list a bunch
of things you classify as a whole lot of extra work.  Including QA.  Using
lack of burden as a reason to keep it and extra burden as an excuse not to
have spin maintainers do the spins outside of Fedora doesn't wash either.

josh

[Adam Williamson]

On Thu, 2014-01-30 at 06:42 -0500, Josh Boyer wrote:

>  > jwb has tried to characterize this as an 'opportunity'
> for spins,
>  but I
>  > really don't think that washes. It's much more a case of us dumping
>  a
>  > whole lot of extra work onto any who wants to maintain a spin:
>  >
>  > * Get a domain
>  > * Get a proper SSL cert for your domain
>  > * Figure out a build process - hack up some scripts which inevitably
>  > grow into a baroque horror? Deploy your own koji?
>  > * Figure out a QA process (we have provided a QA process for spins;
>  this
>  > cost us - well, me, personally - a few hours I was happy to spend
>  > several releases ago, and it's in place and it works)
>  > * Cover the costs of hosting, or convince someone to distribute your
>  > bits
>  > * Do all your own marketing
>  > * Somehow try to make sure that tools like liveusb-creator include
>  your
>  > bits
>  >
>  > I'm not sure I can imagine a spin maintainer who would be *happy*
>  about
>  > all this.
>  
>  Your other reply said there is no burden for spins. 
I said there was no extra *QA* burden. I did tentatively float an idea
that it wasn't a major burden for releng either, but I believe I
indicated I could hardly gainsay the releng folks on that.

>    Yet you list a bunch of things you classify as a whole lot of
> extra
>  work.  Including QA. 
Note the parenthesis:

"(we have provided a QA process for spins; this cost us - well, me,
personally - a few hours I was happy to spend several releases ago, and
it's in place and it works)"

We don't require ourselves to do any testing of spins, hence there is no
ongoing burden. Setting up the 'infrastructure' for spins QA was
trivial, because as long as spins are integrated with the main release
process, all we have to do is add a couple of extra tables to a wiki
page:

https://fedoraproject.org/wiki/QA:Desktop_validation_results_template

Each time a TC or RC comes out, we create a new instance of that
template. We'd do that whether we have non-blocking spins or not,
because it's the same page used to test the blocking spins. So since the
whole process is integrated, we get a decent QA process for desktop
spins at basically no cost.

Non-desktop spins could have their own template pages, which adds a huge
extra five seconds or so of work for us at each TC/RC point.

I sometimes *choose* to do spin testing, because I happen to think it is
a good and valuable thing to send out working Xfce, MATE, LXDE etc. But
it's entirely optional.

>    Using lack of burden as a reason to keep it and extra burden as an
>  excuse not to have spin maintainers do the spins outside of Fedora
>  doesn't wash either. 
When you put it *that* way...:)

So, let me pull the points together: so far as QA goes, having spins
does not impose extra required work on us. QA team members can choose to
help with spin testing if they think it's useful work, but nothing
requires the QA team to do any testing of non-blocking spins.

I will let releng speak for themselves on the question of what mandatory
ongoing work spins impose on them.

My other point is that by just being one part of a whole integrated
process, spins get a lot of useful things done for them in a fairly
efficient way, which if they were separated out from the main Fedora
process would not happen. This applies to the QA *infrastructure*; as I
indicated, providing the space for spins QA to occur is essentially free
for us, but if spins were no longer part of the main Fedora validation
process, that wouldn't be the case any more - spins would have to come
up with their own infrastructure, which would be rather more work. QA
wouldn't have to do that work, so from a selfish point of view I
shouldn't care, but *someone* would have to do it. It's inefficient.

The same also applies to the releng processes. As we have to build live
images anyway, we have a fairly good process for doing live builds
efficiently in place, and the spins are just 'more of the same'. Releng
folks seem to indicate that just having 'more of the same' can be a
problem for them in terms of resource availability, and that sucks - but
at least they don't have to keep re-inventing the processes. If we split
spins off, each spin is going to have to reinvent that process.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Frank Murphy]

On Wed, 29 Jan 2014 16:39:03 -0600
Jon <jdisnard(a)gmail.com&gt; wrote:

>  Another aspect I worry about is the mirroring stuff.
>  With the coming WGs I fear the rsync mirroring will grow very large,
>  and spins are an attractive piece of fat to cut.
>  Reducing size is something we worry about on the infra, rel-eng side
>  of things. 
If numbers of Gnome > || < non Gnome Desktops 
//* am not including DEs' as Spins */
if less than, do such students\devs\admins move from Fedora usage
as Fedora.next has nothing for them.
Is not the whole purpose of .next to prevent losing users.

If storage is the problem, cull all
Fedora EOL 3+ year releases\rpms etc.
Move spins when created to Linux tracker etc..

Or is it all an Exercise to limit Fedora to Gnome only?

___
Regards,
Frank 
www.frankly3d.com

[Adam Williamson]

On Thu, 2014-01-30 at 07:58 +0000, Frank Murphy wrote:

>  If storage is the problem, cull all
>  Fedora EOL 3+ year releases\rpms etc. 
We already do this - old releases are moved to
https://dl.fedoraproject.org/pub/archive/ , where they're stored
differently and not mirrored. We kinda ought to keep copies of them
around *somewhere* for historical purposes, though, we can't really just
burn them down.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Jaroslav Reznik]

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

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

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

Jaroslav

>  [1] https://fedoraproject.org/wiki/Remix
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >  
> >  iEYEARECAAYFAlLpZMwACgkQeiVVYja6o6NOIwCeP6Kr6FGVYLCdU9Uofv7Xrqm1
> >  e3oAoIEky2/IjoGBF9MqVlEbkG0jd4vv
> >  =KDoO
> >  -----END PGP SIGNATURE----- 
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Christian Schaller]

----- Original Message -----
>  From: "Jaroslav Reznik" <jreznik(a)redhat.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  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

[Jaroslav Reznik]

----- Original Message -----
>  ----- Original Message -----
>  > From: "Jaroslav Reznik" <jreznik(a)redhat.com&gt;
>  > To: "Development discussions related to Fedora"
>  > <devel(a)lists.fedoraproject.org&gt;
>  > 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 :) 
Good to hear you're thinking about it.

>  
>  > - 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. 
Yes, it would be end of Fedora as user facing brand. And also pretty demanding
to do it for different products.

>  > > 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. 
Same reason as for products outside Fedora brand - it would be pretty 
demanding to do so. On the other hand I think the rules could be set pretty
straight.

Jaroslav

>  Christian
>   
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Howard Howell]

On Thu, 2014-01-30 at 07:47 -0500, Christian Schaller wrote:
>  
>  
>  
>  ----- Original Message -----
>  > From: "Jaroslav Reznik" <jreznik(a)redhat.com&gt;
>  > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  > 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.

[Stephen Gallagher]

>  On Jan 31, 2014, at 3:30 AM, Les Howell <hlhowell(a)pacbell.net&gt;
> wrote:
>  
> > On Thu, 2014-01-30 at 07:47 -0500, Christian Schaller wrote:
> > 
> > 
> > 
> > ----- Original Message -----
> >> From: "Jaroslav Reznik" <jreznik(a)redhat.com&gt;
> >> To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
> >> 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.

[Frank Murphy]

On Fri, 31 Jan 2014 06:03:48 -0500 (EST)
Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  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. 
As long as "audience" is kept informed I think most thing will be fine,
But, I'm am a bit worried by "some" who are of the opinion if not Gnome,
then dump it. Without the option to install any pkg that may not have
the G word in it's name or origin.

Personally, I know currently, most DEs' can be installed with yum
groupinstall. But, that may not always be the case.

If it ends up as not being the case, users may just want to
code or whatever, without having to fight current distro to do so.

It may be easier to boot: non-Fedora-livemedia/DE-of-choice.
Carry on with your workflow. 

I hope the future proves me wrong,
but I fear a too restrictive product,
may increase the (user-base) emigration, not halt it.

___
Regards,
Frank 
www.frankly3d.com

[Adam Williamson]

On Fri, 2014-01-31 at 11:22 +0000, Frank Murphy wrote:
>  On Fri, 31 Jan 2014 06:03:48 -0500 (EST)
>  Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  
>  > 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.
>  
>  As long as "audience" is kept informed I think most thing will be fine,
>  But, I'm am a bit worried by "some" who are of the opinion if not Gnome,
>  then dump it. Without the option to install any pkg that may not have
>  the G word in it's name or origin.
>  
>  Personally, I know currently, most DEs' can be installed with yum
>  groupinstall. But, that may not always be the case. 
I haven't seen any indication that anyone wants that to change as part
of .next. What we're currently discussing is basically a deliverables
question: what collections-of-packages-in-some-sort-of-lump do we want
to release, under what names and branding, with what level of support,
etc etc etc. But I haven't seen anything in even the most radical
proposals which involves dumping non-Product bits from the repos.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Frank Murphy]

On Fri, 31 Jan 2014 10:53:17 -0800
Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  > Personally, I know currently, most DEs' can be installed
> with yum
>  > groupinstall. But, that may not always be the case.
>  
>  I haven't seen any indication that anyone wants that to change as part
>  of .next.  
I do sincerely hope you are correct.


___
Regards,
Frank 
www.frankly3d.com

[Emmanuel Seyman]

* Frank Murphy [31/01/2014 11:22] :
>  Personally, I know currently, most DEs' can be installed with yum
>  groupinstall. But, that may not always be the case. 
I'm going to go in the opposite direction. The old anaconda installer made it
hard to see what groups you were installing and how you could install others.
The new anaconda is much better in this regard and the need for spins is
lessened, imho.

Emmanuel

[Frank Murphy]

On Fri, 31 Jan 2014 22:50:59 +0100
Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:

>  * Frank Murphy [31/01/2014 11:22] :
>  >
>  > Personally, I know currently, most DEs' can be installed with yum
>  > groupinstall. But, that may not always be the case.
>  
>  I'm going to go in the opposite direction. The old anaconda installer
>  made it hard to see what groups you were installing and how you could
>  install others.  
The point is will there be choice, and only time will tell.
Anaconda won't be used to select groups during Desktop.product install,
if I've been following correctly.  
It will install what's considered "product" that the WG decides upon.
Fully understand and accept that. 
There may not be a DVD available beyond .next for multiple choice.


___
Regards,
Frank 
www.frankly3d.com

[Matthias Clasen]

On Fri, 2014-01-31 at 06:03 -0500, Stephen Gallagher wrote:
>  
>  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. 
The spins concept splits the community into small fiefdoms and creates
unnecessary divisions.

I've seen mails on this list recently where people proudly stated that
they would continue to advertise one particular spin at conferences etc,
regardless what the official Fedora products are. If that is how we
advertise 'Fedora', it is not really a surprise that our users are
unclear about what it really is...

[Lukáš Tinkl]

Dne 31.1.2014 14:20, Matthias Clasen napsal(a):
>  On Fri, 2014-01-31 at 06:03 -0500, Stephen Gallagher wrote:
> >
> > 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.
>
>  The spins concept splits the community into small fiefdoms and creates
>  unnecessary divisions.
>
>  I've seen mails on this list recently where people proudly stated that
>  they would continue to advertise one particular spin at conferences etc,
>  regardless what the official Fedora products are. If that is how we
>  advertise 'Fedora', it is not really a surprise that our users are
>  unclear about what it really is...
>  
Fedora isn't a Gnome OS, perhaps that's what they're trying to convey; 
making it one will most probably create less confusion but I'm sure it 
will also make us less relevant (my personal opinion).

-- 
Lukáš Tinkl <ltinkl(a)redhat.com&gt;
Software Engineer - KDE desktop team, Brno
KDE developer <lukas(a)kde.org&gt;
Red Hat Inc.                               http://cz.redhat.com

[Frank Murphy]

On Fri, 31 Jan 2014 14:34:17 +0100
Lukáš Tinkl <ltinkl(a)redhat.com&gt; wrote:

>  Fedora isn't a Gnome OS, perhaps that's what they're
> trying to
>  convey; making it one will most probably create less confusion but
>  I'm sure it will also make us less relevant (my personal opinion).
>  
Currently it's not, it is a default DE, no problem there.

___
Frank 
www.frankly3d.com

[Matthias Clasen]

On Fri, 2014-01-31 at 14:34 +0100, Lukáš Tinkl wrote:

>  Fedora isn't a Gnome OS, perhaps that's what they're
> trying to convey; 
>  making it one will most probably create less confusion but I'm sure it 
>  will also make us less relevant (my personal opinion). 
Not sure why that was necessary, but I'll answer anyway:

I would be happy if Fedora moves towards being an OS, with a clear
separation between system and applications, and a clear definition of
what is part of the core system and what isn't. I don't think it makes
sense to discuss products if we don't agree on that as a necessity.

[Colin Walters]

On Fri, Jan 31, 2014 at 9:02 AM, Matthias Clasen <mclasen(a)redhat.com&gt; 
wrote:
>  
>  I would be happy if Fedora moves towards being an OS,
>   
Red Hat Enterprise Linux comes in both Server and Workstation variants, 
among others.  To continue to serve a useful role as upstream, I 
believe Fedora should be able to do *both* of these (and more).  It 
hurts our downstream if we completely lose the server or client polish, 
and one has to be retrofitted after the fact.

I think we *can* do both at the same time, while also not being a 
collection of packages.  We can walk and chew bubble gum at the same 
time.  To learn more about some technology I'm working on in that area, 
come to my devconf.cz talk =)

[Frank Murphy]

On Fri, 31 Jan 2014 08:20:18 -0500
Matthias Clasen <mclasen(a)redhat.com&gt; wrote:

>  I've seen mails on this list recently where people proudly stated
> that
>  they would continue to advertise one particular spin at conferences
>  etc 
The current product is not Gnome, it is Fedora.
And if asked about Xfce, which I solely use with Fedora. 
I will answer.


___
Regards,
Frank 
www.frankly3d.com

[Stephen Gallagher]

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

[Rahul Sundaram]

Hi


On Thu, Jan 30, 2014 at 11:01 AM, Stephen Gallagher wrote:

>  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.
>  
Part of the problem I have with this discussion other than the alarmist
subject is that we are discussing the "fate of spins" before even coming
out with concrete products out of the fedora.next proposals.  That seems
premature.

Rahul

[Jiri Eischmann]

Rahul Sundaram píše v Čt 30. 01. 2014 v 11:06 -0500:
>  Hi
>  
>  
>  On Thu, Jan 30, 2014 at 11:01 AM, Stephen Gallagher wrote:
>          
>          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.
>  
>  
>  Part of the problem I have with this discussion other than the
>  alarmist subject is that we are discussing the "fate of spins" before
>  even coming out with concrete products out of the fedora.next
>  proposals.  That seems premature.  
+1
I cannot agree more. We still don't have (at least I don't) have a clear
idea how basics of Fedora.NEXT will look. So this discussion is really
kinda premature. We should clearly define the products first, then we
can discuss spins and the border between them and remixes. From bottom
up please :)

Jiri

[Bill Nottingham]

Jiri Eischmann (eischmann(a)redhat.com) said: 
>  >         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.
>  > 
>  > 
>  > Part of the problem I have with this discussion other than the
>  > alarmist subject is that we are discussing the "fate of spins" before
>  > even coming out with concrete products out of the fedora.next
>  > proposals.  That seems premature. 
>  
>  +1
>  I cannot agree more. We still don't have (at least I don't) have a clear
>  idea how basics of Fedora.NEXT will look. So this discussion is really
>  kinda premature. We should clearly define the products first, then we
>  can discuss spins and the border between them and remixes. From bottom
>  up please :) 
Blame me, I filed the original ticket. My concern was that we're (obviously)
doing work in the Fedora.next space around:

1) the three products (workstation, server, cloud)
2) the base, which lives under them in some manner
3) environments & stacks, which can live on top of them

First, I'm making the assumption that those three products are not the
end-all/be-all of what Fedora can ever be. So we should have a defined
process for how new products can be formed. And that can tie into some
things that are now spins, if they want to go that route.

Second, as we design how we build and ship all of those things above, it
stands to reason that implementation choices made there have the possibility
of breaking spins as they exist now.  That shouldn't happen in a complete
vacuum without warning, so it's worth discussing where things that are spins
now fit into that process.

Bill

[Adam Williamson]

On Thu, 2014-01-30 at 14:53 -0500, Bill Nottingham wrote:
>  Jiri Eischmann (eischmann(a)redhat.com) said: 
>  > >         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.
>  > > 
>  > > 
>  > > Part of the problem I have with this discussion other than the
>  > > alarmist subject is that we are discussing the "fate of spins"
> before
>  > > even coming out with concrete products out of the fedora.next
>  > > proposals.  That seems premature. 
>  > 
>  > +1
>  > I cannot agree more. We still don't have (at least I don't) have a clear
>  > idea how basics of Fedora.NEXT will look. So this discussion is really
>  > kinda premature. We should clearly define the products first, then we
>  > can discuss spins and the border between them and remixes. From bottom
>  > up please :)
>  
>  Blame me, I filed the original ticket. My concern was that we're (obviously)
>  doing work in the Fedora.next space around:
>  
>  1) the three products (workstation, server, cloud)
>  2) the base, which lives under them in some manner
>  3) environments & stacks, which can live on top of them
>  
>  First, I'm making the assumption that those three products are not the
>  end-all/be-all of what Fedora can ever be. So we should have a defined
>  process for how new products can be formed. And that can tie into some
>  things that are now spins, if they want to go that route.
>  
>  Second, as we design how we build and ship all of those things above, it
>  stands to reason that implementation choices made there have the possibility
>  of breaking spins as they exist now.  That shouldn't happen in a complete
>  vacuum without warning, so it's worth discussing where things that are spins
>  now fit into that process. 
Looked at that way it's obviously an important question to answer
indeed.

I've written two posts on this topic and ripped them up for being
excessively negative, but let me try one more time:

I think part of the worry is the tension between having a product which
is clearly focused around the GNOME desktop (please, can we just agree
on this? I'm not saying it's a bad thing, but I don't think the 'but we
haven't picked a desktop!' hedge is contributing to the clarity of
discussion: it is patently obvious that Workstation is going to be
GNOME), and what that means for all the other desktop spins.

If we decide the alternative desktops are a valuable part of Fedora -
which seems to be a popular opinion - how do we fit them into a
Product-based conception of Fedora?

We can have a KDE Product, and an Xfce Product, and an LXDE Product,
but...at that point haven't we just re-invented spins? It doesn't seem
to quite work with the Product conception.

I'm sure there is a solution for this, and I don't want it to come off
as stop energy. I just wanted to try and have a stab at identifying the
source of concern.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Josh Boyer]

On Thu, Jan 30, 2014 at 3:16 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Thu, 2014-01-30 at 14:53 -0500, Bill Nottingham wrote:
> > Jiri Eischmann (eischmann(a)redhat.com) said:
> > > >         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.
> > > >
> > > >
> > > > Part of the problem I have with this discussion other than the
> > > > alarmist subject is that we are discussing the "fate of spins"
> before
> > > > even coming out with concrete products out of the fedora.next
> > > > proposals.  That seems premature.
> > >
> > > +1
> > > I cannot agree more. We still don't have (at least I don't) have a
> clear
> > > idea how basics of Fedora.NEXT will look. So this discussion is really
> > > kinda premature. We should clearly define the products first, then we
> > > can discuss spins and the border between them and remixes. From bottom
> > > up please :)
> >
> > Blame me, I filed the original ticket. My concern was that we're (obviously)
> > doing work in the Fedora.next space around:
> >
> > 1) the three products (workstation, server, cloud)
> > 2) the base, which lives under them in some manner
> > 3) environments & stacks, which can live on top of them
> >
> > First, I'm making the assumption that those three products are not the
> > end-all/be-all of what Fedora can ever be. So we should have a defined
> > process for how new products can be formed. And that can tie into some
> > things that are now spins, if they want to go that route.
> >
> > Second, as we design how we build and ship all of those things above, it
> > stands to reason that implementation choices made there have the possibility
> > of breaking spins as they exist now.  That shouldn't happen in a complete
> > vacuum without warning, so it's worth discussing where things that are spins
> > now fit into that process.
>
>  Looked at that way it's obviously an important question to answer
>  indeed.
>
>  I've written two posts on this topic and ripped them up for being
>  excessively negative, but let me try one more time:
>
>  I think part of the worry is the tension between having a product which
>  is clearly focused around the GNOME desktop (please, can we just agree
>  on this? I'm not saying it's a bad thing, but I don't think the 'but we
>  haven't picked a desktop!' hedge is contributing to the clarity of
>  discussion: it is patently obvious that Workstation is going to be
>  GNOME), and what that means for all the other desktop spins. 
I'll agree that it's the most likely outcome, sure.  I still think
there's value in not just assuming things though, and actually going
through the process/discussion.  Saying something is official before
it's official is stupid.

>  If we decide the alternative desktops are a valuable part of Fedora
> -
>  which seems to be a popular opinion - how do we fit them into a
>  Product-based conception of Fedora?
>
>  We can have a KDE Product, and an Xfce Product, and an LXDE Product,
>  but...at that point haven't we just re-invented spins? It doesn't seem
>  to quite work with the Product conception. 
Agreed.  As I said in my reply to John, there's a larger branding
conversation to be had.

josh

[Kevin Kofler]

Adam Williamson wrote:
>  We can have a KDE Product, and an Xfce Product, and an LXDE Product,
>  but...at that point haven't we just re-invented spins? It doesn't seem
>  to quite work with the Product conception. 
Why not?

I see only 2 acceptable outcomes, either KDE becomes a Product or the whole 
concept of "Products" gets dropped.

The KDE spin has always been a release-blocking deliverable, why should we 
get degraded to a second-class citizen?

        Kevin Kofler

[Kevin Kofler]

PS:

I wrote:

>  Adam Williamson wrote:
>  The KDE spin has always been a release-blocking deliverable, why should we
>  get degraded to a second-class citizen? 
Sorry, poor choice of words there: The KDE spin has been a release-blocking 
deliverable for years. This hasn't ALWAYS been the case, in fact I do 
remember that we did have to fight for this achievement, but I really don't 
long back to the dark ages where we didn't have that status.

The goal should be to let ALL desktop spins get equal treatment (and equal 
with the GNOME spin no matter whether it's called "Desktop Spin", 
"Workstation Product" or whatever silly marketing name), and in particular, 
release-blocking status, NOT to remove it from the KDE Spin.

Why does Fedora always have to give GNOME preferential treatment?

        Kevin Kofler

[Robert Mayr]

2014-02-02 Kevin Kofler <kevin.kofler(a)chello.at&gt;:
>  Adam Williamson wrote:
> > We can have a KDE Product, and an Xfce Product, and an LXDE Product,
> > but...at that point haven't we just re-invented spins? It doesn't seem
> > to quite work with the Product conception.
>
>  Why not?
>
>  I see only 2 acceptable outcomes, either KDE becomes a Product or the whole
>  concept of "Products" gets dropped.
>
>  The KDE spin has always been a release-blocking deliverable, why should we
>  get degraded to a second-class citizen?
>
>          Kevin Kofler 
Why do you think only about KDE? This topic shouldn't turn into a DE war IMHO.
The product for Desktop users should be just one, Workstation. And
KDE, as Xfce or LXDE are part of this product and should live under
the wing of the Workstation. That's not a degration in my eyes, just
another array, and it's not constructive to have for every DE
environment a separate product. Fedora.next is not this, fedora.next
aims to have 3 main products for different use cases, there is no
reason to have a separate product for every single Spin unless we want
to go backwards again.

-- 
Robert Mayr
(robyduck)

[Ralf Corsepius]

On 02/02/2014 11:57 PM, Robert Mayr wrote:
>  2014-02-02 Kevin Kofler <kevin.kofler(a)chello.at&gt;:
> > Adam Williamson wrote:
> >> We can have a KDE Product, and an Xfce Product, and an LXDE Product,
> >> but...at that point haven't we just re-invented spins? It doesn't seem
> >> to quite work with the Product conception.
> >
> > Why not?
> >
> > I see only 2 acceptable outcomes, either KDE becomes a Product or the whole
> > concept of "Products" gets dropped.
> >
> > The KDE spin has always been a release-blocking deliverable, why should we
> > get degraded to a second-class citizen?
> >
> >          Kevin Kofler
>
>  Why do you think only about KDE? This topic shouldn't turn into a DE war IMHO.
>  The product for Desktop users should be just one, Workstation. And
>  KDE, as Xfce or LXDE are part of this product and should live under
>  the wing of the Workstation. That's not a degration in my eyes, just
>  another array, and it's not constructive to have for every DE
>  environment a separate product. 
I do not think it's useful to split Fedora into any amount of "products" 
(I also have never considered the spins to be useful).

IMO, a Linux distro.is a "construction kit", where _users_ should be 
able to choose to compose their own setup, not what some committee, 
secret cabal or "WG" thinks the user should choose.

>  Fedora.next is not this, fedora.next
>  aims to have 3 main products for different use cases, there is no
>  reason to have a separate product for every single Spin unless we want
>  to go backwards again. 
Actually, I think Fedora is going backwards in time, ...

Ralf

[Chris Murphy]

On Feb 2, 2014, at 5:34 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:

>  On 02/02/2014 11:57 PM, Robert Mayr wrote:
> > 2014-02-02 Kevin Kofler <kevin.kofler(a)chello.at&gt;:
> >> Adam Williamson wrote:
> >>> We can have a KDE Product, and an Xfce Product, and an LXDE Product,
> >>> but...at that point haven't we just re-invented spins? It doesn't
> seem
> >>> to quite work with the Product conception.
> >> 
> >> Why not?
> >> 
> >> I see only 2 acceptable outcomes, either KDE becomes a Product or the whole
> >> concept of "Products" gets dropped.
> >> 
> >> The KDE spin has always been a release-blocking deliverable, why should we
> >> get degraded to a second-class citizen?
> >> 
> >>         Kevin Kofler
> > 
> > Why do you think only about KDE? This topic shouldn't turn into a DE war IMHO.
> > The product for Desktop users should be just one, Workstation. And
> > KDE, as Xfce or LXDE are part of this product and should live under
> > the wing of the Workstation. That's not a degration in my eyes, just
> > another array, and it's not constructive to have for every DE
> > environment a separate product.
>  
>  I do not think it's useful to split Fedora into any amount of "products" (I
> also have never considered the spins to be useful).
>  
>  IMO, a Linux distro.is a "construction kit", where _users_ should be able to
> choose to compose their own setup, not what some committee, secret cabal or "WG"
> thinks the user should choose. 
This makes no sense, either to describe Fedora.last or Fedora.next. I could pick any
distribution and compose my own setup if I'm willing to work hard enough at it. But I
want people, who I think actually know better than I do, to discover and define what best
practices are or need to be matured; to make a clear bet on what technologies are nascent
but have a good chance of being viable, and laying out a suggested path for implementation
and future work. I consider that a proposal which I can take or leave. Even by
constraining my choices, I gain by opting in. It's flawed logic that says more choice
is inherently better. There's a reason why we  have concepts like focus, emphasis,
prominence and triage. All things are not equal.


> > Fedora.next is not this, fedora.next
> > aims to have 3 main products for different use cases, there is no
> > reason to have a separate product for every single Spin unless we want
> > to go backwards again.
>  
>  Actually, I think Fedora is going backwards in time, … 
If that's true, at least then it's not stuck in time, which would be decidedly
worse. If it really is going backwards, this whole adventure will all the sooner reveal
itself as the wrong direction. But I think it's a necessary process in eventually
moving forward in any case.



Chris Murphy

[Kevin Kofler]

Robert Mayr wrote:
>  Why do you think only about KDE? 
The other desktops should be considered separate Products, too. It's time to 
stop treating them as second-class citizens that we won't even wait a few 
days for with our releases.

>  This topic shouldn't turn into a DE war IMHO. The product for
> Desktop
>  users should be just one, Workstation. And KDE, as Xfce or LXDE are part
>  of this product and should live under the wing of the Workstation. 
That way we either do no live images, or bad live images, with a menu filled 
with lots of applications that do the same thing, unless we start abusing 
Only/NotShowIn, which would suck for those people who do want to use e.g. 
Okular under GNOME.

I don't think a single image for all desktops is a good idea.

        Kevin Kofler

[Matthew Miller]

On Thu, Jan 30, 2014 at 12:16:16PM -0800, Adam Williamson wrote:
>  If we decide the alternative desktops are a valuable part of Fedora
> -
>  which seems to be a popular opinion - how do we fit them into a
>  Product-based conception of Fedora?
>  
>  We can have a KDE Product, and an Xfce Product, and an LXDE Product,
>  but...at that point haven't we just re-invented spins? It doesn't seem
>  to quite work with the Product conception. 
I would like to see Products defined by the problem space that they are
aimed at rather than the technology they're based on. That is, a "Fedora
Scientific Desktop" is a lot more compelling to me than "Fedora KDE" -- at
least as a product. But I don't think there's anything wrong with Fedora KDE
as either a spin or something else.

For that matter, there could be a "Fedora GNOME" spin distinct from the
Fedora Workstation product, if there were people really keen to work on it,
perhap as a showcase of upstream technology without worrying about the
concerns of the Fedora Workstation WG's particular area of focus. (With
"people keen to work on it" as the really key phrase.)


-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Jóhann B. Guðmundsson]

On 02/04/2014 10:39 AM, Matthew Miller wrote:
>  On Thu, Jan 30, 2014 at 12:16:16PM -0800, Adam Williamson wrote:
> > If we decide the alternative desktops are a valuable part of Fedora -
> > which seems to be a popular opinion - how do we fit them into a
> > Product-based conception of Fedora?
> >
> > We can have a KDE Product, and an Xfce Product, and an LXDE Product,
> > but...at that point haven't we just re-invented spins? It doesn't seem
> > to quite work with the Product conception.
>  I would like to see Products defined by the problem space that they are
>  aimed at rather than the technology they're based on. That is, a "Fedora
>  Scientific Desktop" is a lot more compelling to me than "Fedora KDE" --
> at
>  least as a product. But I don't think there's anything wrong with Fedora KDE
>  as either a spin or something else.
>
>  For that matter, there could be a "Fedora GNOME" spin distinct from the
>  Fedora Workstation product, if there were people really keen to work on it,
>  perhap as a showcase of upstream technology without worrying about the
>  concerns of the Fedora Workstation WG's particular area of focus. (With
>  "people keen to work on it" as the really key phrase.)
>
>  
But you cannot overlap products as in you cannot have a "Gnome 
workstation and "KDE workstation" etc you cannot have an "Server" 
product outside what is already defined in the ServerWG nor a "Cloud" 
product outside what is already defined there.

Basically what's happening here is that "default" is being applied to 
now three spaces which filled with Red Hat products and elevated above 
community contribution just like Gnome was put above all community 
contributions as an "Default".

Do people truly really want us to move forward with this discrimination 
between contributions to the project?

JBG

[Reindl Harald]

Am 04.02.2014 11:57, schrieb Jóhann B. Guðmundsson:
>  On 02/04/2014 10:39 AM, Matthew Miller wrote:
> > On Thu, Jan 30, 2014 at 12:16:16PM -0800, Adam Williamson wrote:
> >> If we decide the alternative desktops are a valuable part of Fedora -
> >> which seems to be a popular opinion - how do we fit them into a
> >> Product-based conception of Fedora?
> >>
> >> We can have a KDE Product, and an Xfce Product, and an LXDE Product,
> >> but...at that point haven't we just re-invented spins? It doesn't seem
> >> to quite work with the Product conception.
> > I would like to see Products defined by the problem space that they are
> > aimed at rather than the technology they're based on. That is, a "Fedora
> > Scientific Desktop" is a lot more compelling to me than "Fedora KDE"
> -- at
> > least as a product. But I don't think there's anything wrong with Fedora KDE
> > as either a spin or something else.
> >
> > For that matter, there could be a "Fedora GNOME" spin distinct from the
> > Fedora Workstation product, if there were people really keen to work on it,
> > perhap as a showcase of upstream technology without worrying about the
> > concerns of the Fedora Workstation WG's particular area of focus. (With
> > "people keen to work on it" as the really key phrase.)
>  
>  But you cannot overlap products as in you cannot have a "Gnome workstation and
> "KDE workstation" etc you cannot
>  have an "Server" product outside what is already defined in the ServerWG nor a
> "Cloud" product outside what is
>  already defined there.
>  
>  Basically what's happening here is that "default" is being applied to now
> three spaces which filled with Red Hat
>  products and elevated above community contribution just like Gnome was put above all
> community contributions as an
>  "Default".
>  
>  Do people truly really want us to move forward with this discrimination between
> contributions to the project? 
honestly going back to only a install DVD with a sane user-UI and dedicate all
the time wasted for the spin/products/discrimination discussions for documentations,
screenshots and howtos would have more benefit for Fedora

there is nothing you can't setup with the "one fits all" DVD or even with
a slim network install if you only knew what to install and how to configure

[Przemek Klosowski]

On 02/04/2014 06:15 AM, Reindl Harald wrote:
>  honestly going back to only a install DVD with a sane user-UI and 
>  dedicate all the time wasted for the spin/products/discrimination 
>  discussions for documentations, screenshots and howtos would have more 
>  benefit for Fedora there is nothing you can't setup with the "one fits 
>  all" DVD or even with a slim network install if you only knew what to 
>  install and how to configure 
Right! since spins are just a fancy way to install groups, I would like 
the main install to offer them in a distinct 'I want to customize' 
installation step of the One True Fedora. That assumes that one can 
actually mix and match groups, even if they affect the fundamental 
layers such as the desktop environment. I haven't tried a combined 
Gnome/KDE installation recently, but I remember that it just offered an 
option to start a login session in either desktop environment.

An example of rampant customization is SUSE studio 
(http://susestudio.com/browse), and I am not at all impressed by it.  I 
am sure that there are some gems there but the pile of options is just 
overwhelming, and I think a better approach would be to have a solid 
base system with multiple customization recipes.

This would require careful definition of QA release requirements, to 
avoid combinatorial explosion in testing---but the current approach of 
testing the two basic desktop environments is fine and would still work.

[Adam Williamson]

On Tue, 2014-02-04 at 11:27 -0500, Przemek Klosowski wrote:
>  On 02/04/2014 06:15 AM, Reindl Harald wrote:
>  
>  > honestly going back to only a install DVD with a sane user-UI and
>  > dedicate all the time wasted for the spin/products/discrimination
>  > discussions for documentations, screenshots and howtos would have
>  > more benefit for Fedora there is nothing you can't setup with the
>  > "one fits all" DVD or even with a slim network install if you only
>  > knew what to install and how to configure 
>  
>  Right! since spins are just a fancy way to install groups, I would
>  like the main install to offer them in a distinct 'I want to
>  customize' installation step of the One True Fedora. That assumes that
>  one can actually mix and match groups, even if they affect the
>  fundamental layers such as the desktop environment. I haven't tried a
>  combined Gnome/KDE installation recently, but I remember that it just
>  offered an option to start a login session in either desktop
>  environment. 
You can in fact do this at present, though it isn't heavily advertised
and I suspect was quietly snuck in by someone on the 'it's easier to
apologize than ask permission' principle ;)

If you choose the 'Basic Desktop' group on the left-hand side of
Software Selection, you'll see the 'subsidiary' group set on the
right-hand side includes all the major desktops, and you can pick as
many of them as you like. I think you don't get quite the same set of
package groups for each environment as you would if you picked its
dedicated environment group on the left hand side, but you should get
something that works at least.

This isn't particularly "supported", by which I mean: we don't promote
or document it, QA doesn't do planned testing of it, and we wouldn't
block a release on it being broken. But AFAIK it usually works OK.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

On Tue, Feb 04, 2014 at 10:57:51AM +0000, "Jóhann B. Guðmundsson" wrote:
>  >For that matter, there could be a "Fedora GNOME" spin
> distinct from the
>  >Fedora Workstation product, if there were people really keen to work on it,
>  >perhap as a showcase of upstream technology without worrying about the
>  >concerns of the Fedora Workstation WG's particular area of focus. (With
>  >"people keen to work on it" as the really key phrase.)
>  But you cannot overlap products as in you cannot have a "Gnome
>  workstation and "KDE workstation" etc you cannot have an "Server"
>  product outside what is already defined in the ServerWG nor a
>  "Cloud" product outside what is already defined there. 
I think it's okay for there to be some overlap. The real world doesn't
always chop up into neat boxes. If there's a *lot* of overlap between two
nominally-different products, then that is less useful and it's probably
better for them to either work together or else find a stronger
differentiation.

But that's talking about products. As long as someone is interested in doing
them, spins can overlap like crazy.



-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Jóhann B. Guðmundsson]

On 02/04/2014 12:38 PM, Matthew Miller wrote:
>  On Tue, Feb 04, 2014 at 10:57:51AM +0000, "Jóhann B.
> Guðmundsson" wrote:
> >> For that matter, there could be a "Fedora GNOME" spin distinct from
> the
> >> Fedora Workstation product, if there were people really keen to work on it,
> >> perhap as a showcase of upstream technology without worrying about the
> >> concerns of the Fedora Workstation WG's particular area of focus. (With
> >> "people keen to work on it" as the really key phrase.)
> > But you cannot overlap products as in you cannot have a "Gnome
> > workstation and "KDE workstation" etc you cannot have an
> "Server"
> > product outside what is already defined in the ServerWG nor a
> > "Cloud" product outside what is already defined there.
>  I think it's okay for there to be some overlap. The real world doesn't
>  always chop up into neat boxes. If there's a *lot* of overlap between two
>  nominally-different products, then that is less useful and it's probably
>  better for them to either work together or else find a stronger
>  differentiation.
>
>  But that's talking about products. As long as someone is interested in doing
>  them, spins can overlap like crazy. 
Yes but community products wont be considered "primary" products which 
means if things continues in the same manner as "default" does be 
ignored by QA/Releng/Marketing/Design since the focus will *only* be on 
"primary" products.

JBG

[Matthew Miller]

On Tue, Feb 04, 2014 at 12:56:04PM +0000, "Jóhann B. Guðmundsson" wrote:
>  Yes but community products wont be considered "primary"
> products 
No. The initial plan calls for three primary *community* products. And we'll
see where it goes from there.

>  which means if things continues in the same manner as
> "default" does
>  be ignored by QA/Releng/Marketing/Design since the focus will *only*
>  be on "primary" products. 
"Focus", yes. "Only", no. All of those groups help with existing spins
to
some degree now, and I don't see any particular change there.

As I understand what you've said in earlier messages, I think you're
strongly in the camp that thinks Fedora is best as a big bag of building
blocks which we hand to users. Other people think that it would be best if
we glued the blocks together into predesigned shapes. I think we can do the
middle route, where we offer some pre-built structures but also keep the
blocks available. Or to switch metaphors to the way Colin Walters put it in
a message I read a few minutes ago , we *can* walk and chew gum at the same
time.

-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[Dan Mashal]

On Thu, Jan 30, 2014 at 11:53 AM, Bill Nottingham <notting(a)redhat.com&gt; wrote:
>  Blame me, I filed the original ticket. My concern was that we're
> (obviously)
>  doing work in the Fedora.next space around:
>
>  1) the three products (workstation, server, cloud)
>  2) the base, which lives under them in some manner
>  3) environments & stacks, which can live on top of them 
If what you mean is a spin is a "stack" that lives on top of the
"base" that would be fine.

Dan

[Ralf Corsepius]

On 01/30/2014 05:06 PM, Rahul Sundaram wrote:
>  Hi
>
>
>  On Thu, Jan 30, 2014 at 11:01 AM, Stephen Gallagher wrote:
>
>
>      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.
>
>
>  Part of the problem I have with this discussion other than the alarmist
>  subject is that we are discussing the "fate of spins" before even coming
>  out with concrete products out of the fedora.next proposals.  That seems
>  premature. 
+1

Until now, I am still unable to grasp the sense of "Fedora.NEXT".
All in all, to me all I've read so far sounds like being a lot of effort 
with undefined, unclear or questionable outcome.

Ralf

[Kevin Kofler]

Ralf Corsepius wrote:
>  Until now, I am still unable to grasp the sense of
> "Fedora.NEXT".
>  All in all, to me all I've read so far sounds like being a lot of effort
>  with undefined, unclear or questionable outcome. 
Indeed.

I don't understand why we are doing that "Fedora.NEXT" thing in the first 
place. It's a lot of change for the sake of change, without any idea whether 
the output will be better than the status quo, or even whether there will be 
any (usable) output at all!

        Kevin Kofler

[Solomon Peachy]

On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
>  I don't understand why we are doing that "Fedora.NEXT"
> thing in the 
>  first place. It's a lot of change for the sake of change, without any 
>  idea whether the output will be better than the status quo, or even 
>  whether there will be any (usable) output at all! 
For what my opinion is worth (as someone who's been around since the 
RHL4.1 days) I have to agree.  I've paid close attention to this ongoing 
saga, ad while the old development and governence model had its warts, 
it did seem to work consistently for Fedora's stated foundational 
goals (Freedom, Friends, Features, First)

So far the only tangible result is that the release date for F21 is 
delayed (which is probably a good thing) Everything else seems to be 
"It's Fedora, just totally different and not Fedora any more." 

The main "feature" I've seen requested is an intermediate-cadence 
support cycle between RHEL/clones' 5-year and Fedora's 1ish-year, but 
nobody (especially not those asking for it) seems willing/able to do the 
work to provide that support on the (nontrivial!) distro-level scale.  
(I remember all too well the Fedora Legacy folks' pleading for help..)

A longer release cadence means we lose the 'First' goal (both in the 
First-to-market and Upstream-First sense), and the main beneficiary 
seems to be those who think the 'Freedom' goal only applies to 
themselves, not their downstream users.

Anyway.  I'll shut back up, but I would really hate to see Fedora's 
unique (and IMO successful) model get thrown out.  It really is a matter 
of principles.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.

[Chris Murphy]

On Feb 2, 2014, at 6:33 AM, Solomon Peachy <pizza(a)shaftnet.org&gt; wrote:

>  On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
> > I don't understand why we are doing that "Fedora.NEXT" thing in the 
> > first place. It's a lot of change for the sake of change, without any 
> > idea whether the output will be better than the status quo, or even 
> > whether there will be any (usable) output at all!
>  
>  For what my opinion is worth (as someone who's been around since the 
>  RHL4.1 days) I have to agree.  

I think this is a good summary of what it's all about and what it isn't.

https://www.happyassassin.net/2014/01/31/good-morning-bugfixing-and-think...



Chris Murphy

[Solomon Peachy]

On Sun, Feb 02, 2014 at 11:26:06AM -0700, Chris Murphy wrote:
>  > For what my opinion is worth (as someone who's been around
> since the 
>  > RHL4.1 days) I have to agree. 
>  
>  I think this is a good summary of what it's all about and what it isn't.
>  
>
> https://www.happyassassin.net/2014/01/31/good-morning-bugfixing-and-think...
Hmm.  That's an interesting read, and for what it's worth I like the 
position he advocates. It could be a great improvement over the current 
'yum groupinstall' situation, depending on how some of the details are 
worked out.

But looking at it from a 3rd party software perspective (F/OSS or 
otherwise) it's barely an incremental improvement over the current 
status quo -- While a third party will be able to rely on a minimal 
package set being present (thereby eliminating a step in their 
installer), they will still have to specifically target individual 
Fedora [Product] releases and keep up with Fedora's release cadence as 
well.  (In other words, it's a negligable improvement without some 
significant changes to Fedora's release and support models)

Anyway, time to resume hacking on Gutenprint.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.

[Ralf Corsepius]

On 02/02/2014 07:26 PM, Chris Murphy wrote:
>  On Feb 2, 2014, at 6:33 AM, Solomon Peachy <pizza(a)shaftnet.org&gt; wrote:
>
> > On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
> >> I don't understand why we are doing that "Fedora.NEXT" thing in
> the
> >> first place. It's a lot of change for the sake of change, without any
> >> idea whether the output will be better than the status quo, or even
> >> whether there will be any (usable) output at all!
> >
> > For what my opinion is worth (as someone who's been around since the
> > RHL4.1 days) I have to agree.
>
>
>  I think this is a good summary of what it's all about and what it isn't.
Would you mind do summarize how you understand this in your own words?

To me this all reads as "Fedora.Next" is a marketing term for a 
predefined set of packages aiming at certain arbitrary predefined 
use-cases.

I regret, but I fail to find much sense in this.

Ralf

[Chris Murphy]

On Feb 2, 2014, at 2:54 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:

>  On 02/02/2014 07:26 PM, Chris Murphy wrote:
> > 
> > On Feb 2, 2014, at 6:33 AM, Solomon Peachy <pizza(a)shaftnet.org&gt; wrote:
> > 
> >> On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
> >>> I don't understand why we are doing that "Fedora.NEXT" thing in
> the
> >>> first place. It's a lot of change for the sake of change, without any
> >>> idea whether the output will be better than the status quo, or even
> >>> whether there will be any (usable) output at all!
> >> 
> >> For what my opinion is worth (as someone who's been around since the
> >> RHL4.1 days) I have to agree.
> > 
> > 
> > I think this is a good summary of what it's all about and what it isn't.
>  Would you mind do summarize how you understand this in your own words? 
>  To me this all reads as "Fedora.Next" is a marketing term
> for a predefined set of packages aiming at certain arbitrary predefined use-cases. 
First, subjective and arbitrary are not the same thing, and considering Fedora.next being
purely random and whimsical is hyperbole.

Therefore my understanding is different. What's been called "hand waviness"
is the unavoidable subjective state of any new process. The flushing out and refinement of
subjective goals into objective ones is what the Working Groups are doing. I also
understand that while a high percentage of objectivity is desired and intended, even by
Fedora 21 the process will still be maturing.

I can only imagine focus, instead of haphazard and the potential for truly arbitrary
outcomes, occurs without any consideration of use cases. So I see pre-defined use cases as
completely reasonable. Are they subjective? Sure. But we're not building a linux
distribution for camels, so lets not pretend that we have unlimited resources, that Fedora
is a chameleon and it can be all things to everyone simultaneously and still be high
enough quality and relevance that people want to, you know, use it and get things done.


Chris Murphy

[Kevin Kofler]

Chris Murphy wrote:
>  I think this is a good summary of what it's all about and what it
> isn't.
>  
>
> https://www.happyassassin.net/2014/01/31/good-morning-bugfixing-and-think...
Yikes, one more step away from flexibility and towards a proprietary "one
size fits it all" experience!? :-(

You're a developer and you want your users to have a certain set of packages
installed? Then you Require those packages! That's what RPMs are for! (And
yes, this implies that you're supposed to actually PACKAGE your software. Or
at least to let other people package it. People at certain third-party
repositories are willing to package stuff even from binary tarballs, if only
your license lets them! Heck, they even came up with hackish workarounds
such as LPF for when the license DOESN'T let them, but they really shouldn't
have to! But the right approach will always be to get your software INTO
Fedora, with source code and under Fedora-compatible licensing terms.)

        Kevin Kofler

[Kevin Kofler]

Solomon Peachy wrote:
>  So far the only tangible result is that the release date for F21 is
>  delayed (which is probably a good thing) 
It's not. As you say yourself:
>  A longer release cadence means we lose the 'First' goal (both
> in the
>  First-to-market and Upstream-First sense), and the main beneficiary
>  seems to be those who think the 'Freedom' goal only applies to
>  themselves, not their downstream users. 
so we shouldn't delay our releases for
no good reason.

>  The main "feature" I've seen requested is an
> intermediate-cadence
>  support cycle between RHEL/clones' 5-year and Fedora's 1ish-year, but
>  nobody (especially not those asking for it) seems willing/able to do the
>  work to provide that support on the (nontrivial!) distro-level scale. 
Longer support must not happen at the expense of release frequency.

>  (I remember all too well the Fedora Legacy folks' pleading for
> help..) 
The reason Fedora Legacy failed was its unrealistic QA requirements on 
package updates, a disease that has since spread to Fedora as a whole. We 
could support our releases for much longer (WITHOUT reducing their 
frequency) if we just let maintainers push the security fixes without any 
bureaucracy. Right now, we even have trouble getting karma for the Fedora 
n-1 release that is still supported.

        Kevin Kofler

[Kevin Kofler]

Stephen Gallagher wrote:
>  Right now, the vision essentially looks like:
>  
>  Fedora Products: This *is* Fedora. It comes in three flavors. 
I don't like the hardcoded "three" there at all, because if KDE is to ever 
become a full-fledged Product (which IMHO it should have been from the 
beginning!), it will need to change (unless you're dropping one of your 3 
sacred spins).

        Kevin Kofler

[Stephen Gallagher]

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

On 02/01/2014 11:07 PM, Kevin Kofler wrote:
>  Stephen Gallagher wrote:
> > Right now, the vision essentially looks like:
> > 
> > Fedora Products: This *is* Fedora. It comes in three flavors.
>  
>  I don't like the hardcoded "three" there at all, because if KDE is
>  to ever become a full-fledged Product (which IMHO it should have
>  been from the beginning!), it will need to change (unless you're
>  dropping one of your 3 sacred spins).
>   
Well, I thought it was clear, since I did include the words "Right
now", but yes: I do think that other products should be both permitted
and planned. One thing I've been discussing as an option with some of
the members of the KDE SIG is to promote Fedora Scientific, based on
the present-day KDE and Scientific Spins, as a fourth Fedora Product.

I think this would be valuable as it would also act as a prototype for
what the new-product process will need to be going forward.

To address another concern you had elsewhere:
One of the stated goals of the Products is to provide a known and
reliable setup. I don't view it as reducing Freedom (or Choice)
because a clear goal of this effort is to ensure that if you don't
want this setup, you don't have to use it. You will be able to either
install one of the the Products (and later remove packages you don't
want) or you can install individual packages directly from the
netinstall.iso just as you have always done. So I really view this as
an add-on: if the *choice* a user wants to make is "I'd like someone
who knows more than I do to make the decision about what I should have
installed", that's just as valid a choice as "I want to use DNF
instead of YUM". It's just taking place at a higher level.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLwsTIACgkQeiVVYja6o6PjhgCgneEHSY6BHKprKxdul+Naw/FN
> Z2gAoJf2kF1QEq8ixaEs4LvJLn6MROOR
> =ai3m
> -----END PGP SIGNATURE-----

[Howard Howell]

On Tue, 2014-02-04 at 10:21 +0100, Stephen Gallagher wrote:
>  On 02/01/2014 11:07 PM, Kevin Kofler wrote:
>  > Stephen Gallagher wrote:
>  >> Right now, the vision essentially looks like:
>  >> 
>  >> Fedora Products: This *is* Fedora. It comes in three flavors.
>  > 
>  > I don't like the hardcoded "three" there at all, because if KDE is
>  > to ever become a full-fledged Product (which IMHO it should have
>  > been from the beginning!), it will need to change (unless you're
>  > dropping one of your 3 sacred spins).
>  > 
>  
>  Well, I thought it was clear, since I did include the words "Right
>  now", but yes: I do think that other products should be both permitted
>  and planned. One thing I've been discussing as an option with some of
>  the members of the KDE SIG is to promote Fedora Scientific, based on
>  the present-day KDE and Scientific Spins, as a fourth Fedora Product.
>  
>  I think this would be valuable as it would also act as a prototype for
>  what the new-product process will need to be going forward.
>  
>  To address another concern you had elsewhere:
>  One of the stated goals of the Products is to provide a known and
>  reliable setup. I don't view it as reducing Freedom (or Choice)
>  because a clear goal of this effort is to ensure that if you don't
>  want this setup, you don't have to use it. You will be able to either
>  install one of the the Products (and later remove packages you don't
>  want) or you can install individual packages directly from the
>  netinstall.iso just as you have always done. So I really view this as
>  an add-on: if the *choice* a user wants to make is "I'd like someone
>  who knows more than I do to make the decision about what I should have
>  installed", that's just as valid a choice as "I want to use DNF
>  instead of YUM". It's just taking place at a higher level. 
Very well said
and I agree.  It takes a long time with some packages to
ensure that you have all the dependencies, supporting software (such as
Gschem, gnetlist, and ngspice, along with models, footprints, and
symbols) and useful utilities, such as snapshot, and Gerber viewers.
Moreover, while a user often knows what needs to be done, figuring out
which utilities work well with the application is something a new user
would not be equipped to handle.

Regards,
Les H

[Adam Williamson]

On Tue, 2014-02-04 at 10:21 +0100, Stephen Gallagher wrote:
>  On 02/01/2014 11:07 PM, Kevin Kofler wrote:
>  > Stephen Gallagher wrote:
>  >> Right now, the vision essentially looks like:
>  >> 
>  >> Fedora Products: This *is* Fedora. It comes in three flavors.
>  > 
>  > I don't like the hardcoded "three" there at all, because if KDE is
>  > to ever become a full-fledged Product (which IMHO it should have
>  > been from the beginning!), it will need to change (unless you're
>  > dropping one of your 3 sacred spins).
>  > 
>  
>  Well, I thought it was clear, since I did include the words "Right
>  now", but yes: I do think that other products should be both permitted
>  and planned. One thing I've been discussing as an option with some of
>  the members of the KDE SIG is to promote Fedora Scientific, based on
>  the present-day KDE and Scientific Spins, as a fourth Fedora Product.
>  
>  I think this would be valuable as it would also act as a prototype for
>  what the new-product process will need to be going forward. 
This still seems kind of bizarre to me. Scientific Workstation is a very
niche spin for a particular audience which happens to use the KDE
desktop because, I dunno, the person who built the spin had to pick
*some* desktop and they liked KDE more than GNOME or something. KDE is
our most significant desktop spin after GNOME.

If we're expanding the product set, Fedora KDE seems like a reasonable
Product candidate, but smooshing it together with Scientific Workstation
seems a bit bizarre.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Stephen Gallagher]

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

On 02/04/2014 10:37 PM, Adam Williamson wrote:
>  On Tue, 2014-02-04 at 10:21 +0100, Stephen Gallagher wrote:
> > On 02/01/2014 11:07 PM, Kevin Kofler wrote:
> >> Stephen Gallagher wrote:
> >>> Right now, the vision essentially looks like:
> >>> 
> >>> Fedora Products: This *is* Fedora. It comes in three
> >>> flavors.
> >> 
> >> I don't like the hardcoded "three" there at all, because if KDE
> >> is to ever become a full-fledged Product (which IMHO it should
> >> have been from the beginning!), it will need to change (unless
> >> you're dropping one of your 3 sacred spins).
> >> 
> > 
> > Well, I thought it was clear, since I did include the words
> > "Right now", but yes: I do think that other products should be
> > both permitted and planned. One thing I've been discussing as an
> > option with some of the members of the KDE SIG is to promote
> > Fedora Scientific, based on the present-day KDE and Scientific
> > Spins, as a fourth Fedora Product.
> > 
> > I think this would be valuable as it would also act as a
> > prototype for what the new-product process will need to be going
> > forward.
>  
>  This still seems kind of bizarre to me. Scientific Workstation is a
>  very niche spin for a particular audience which happens to use the
>  KDE desktop because, I dunno, the person who built the spin had to
>  pick *some* desktop and they liked KDE more than GNOME or
>  something. KDE is our most significant desktop spin after GNOME.
>  
>  If we're expanding the product set, Fedora KDE seems like a
>  reasonable Product candidate, but smooshing it together with
>  Scientific Workstation seems a bit bizarre.
>   
It's not just that, actually. It has to do with the fact that the
majority of the scientific-focused applications are built atop the QT4
and other KDE libraries, making it much better suited to operating
atop the KDE desktop environment. Certainly it *can* be run in GNOME
at the cost of additional memory usage and other resources.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLx94cACgkQeiVVYja6o6NGNQCeKT3nPbjJ04q8htyShHqymZ5h
> Ue4AnRgzkAplJWv6KcZRAtqfA3tWHrWk
> =egPd
> -----END PGP SIGNATURE-----

[Przemek Klosowski]

On 02/05/2014 03:34 AM, Stephen Gallagher wrote:
>  It's not just that, actually. It has to do with the fact that
> the
>  majority of the scientific-focused applications are built atop the QT4
>  and other KDE libraries, making it much better suited to operating
>  atop the KDE desktop environment. Certainly it *can* be run in GNOME
>  at the cost of additional memory usage and other resources 
This doesn't sound
right.

yum group info 'Engineering and Scientific'

lists 148 applications, of which 14 require Qt (*). The method I used is 
pretty ad-hoc so perhaps I am missing something, but it seems to me that 
KDE is not really correlated to the 'scientificness'. This reflects my 
personal experience---I have been using Fedora for scientific computing 
for a long time, always under Gnome and I never felt the need to switch 
to KDE. Adam is probably right that KDE might just be a personal 
preference of the spin authors.

This actually illustrates a problem I have with spins: if you treat them 
too much like separate products, they detract from modularity that is 
really the strength of Linux and Fedora. It should work just fine to 
combine Scientific and Security, for instance if someone wanted to do a 
statistical analysis on WiFi security survey scans :). If you look at 
spins as a PR/marketing effort around groupinstall, the modularity is 
easily available. If you look at spins as a customized remixes creating 
a specialized environment, not so much.

Greetings

przemek




(*) as determined by

for a in `yum group info 'Engineering and Scientific'` ; do if repoquery 
--requires $a | grep -iq qt; then echo $a; fi  ; done

[Adam Williamson]

On Wed, 2014-01-29 at 15:30 -0500, 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? 
So in my new constructive spirit ;) let me take a crack at some answers
to this:

I think the Spins process as it currently exists has a lot of problems.
We've been saying this for years, long before we even thought about
Fedora.next. You identify some of them above, and there are others -
we've never had coherent messaging about the spins, for instance. This
is especially silly with the desktop spins, where there are all kinds of
mixed messages.

* Desktop is a spin, but it's also our default deliverable.
* KDE is a spin, and considered a release-blocking deliverable.
* Xfce, LXDE, MATE and SoaS are spins, aren't considered
release-blocking deliverables, but they *are* shipped in the same
directory as the Desktop and KDE spins on the mirrors (since F20), and
they're broken out and given special status on the download page as
"Desktops" - https://fedoraproject.org/get-fedora#desktops .
* Security Lab, Design Suite, Scientific-KDE and Electronics Lab aren't
shipped in the same directory as Desktop, KDE, LXDE, MATE and SoaS (the
directory they're in isn't carried by all mirrors, I don't think), and
they're not "Desktops", but they're shown on a Spins tab on the
download
page.
* All the other spins are spins, but they're not the default
deliverable, they don't block the release, they're shipped in the same
directory as Security Lab etc, but they're not shown directly on the
download page at all.
* https://spins.fedoraproject.org/ shows all the spins *except Desktop*
in a co-equal way.

There's an ad-hoc method to all this madness - there's a sort of ranking
system going on there that is intentional - but it's all been rather
thrown together as we've gone along and tweaked from release to release
with no great overarching plan.

So it's a good idea to look at the Spins space and see if there are
opportunities for improvement, almost regardless of the Products plan,
in fact (though obviously it is relevant to some questions here).

Despite the problems with the process, though, I think some of our
actual Spins manage to be excellent small-p products that provide good
solid value to the Fedora project and we should find a way to keep them
within the Fedora space even in a Product-ified world.

The desktop spins are the ones that seem most important to keep. I think
there's a reasonable argument for dropping most or all of the
non-desktop spins, because they're essentially just vehicles for
delivering package groups, when you look at them. Games provides a bunch
of games. Electronics Lab provides a bunch of electronics tools. There's
nothing particularly compelling about shipping these particular bundles
of packages as live images, or as images at all; we can come up with any
number of other mechanisms for letting people get at them, very
trivially. Hell, it's not particularly difficult to do it right now.

The desktop spins, though, do have a reasonable amount of value to users
of those desktops. People do use live media *just as live media*, and we
know there are Fedora users who want to use desktops other than our
default desktop, and Fedora contributors willing to do the work of
maintaining and testing live image deliverables for those desktops. The
desktop spins we have have mostly managed to meet reasonable quality
expectations in recent releases without imposing a burden on the QA
team. I just don't see any major problems to solve in the area of the
existing desktop spins *as small-p products that are a part of the
Fedora project*, though I certainly respect the releng team's statement
that their work scales more or less linearly with the number of
deliverables we decide to make a part of the Fedora space.

Even if we want to keep the alternative desktop live images as a part of
the Fedora space, though, that affords us quite a bit of flexibility to
change other things about this process.

As I said, I personally would be fine with us dropping the non-desktop
spins with just a bit of effort to make sure those package groups are
nice and easy to access from whatever generic installation media we wind
up continuing to ship (I'm assuming for now we'll at least still have
netinst.iso) and from the software deployments tools associated with
each Product.

The .next effort certainly gives us an opportunity to fix all the mixed
messaging. We could, for instance, give up on the initial idea of spins
as this big open space for all kinds of small-p products to be built,
drop spins.fp.o entirely (and save whatever work that saves), and just
have a particular set of alternative desktop live images as Fedora
release deliverables, maybe drop the whole Spins name. I'd certainly
find it reasonable to generally message them as being a 'second tier'
set after the big-p Product deliverables: the download page would
heavily push the Product deliverables, as it currently mainly pushes the
desktop live image, and have all the alternative-desktop deliverables
shown less prominently.

tl;dr summary: I do think it's important to keep the alternative-desktop
live image deliverables within the Fedora tent, but there are lots of
ways we can look at doing that that are different from the way we
currently do it. The non-desktop spins, I think there's a strong
argument for losing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Fenzi]

On Fri, 31 Jan 2014 14:37:02 -0800
Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  So in my new constructive spirit ;) let me take a crack at some
>  answers to this:
>  
>  I think the Spins process as it currently exists has a lot of
>  problems. We've been saying this for years, long before we even
>  thought about Fedora.next. You identify some of them above, and there
>  are others - we've never had coherent messaging about the spins, for
>  instance. This is especially silly with the desktop spins, where
>  there are all kinds of mixed messages. 
Yeah. I think things got somewhat better in f20 at least due to the
requirement that someone/anyone actually booted the thing and it
worked. 

...snip...

>  The desktop spins are the ones that seem most important to keep. I
>  think there's a reasonable argument for dropping most or all of the
>  non-desktop spins, because they're essentially just vehicles for
>  delivering package groups, when you look at them. Games provides a
>  bunch of games. Electronics Lab provides a bunch of electronics
>  tools. There's nothing particularly compelling about shipping these
>  particular bundles of packages as live images, or as images at all;
>  we can come up with any number of other mechanisms for letting people
>  get at them, very trivially. Hell, it's not particularly difficult to
>  do it right now. 
I went down this same path a few years ago, but there are actually use
cases for the non desktop spins that aren't served by just installing
and then installing the packages. For example: 

* Using the security spin booted live to examine a compromised install.
  You don't want to attach it to a real install thats r/w. Booting off
  a read only media means if something messes it up, you can just
  reboot. 

* You have 30 machines in a lab you can use for your electronics lab or
  design class or gamer gathering. You're allowed to reboot them, but
  not install anything on them (they have windows on them or something).
  You can just walk around before class and boot them all up on live
  dvd/cd's. If someone messes up their setup in the class, they just
  reboot and get back to the desktop. 

Now perhaps these are cases where we just say: hey, make your own for
this, but they are valid use cases not easily handled by dropping those
spins. 

>  The desktop spins, though, do have a reasonable amount of value to
>  users of those desktops. People do use live media *just as live
>  media*, and we know there are Fedora users who want to use desktops
>  other than our default desktop, and Fedora contributors willing to do
>  the work of maintaining and testing live image deliverables for those
>  desktops. The desktop spins we have have mostly managed to meet
>  reasonable quality expectations in recent releases without imposing a
>  burden on the QA team. I just don't see any major problems to solve
>  in the area of the existing desktop spins *as small-p products that
>  are a part of the Fedora project*, though I certainly respect the
>  releng team's statement that their work scales more or less linearly
>  with the number of deliverables we decide to make a part of the
>  Fedora space. 
I'm not going to speak for releng, but IMHO... the items that are
somewhat a burden still with spins are: 

* Making sure someone tests and signs off at milestones. 
  (Perhaps this could be somehow automated?)
* The volume of things makes composes take longer. 
  (perhaps we could stop doing them as part of tc/rc composes, and just
  do them after each of those so they don't gate those?)
* websites folks have to look at what was signed off and adjust the
  websites for them.
  (Perhaps we could make some kind of more self service site for spins?)

>  Even if we want to keep the alternative desktop live images as a
> part
>  of the Fedora space, though, that affords us quite a bit of
>  flexibility to change other things about this process. 
Agreed. 

kevin

[Adam Williamson]

On Fri, 2014-01-31 at 16:22 -0700, Kevin Fenzi wrote:

>  > The desktop spins are the ones that seem most important to keep.
> I
>  > think there's a reasonable argument for dropping most or all of the
>  > non-desktop spins, because they're essentially just vehicles for
>  > delivering package groups, when you look at them. Games provides a
>  > bunch of games. Electronics Lab provides a bunch of electronics
>  > tools. There's nothing particularly compelling about shipping these
>  > particular bundles of packages as live images, or as images at all;
>  > we can come up with any number of other mechanisms for letting people
>  > get at them, very trivially. Hell, it's not particularly difficult to
>  > do it right now.
>  
>  I went down this same path a few years ago, but there are actually use
>  cases for the non desktop spins that aren't served by just installing
>  and then installing the packages. For example: 
>  
>  * Using the security spin booted live to examine a compromised install.
>    You don't want to attach it to a real install thats r/w. Booting off
>    a read only media means if something messes it up, you can just
>    reboot. 
>  
>  * You have 30 machines in a lab you can use for your electronics lab or
>    design class or gamer gathering. You're allowed to reboot them, but
>    not install anything on them (they have windows on them or something).
>    You can just walk around before class and boot them all up on live
>    dvd/cd's. If someone messes up their setup in the class, they just
>    reboot and get back to the desktop. 
>  
>  Now perhaps these are cases where we just say: hey, make your own for
>  this, but they are valid use cases not easily handled by dropping those
>  spins.  
Thanks for the examples - I think you've given them before, and I've
forgotten them.

Yup: they're valid use cases, and they strengthen the argument for those
spins *as* spins. But indeed you can still make the case that there just
isn't enough value in doing it as part of Fedora, and viewed in the
context of these fairly 'niche' uses, the argument about making them
into remixes or something seems less alarming. I'm not sure I'd be
onboard with hiving off KDE, Xfce and Sugar as non-Fedora stuff (or
requiring them to become fully-fledged Products), but I can certainly
see saying 'look, if you want to take Fedora and build a security
forensics live image on top of it, that's awesome, but call it something
else and maintain it yourself' - I'm rather more on-board with that
argument *as applied to these somewhat niche cases* than just applied
to, you know, everything we currently cover with Spins. I'm not sure I
have a definite opinion on whether we need to / should do that or not,
but I know I wouldn't be incredibly sad/angry if it happened.

I do think there's some mileage in the argument that, if you go all the
back to the original Spins conception as this wide-open field to create
ANY PRODUCT YOU LIKE from Fedora bits and it'd be part of the Fedora
project in *some* form, that's probably biting off more than we can
realistically chew, especially given what releng has said about
resources. Right now we're kinda between two stools on that: Spins
didn't take off like wildfire and produce hundreds of awesome things
like maybe it was originally expected to, but it wasn't a complete and
utter dead loss either - so now we're in, I guess, a slightly weird
situation where we have this very heavyweight conception of Spins which
is maybe not providing us enough value to justify its weight.

If you want to take a "market" view of it, you can make the argument
that SUSE Studio is rather eating our lunch on the original Spins
concept:

http://susestudio.com/browse

zoiks. Kind of beats our 'well, first figure out the way livecd-creator
is duct taped together, then submit a kickstart file to this SIG thing
that barely exists any more, then...' process into a cocked hat.

<snip last section - I think all your ideas there were sound>
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Kofler]

Stephen Gallagher wrote:
>  1) Are Spins useful as they currently exist? 
Yes. Just see how many people do, indeed, use them.

>  2) Should Spins be eliminated entirely in favor of Fedora Remixes[1].
No! HELL NO! Reducing Fedora to those 3 uninteresting "Products" would be a 
huge step backwards.

>  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? 
Maybe. It all depends on what the expectations are for something to become a 
Product. IMHO, it should have no more expectations than we currently have 
for Spins (i.e. ALL Spins should automatically become Products), in which 
case the question becomes moot entirely. But seeing the kind of bureaucratic 
processes some people are expecting Products to go through, as long as those 
expectations remain, I think the answer to your question 3 can only be: No!

>  3b) If we treat Spins as Products-in-development, what do we do with
>  those Spins that don't fit that criteria? 
See above, there shouldn't be any. Otherwise, the answer to the previous 
question must be "no". In both cases, this question becomes moot.

        Kevin Kofler