Manoj Srivastava writes ("Re: Bug mass filling"):
> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <[EMAIL PROTECTED]> said:
> > There are two different and orthogonal properties of a policy
> > requirement:
> > 1. [...]
> > [and]
> > 2. Is a violation of the requirement release-critical ? That is,
> > would it be better to remove the package (or to stick with the
> > old version of the package) than to live with this bug ?
>
> I posit the second one is not a characteristic of the policy
> requirement; it is a characteristic of the bug.
Well, yes.
> My stance is that bug severity tags are tied to policy
> violations, since that can be determined mechanically; violate a must
> directive, bug is serious. Whether or not all serious bugs are RC is
> anothermatter that the release team determines; hence the *-ignore
> tags.
Why on earth is it useful to encode some scripturally-determined
property of a bug in the severity ?
The use for the severity is to 1. allow us to record whether the bug
is release critical (which is definitely something we need to track)
and 2. allow the project to prioritise its work (which is also
something we need to track). Helpfully we can use the same linear
scale for both because all release-critical bugs should always have a
higher priority than all non-release-critical bugs.
> The problem is, since this involves human judgement, one can no
> longer state in policy what category a must violation of policy falls
> into; policy must waffle with well, if you find a policy violation,
> fgiure out what severity the ciolation would be, consult your
> feelings, other peoples feelings, release managers, and perhaps the
> phase of the moon.
This is a completely bizarre assertion. If you're submitting a bug
you can look at the BTS web page which gives clear definitions of all
of the bug severities.
There is only one significant problem with the list at
http://www.debian.org/Bugs/Developer#severities
which is the definition of `serious'. It should be replaced with:
serious
Release critical bugs (other than `grave' and `critical' bugs);
see also the Release Managers' policy at <URL>. Do not set
this severity unless it would be better to remove the package
from the distribution than to ship it with this bug. The
final decision about whether a bug is release critical rests
with the Release Managers.
Obviously there is room for judgement here by the submitter and the
maintainer - but we rely on our colleagues to make the right decisions
in all sorts of areas.
> Since we already feel that our RM's are overworked (hence
> dunc-tank and payment schemes), I strongly suggest we not add to the
> RM's burdens any more than we have to.
If the RMs want to write a document saying what counts as a release
critical bug, can do so. And lo, look, they have.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
