Fedora.NEXT Products and the fate of Spins

Kevin Fenzi kevin at scrye.com
Fri Jan 31 23:22:17 UTC 2014


On Fri, 31 Jan 2014 14:37:02 -0800
Adam Williamson <awilliam at redhat.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140131/f630904a/attachment.sig>


More information about the devel mailing list