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

Re: Bug mass filling

On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <ian@davenant.greenend.org.uk> said: 

> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek
>> <vorlon@debian.org> 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

        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.

He gave her a look that you could have poured on a waffle.
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: