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:
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.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
