Release-critical bug process?

Adam Williamson awilliam at redhat.com
Mon Feb 9 22:18:20 UTC 2009


On Mon, 2009-02-09 at 08:45 -0500, James Laska wrote:

> 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?

Quick note, here: the intent of 'severity' and 'priority' is different.
Particularly as regards a distribution. 'severity' is how bad the
problem is. 'priority' is how fast it should be fixed.

Particularly in a distro context, the two don't map directly to each
other. Basically, 'severity' should only be judged in the context of the
package. If it's a crasher, it's 'critical'; if it's some small cosmetic
bug, it's 'minor'. But 'priority' should be judged in the context of the
distro. A small cosmetic bug in Firefox that everyone in the world would
see may be 'minor' severity but 'release_critical' priority; a crasher
bug in some obscure chemistry app may be 'critical' severity but 'low'
priority.

That's the method that makes sense to me, anyway. I recognize that
Fedora doesn't really use the 'priority' field, preferring to use
blocker bugs, but I think the 'severity' field can be profitably used to
help maintainers organize their bug load - if Bugzappers correctly
identify the 'severity' of each bug, a busy maintainer can prioritize
'critical' issues over 'minor' ones.
-- 
adamw





More information about the fedora-test-list mailing list