Proposal: "automatic blockers"

[Adam Williamson]

On 16/02/13 08:49 AM, Kevin Fenzi wrote:
> On Fri, 15 Feb 2013 18:34:33 -0800
> Adam Williamson <awilliam at redhat.com> wrote:
>
> ...snip...
>
>> Any thoughts on the general idea, or on the specific list of bug
>> types I came up with - any more to add to the list, or remove from
>> it? I don't want to make the list _too_ big, and it shouldn't include
>> any type of bug that could possibly _not_ be a blocker, we want it to
>> be only the completely, 100%, screaming obvious slam-dunks. The last
>> entry is a bit of a 'possible' in my mind, there's an argument for
>> not including it, as people might interpret it too widely. It's meant
>> to cover only the case where we build a TC/RC and it's utterly DOA:
>> the image just flat out fails to boot, for everyone, no matter what
>> the hardware or configuration, it's just dead.
>
> I don't object to the idea, and it might be mudding waters/adding
> process, but couldn't these things be 'acceptance tests'?
>
> ie, rel-eng composes the bits from devel, syncs them up and then a very
> small set of acceptance tests are run on them. If they all pass, great,
> and QA accepts the compose for testing. If they don't, then the compose
> is dead and never goes to wider QA testing.

That's more or less effectively what happens anyway - most of the things 
on the list are the things that Andre always tests the moment the ISOs 
show up. I would be reluctant to make them formal acceptance tests, 
though, because in some circumstances it still makes sense to keep 
testing them - you can still do useful testing of an image that has a 
repoclosure failure, for instance, in some cases.

> That may be too much red-tape and formal, or it might be more clear to
> some people. :) Just thought I would toss it out there. :)
>
> Anyhow, I'm +1 to the idea in general.
>
> kevin
>
>
>
>


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