Release-critical bug process?

[James Laska]

On Mon, 2009-02-09 at 01:17 +0530, Rahul Sundaram wrote:
>  http://fedoraproject.org/wiki/QA/ReleaseCriteria

I'm of the mindset that QA should not solely define the release
criteria.  Defining what a release should be must be a collaborative
decision.  Perhaps the above link is something that each team provides
*minimal* content for and FESCO reviews/approves?  QA can then taylor
testing around what expectations the development teams are setting along
with the approved release criteria.  Should all this data eventually
land in each test plan as 'exit criteria'?

I'd love to see a world where each test team defines their exit criteria
for testing.  I find it difficult to fill a single document with
absolutes that properly apply to all levels of testing throughout the
operating system.  Success for the Fingerprint feature will look much
different than success for KDE4.2 and kernel.

That doesn't mean that QA cannot or should not be involved in deciding
whether something blocks the release.  I wonder if the release blocking
decision could be more collaborative?  

The issues should be flagged/raised/escalated appropriately along with a
basic risk assessment (e.g. users will not be able to run 'yum update').
This raises some questions for me ...

 * How to assign defect severity?  # should we bother?
 * When to escalate a defect?
 * How to escalate a defect?

Thanks,
James


> Is this, currently, the case? If not, what is the release-critical
> process? What do you guys think about this? Should we have a process?
> Should it be as I described? Who should be in charge? (I would say
> -bugzappers).

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20090209/a79fe25e/attachment.sig>