Bug severity and release-critical status (was: Bug#509732: Debian policy doesn't feature RC bugs)
Don Armstrong <don@debian.org> writes:
> On Thu, 25 Dec 2008, José Luis González wrote:
> > If a problem is RC, it should be marked as RC. If the BTS manages
> > pseudopackages, a bug in a pseudopackage that is RC should be
> > marked as RC in the BTS.
>
> The BTS has nothing to do with deciding whether particular bugs are
> release critical or not. We indicate to other tools (like britney)
> the set of bugs which are RC and the packages that they affect.
This is an important distinction, too often missed in discussion of
bug reports.
A bug report does *not* say whether the bug is release-critical or
not. The report says what the severity of the bug is; and those
severities are well-defined in terms of the impact the bug has on the
user's system <URL:http://www.debian.org/Bugs/Developer#severities>.
Only one of those severity definitions even mentions suitability for
release, and limits it to the opinion of a release manager. The bulk
of definition of severity levels is derived from observable properties
*of the package*, not of its suitability to a specific release.
The decision of whether a bug is release-critical or not is for the
release managers to make, using the various properties of the bug
(including but *not* limited to its severity) as input to that
decision. They can, in fact, make that decision apparent in the bug
report *without* altering the severity level.
So, it's not correct for anyone but a release manager to decide “this
bug is/is not release-critical, so I'll change the severity”; that is
a perversion of the meaning of the severity field. You can argue about
whether a bug fits the definition of a specific severity level, and
change the severity field value on that basis; but whether the bug
“is release-critical” has no place in that argument.
--
\ “Too many Indians spoil the golden egg.” —Sir Joh |
`\ Bjelke-Petersen |
_o__) |
Ben Finney
Reply to: