Don Armstrong <d...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
