On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <[EMAIL PROTECTED]> said:
> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek
>> <[EMAIL PROTECTED]> said:
>> > When there are issues addressed in policy that are
>> > black-and-white where all violations of the policy requirement
>> > are definitely bugs, but not all such violations should be
>> > grounds for keeping a package out of a release, how do you
>> > suggest such rules should be handled in the normative language of
>> > policy, and how do you suggest that the related bugs be handled
>> > in the BTS?
>>
>> Gee. Don't we already have something very like this?
>>
>> These classifications are roughly equivalent to the bug severities
>> _serious_ (for _must_ or _required_ directive violations), _minor_,
>> _normal_ or _important_ (for _should_ or _recommended_ directive
>> violations) and _wishlist_ (for _optional_ items). [2]
> There are two different and orthogonal properties of a policy
> requirement:
I posit the second one is not a characteristic of the policy
requirement; it is a characteristic of the bug.
> 1. Is the requirement applicable in all cases, or are there
> sometimes overriding reasons to it another way, or exceptional
> cases where the requirement ought not to apply ?
> 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'm happy that the policy manual should itself determine the answer
> to the first question; and this is the conventional distinction
> between `must' vs `should'.
> But the second question is much more subtle, and also isn't properly
> decided by the process that maintains the policy manual. It should
> be probably be decided by the package maintainer in the first
> instance; with the release managers giving both general guidance and
> specific advice, and having the final decision.
Nothing you have said contradicts either what I or aba have
said; the devil lies in the details you have elided.
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.
Andreas is of the opinion we should instead have all serious
bugs be RC, violations of policy must directives that are not RC
should be downgraded.
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.
Unlike the decision of whether a seirous bug is RC under my
proposal, where the word of the RM is law; there is no final
authority about the severity of a policy violation bug under the
alternate proposal. Any maintainer is then free to insist that his
violation of a bug would not be RC, anyway, and downgrade the bug; it
would mean that the RM's would have to be brought in every time there
is a violation of policy.
Since we already feel that our RM's are overworked (hence
dunc-tank and payment schemes), I strongly suggest we not add to the
RM's burdens any more than we have to.
manoj
--
He gave her a look that you could have poured on a waffle.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
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]
