/usrmove?

[Adam Williamson]

Reindl Harald <h.reindl at thelounge.net> wrote:

>
>
>Am 08.02.2012 22:56, schrieb Adam Williamson:
>> On Wed, 2012-02-08 at 12:49 -0900, Jef Spaleta wrote:
>>> On Wed, Feb 8, 2012 at 12:46 PM, Adam Williamson
><awilliam at redhat.com> wrote:
>>>> "The objectives of the Alpha release are to:
>>>>
>>>>    Publicly release installable media versions of a feature
>complete
>>>> test release
>>>>    Test accepted features of Fedora 17
>>>>    Identify as many F17Beta blocker bugs as possible
>>>>    Identify as many F17Blocker blocker bugs as possible"
>>>
>>> And in this scope. Inability to upgrade would be such a Beta
>blocker, methinks.
>> 
>> Sure. But the above doesn't mean that beta and final blockers should
>be
>> *fixed* in Alpha (obviously not). The point is that the Alpha exists
>*in
>> order to be used for the discovery of bugs that will block Beta and
>> Final*. i.e., we need an Alpha release to test upgrading, find out
>that
>> it's broken, and file a bug that blocks the Beta release. :)
>
>why in the world do you need this if you STILL KNOW that something
>is exremely broken? this is useless - block ALPHA if you are
>aware of horrible broken things instead wasting peoples time
>with saying "we have a new alpha lpease test it"
>
>-- 
>devel mailing list
>devel at lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/devel

It's interesting you should say that, because it's a natural instinct: if you find a Big Scary Bug, panic and pull the big red Stop lever until it's fixed, then proceed as normal.

Our experience, though, is that this is entirely the wrong way to do things. The problem is that life is rarely so neat: you don't get an orderly succession of Big Scary Bugs popping up one at a time for you to shoot down.

No, it's usually the case that there are ten or a dozen Big Scary Bugs at any one time. Given that, it's a very bad idea to find one and then focus all attention on it: block all releases until it's fixed and stop looking for or working on other BSBs. It's a much better idea to work as hard as you can to _prevent_ that happening - obviously you have to make sure the BSB gets fixed, but you definitely DON'T let that stop you looking for and fixing other BSBs. Rather the reverse - I think it's important to work actively on finding ways around big showstoppers when we hit them, so we can find the *other* big showstoppers lurking behind them.

Otherwise you get a bad process where you hit a crasher in anaconda and everyone downs tools for two days until it's fixed and a new build is done - whereupon you discover there's another crasher on the next page of anaconda, and if you'd just found a way to work around the earlier crash and carried on testing, the anaconda team couls have been working on BOTH crashes, and probably fixed both in the same two days.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net