Dealing with critical bugs in final releases

[Adam Williamson]

On 22/04/13 09:09 AM, Michael Spahn wrote:
> Thank your for your detailed feedback.
>
> Is there any special group with a focus on testing anaconda?

That would be us. Testing anaconda is probably 50% of what we do.

> I think that just happened due to a lack of physical hardware to test
> Fedora 18. :-/

We do an awful lot of testing on an awful lot of physical hardware. But 
it's impossible to either test a release on all possible hardware, or to 
adopt as a policy that we don't ship anything if there's any hardware on 
which it doesn't work. I doubt anyone has ever released an operating 
system which works on all PC hardware.

> If I got your point right it's also no option to just update to the
> latest anaconda (for example) and use the same packages like the first
> spin?

You can do that with a live install, and using an updates image - as 
documented in the bug and on the commonbugs page - is the equivalent for 
non-live installs.

For a network-related bug like this, it's likely better to source the 
updates image from a local device - USB stick would be easiest - than 
from the network.

It's very easy to propose releasing new spins, but it's much harder to 
actually do it. It would suck up a bunch of release engineering and QA 
time, because each re-spin would have to go through the same 
spin/validate/re-spin/validate/release process that any Fedora release 
goes through. It is not a trivial effort.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net