Re: Release-critical bugs, and #97671
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 <srivasta@debian.org> 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 debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: