Manoj Srivastava writes (SuperCite undone): > Ian Jackson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
