Russ Allbery <r...@debian.org> writes: > Ben Finney <ben+deb...@benfinney.id.au> writes: > > > 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. > > I guess I can kind of see what you're driving at. But on the other > hand, we shouldn't put all the weight on the release managers to > review every bug in Debian and decide whether it's release-critical.
Agreed, and that wasn't the intent of my statements. The release managers set a policy on how they will regard the bug's severity, but it's not a definition *of* the severity levels. > They publish release criteria, and I think the rest of us should try > to at least take a first pass to save them work. Indeed, but that decision should be made on an assessment of the impact of the bug's severity as per the definitions of the severity level values, and only *then* should the chosen severity level be a consideration for release of the package. I'm arguing that the decision flow should be in that direction (and is defined that way), whereas I see it sometimes flowing the other way, which I see as incorrect. Don Armstrong <d...@debian.org> writes: > The only distinction that has importance for release criticality is > the important <-> serious division; anyone can try to adjust the > severity to follow the guidelines of the release team, but the > release team make the final decision. Likewise, anyone can try to > adjust the severities outside of this division, but the > maintainer(s) make the final decision. Perhaps my point can be made better by a thought experiment: Suppose the release managers decide that the division line you point out will, as of tomorrow, lie in a different place from where it is today (i.e. between a different neighbouring pair of severity levels). Suppose further that their reasoning for this is unanimously (!) accepted by all DDs as reasonable and the change a necessary one. I would argue: Such a situation should *not* require changing the severity level of *any* bug report in the BTS. Any existing report that requires its severity changed as a result of this changed criterion is classified incorrectly, and any decision to change a bug report's severity, based only on this changed release criterion, is an incorrect decision. By that argument, we should consider “is this bug release-critical?” to be irrelevant (or, at least, out of our hands) when setting the severity level of a bug report, just as though the criterion cannot be known at the time of setting the severity level. -- \ “No wonder I'm all confused; one of my parents was a woman, the | `\ other was a man.” —Ashleigh Brilliant | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
