Re: Release-critical bugs, and #97671
Manoj Srivastava writes (SuperCite undone):
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > But, I can see that you might want to avoid too much discretion being
> > exercised by bug submitters.
>
> Discretion is not quote how I would describe bug severity
> escalation, but yes, bug severities ought to be as objective as we
> can make them.
I don't think this quite follows, as you put it here. I agree that
it's unhelpful to rely on submitters' judgement to accurately
prioritise bugs, and that a good way to help submitters do a useful
thing is to give them objective criteria.
But, that doesn't mean that the severities need to remain set by those
objective criteria. Someone other than the submitter, with a greater
overview of the whole package or distribution, might have a better
idea, and might reasonably apply subjective judgement.
Indeed, I think the argument you make later leads on to a different
conclusion. You say:
> [The] RM decides on a case by case basis [whether a bug is
> unreleaseable], and factors in the time left to release, this is
> the hardest criteria to achieve, and indeed, we should not even
> try.
So, you think that the bug severity should not be used to record the
bug's releaseability.
The question is then, what other useful information can we use it to
record, or are we trying to use it to record, in a way that supports
everyone in our work ?
My understanding of the main way we treat the BTS is that we use it to
store our todo list - both the whole project's, individual
maintainers'.
For some bugs, namely approximately the ones corresponding to the
current definitions of severity levels grave and critical, it is very
important to the whole project to get them fixed, because they have
bad effects which spread far beyond frequent users of the package.
These bugs are high-priority work items for the whole distribution.
For most other bugs, the package maintainer, and other people closely
involved with the package, are in the best position to decide which
bugs are the most serious and which should be worked on first.
If, then, we are not to encode in the BTS severities the
releaseability of bugs, but instead use them to prioritise work, it
seems clear that at least for bugs which are not `critical' or
`grave', the package maintainer should have discretion.
This discretion can't sensibly be eliminated by specifying the
relative (or absolute) priority of bugs in the policy manual and BTS
instructions, because those documents can't capture all of the
relevant circumstances.
Do you follow this argument ? Do you agree with it ? As you can
probably tell, I think I'm still feeling my way around this issue.
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: