>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Manoj Srivastava writes (SuperCite undone):
Ian> I don't think this quite follows, as you put it here. I agree
Ian> that it's unhelpful to rely on submitters' judgement to
Ian> accurately prioritise bugs, and that a good way to help
Ian> submitters do a useful thing is to give them objective criteria.
So far, so good.
Ian> But, that doesn't mean that the severities need to remain set by
Ian> those objective criteria. Someone other than the submitter,
Ian> with a greater overview of the whole package or distribution,
Ian> might have a better idea, and might reasonably apply subjective
Ian> judgement.
To what end? Why make the objective criteria malleable? When
one discards objective criteria for classifying bugs, one merely
opens the door for more disruptive disagreements between reporters,
and even fellow maintainers. With around a 1000 developers and
counting, there is unlikely to be agreement amongst developers.
When you bring in policy conformance, and RCness, the
maintainer may no longer be the one with the best knowledge of the
issues.
Also, just because a person is the maintainer does not mean
they are more knowledeable than the reporter. (I would prefer not to
name names here).
Ian> So, you think that the bug severity should not be used to record the
Ian> bug's releaseability.
Indeed.
Ian> The question is then, what other useful information can we use it to
Ian> record, or are we trying to use it to record, in a way that supports
Ian> everyone in our work ?
It represents impact on the system. It categorizes the bug. It
helps people understand potential damage the bug could cause, at a
glance. It keeps packages out of testing. Releases occur farly
seldom, and whether a certain version of a package is releasable or
not is of importance to a small number of people for relatively short
intervals of time.
I think we should stop overloading the BTS for a TODO list for
the project and developers. In this day and age we have better tools
both for personal todo lists, and groupware products for the project.
If the project thinks it is so important, why do we not set up
a wicki? or other such tool? It is easy enough to do so.
Ian> For some bugs, namely approximately the ones corresponding to
Ian> the current definitions of severity levels grave and critical,
Ian> it is very important to the whole project to get them fixed,
Ian> because they have bad effects which spread far beyond frequent
Ian> users of the package. These bugs are high-priority work items
Ian> for the whole distribution.
Quite so. And a maintainer should not have the discretion to
junk the objective criteria and label them wishlist on a whim, ot
because they do not want to work on it, or it is too hard to fix
right now.
Ian> For most other bugs, the package maintainer, and other people
Ian> closely involved with the package, are in the best position to
Ian> decide which bugs are the most serious and which should be
Ian> worked on first.
Quite so. And if they do not violate policy must directives,
for the most part they can.
Ian> If, then, we are not to encode in the BTS severities the
Ian> releaseability of bugs, but instead use them to prioritise work, it
Ian> seems clear that at least for bugs which are not `critical' or
Ian> `grave', the package maintainer should have discretion.
Why?
Apart from using the BTS as a poorly designed groupware
TODO list (I say this, even though I designed policy proposals on top
of the BTS, and I know the pitfalls of doing so), this does not seem
to be useful. Indeed, by making the classification criteria fuzzy, we
reduce the utility of the severity, I think.
I mean, important is more or less left to the
maintainer. normal i catch all. wishlist and serious should still be
left objective. I can see things built on top of a new BTS that
would benefit from well defined classification of bugs.
Ian> Do you follow this argument ? Do you agree with it ? As you can
Ian> probably tell, I think I'm still feeling my way around this issue.
I do follow the argument, but I do not agree, I think we
should stop overloading the BTS, and use it for the primary purpose
_first_, especially if it causes friction between reporters and
maintainers about the severities. And it shall, I fear.
manoj
--
(null cookie; hope that's ok)
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
