[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release-critical bugs, and #97671

>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> 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

	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.


 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.


	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.


 (null cookie; hope that's ok)
Manoj Srivastava   <srivasta@debian.org>  <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 debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: