Request: please consider clarifying the project's position on Spins

Toshio Kuratomi a.badger at gmail.com
Tue Dec 7 01:49:55 UTC 2010


On Mon, Dec 06, 2010 at 11:00:44AM +0100, Jaroslav Reznik wrote:
> On Monday, December 06, 2010 02:52:17 am Adam Williamson wrote:
> > 
> > 1) the point that we currently ship spins with no idea whether they work
> > or not, and do in fact sometimes (often?) ship completely broken spins,
> > is an important one. There's actually an argument that this is OK, and
> > that should be considered, though it's counter-intuitive. But it's
> > important to realize that this is entirely a part of the present system
> > and if we don't want that to happen we do need to change the system.
> > Right now, we would never ship a broken Desktop spin, we would almost
> > certainly never ship a broken KDE spin, and it's quite unlikely, since
> > F14, that we would ship a broken LXDE or Xfce spin. Beyond that, all
> > bets are off. There is currently no official testing coverage for the
> > spins beyond those four (I'm trying to cover Sugar, but we didn't quite
> > manage it for F14). As a project, we have no real clue whether they work
> > at all when we ship and to some degree publicise them. The current
> > policy, as Jesse described it, is that we build them, we publish them,
> > and if we find out they're broken, we pull them. That's it.
> > 
> > There's various ways we can handle this:
> > 
> > a) declare it not a problem, as is the current policy
> > b) require QA to do some minimal 'does it work?' testing of all spins,
> > and don't publish ones that are totally broken
> > c) require the SIG (or whatever) that owns each spin to do the basic
> > testing and sign off on the spin before release: if they don't sign off
> > on the spin, it's not published. QA and releng can help facilitate this
> > process if required (just by providing test builds and pointers for
> > testing).
> 
> Some combination of b) and c) should work - be as higher level QA - if someone 
> is using Fedora brand - we have to be sure it's using Fedora brand in that way 
> we can be proud of it ;-) But not in the way how Firefox enforces this rule :) 
> c) needs again some coordination - someone has to poke folks with built image 
> etc. (it was a problem before Validation tests - it was somehow releases and 
> everyone was prying it works). 
> 
Another variable to throw in here -- We make smoketesting something that
belongs to the SIGs to do -- and we don't ship a spin unless it passes
a smoketest but we allow spins to go out at a different time as the rest of
the release.  That idea looks something like this:

Nearing release candidate, we start making images.  Fedora Foo Spin image is
created.

Foo Spin SIG doesn't test yet.

Fedora final is released to the mirrors.  Fedora GNOME, Fedora KDE, Fedora
LXDE, etc go to the mirrors.

Foo Spin SIG tests their images and certifies that they pass the smoketests.

Upload the Foo Spin image to the download servers.

Of course this leaves open what to do if the image doesn't pass its
smoketests.  My take on that would be:

If the SIGs aren't contributing manpower to build images, then rel-eng can
decide to respin with a small selection of updated packages or not at their
discretion.

If the SIGs are contributing manpower to build images, then they can decide
whether to respin with a small selection of updated packages or not at their
discretion.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20101206/347f2d1f/attachment.bin 


More information about the advisory-board mailing list