On 16/02/13 08:49 AM, Kevin Fenzi wrote:
On Fri, 15 Feb 2013 18:34:33 -0800
Adam Williamson <awilliam@xxxxxxxxxx> 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
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
