Anthony Towns writes ("Re: Release-critical bugs, and #97671"): > On Sat, Apr 27, 2002 at 01:34:26AM +0100, Ian Jackson wrote: > > But, the idea in the policy manual is that a `must' is a rule for > > which there are not expected to be exceptions; it doesn't touch on how > > damaging a breach of the rule is. > > Uh, this is completely incorrect. See policy section 1.1, Scope.
You're right. My apologies for assuming I knew what it would say without reading it. Manoj Srivastava <[EMAIL PROTECTED]> writes: ] The core error is that bug severities should not be rigidly ] connected to release criticalness. *THAT* is the place where we need ] to make case by case, subjective decisions Let me just see if I can get some common ground here. Does everybody agree that it's not possible for the policy manual to correctly specify in advance whether a particular policy violation will actually mean that a package should definitely not be released ? (I'm going to call this whether the bug is `releaseable' or not, to avoid getting tangled in an argument over the definition of `release critical.) In this case then there are several pieces of different information which we might record in the BTS severity field: (a) The package maintainer's idea of how urgent/important the bug is (b) The release manager's idea of whether the bug is releaseable (c) Something specified by the policy manual Now there is a relationship between (a) and (b): since the release manager decides whether a bug is releaseable, and the package maintainer should really be trying to deal with the unreleaseable bugs first in order to get the package into the distribution, you can encode both (a) and (b) in an appropriate set of severity levels: divide the severity levels firstly into unreleaseable and releaseable, and then have a number of levels of each. That leaves us with (c) as the other option. I admit that I don't understand the reasoning behind this at all. Surely since the policy manual speaks in terms of generalities, anything it says about classes of bugs is by and large going to need interpretation/discretion anyway. I don't see the value of recording a purely mechanical class in the BTS. Now, that's not to say that the policy manual can't have something to say about what's likely to be a releaseable bug - thus leading one to consult the policy manual when assigning severities in the (a)/(b) model - but it clearly can't have the last word. (It seems to me that the `must's in the policy manual ought to be interpreted this way.) AJ also wrote: > I'm sorry I don't have a catchy way of phrasing this, but it *is* a bug > that makes the package unsuitable for release, it just so happens that > it's going to get released as is now anyway. I hope you won't mind me saying so, but this sounds confused to me. Surely if the bug makes the package unsuitable for release, that *means* that we ought not to release it ? Conversely, if we decide that the package is better off released even with this bug, it means that we've decided that the bug is releaseable, given all the circumstances ? A bug's releaseability can of course change depending on lots of external factors. > > serious > > is a severe violation of Debian policy or any other problem, > > which makes the package unsuitable for release. > > Absolutely unconditionally _no_. This leaves the definition of serious > a matter of judgement on behalf of the submitter which makes managing > the release an order of magnitude more difficult. Well, the current wording sort of does that too: serious is a severe violation of Debian policy (that is, it violates a "must" or "required" directive), or, in the package maintainer's opinion, makes the package unsuitable for release. But, I can see that you might want to avoid too much discretion being exercised by bug submitters. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]