Re: Bug mass filling
On Thu, 26 Oct 2006 12:02:31 +0100, Ian Jackson <ian@davenant.greenend.org.uk> said:
> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson
>> <ian@davenant.greenend.org.uk> 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 ?
Because developers and bug reporters are human, and may need
some guidance about bug severities, and
> 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.
A very developer centric view. But there are other pepople in
the community; and as a general statement this falls far short of the
mark for which bug severities are actually useful for. Bug severities
have one other purpose, and perhaps the most importan of all: It lets
people know whether or not it is OK to upgrade or install a package,
and but severities are one way of gauging a release' quality. While
only partially relevant to this case, you are making what seems like
a general statement, and missing important bits.
>> 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.
I see you are trolling. However, I suppose I can say I have
been trolled, since I am going to reply anyway.
People do not work like that. Simply ignoring the way people
report bugs, and pretending that every one looks at all kinds of
unrelated bug reports and cogently arrives at a working, consistent,
and borderline correct severity may work in an, ahem, bizarre world
you live in, but does not work on planet earth.
So, policy guidelines as to bug severities are a cheap way to
arrive at a consistent default for bug severities, and there is no
reason not to add such guidance, as long as the guidelines are
flexible, and, more importantly, correct.
> There is only one significant problem with the list at
> http://www.debian.org/Bugs/Developer#severitieswhich is the
> definition of `serious'. It should be replaced with:
May I suggest that his opinion is perhaps as, umm, ridiculous,
as the rest of your rant?
> 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.
Jindani.
manoj
--
All things that are, are with more spirit chased than
enjoyed. Shakespeare, "Merchant of Venice"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: