Re: Bug mass filling
On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
> > That's not correct. [serious, grave, and critical] are the "release
> > critical" severities, though some release critical issues won't be
> > fixed for any given release, due to either being not known about or
> > understood (ie, not filed at all, or not given the appropriate
> > severity or attention), or given a specific exemption by the release
> > team ("etch-ignore").
> So riddle me this: currently, policy states that violating a
> "must" or "required" directive in policy is a serious bug; which
> seems to fly in the face of the release process having appropriated
> the "serious" severity.
> Are we removing the policy that violations of policy
> requirements are serious bugs? Is there new guidance on what policy
> violation bug severities ought to be? Are such bugs to be filed
> under "normal"? Or "important"?
> My understanding, which seems to be flawed, was policy
> violations were taken seriously (heh), and policy violation meant to
> be ignored for a release were granted special dispensation (remained
> serious, but were exempt).
> If this is not the case, we should change the policy, and drop
> any reference to bug severities for packages violating policy.
> Personally, think that is not a good idea, since adherence to
> technical policy seems to be the underpinning of the high quality of
> implementation we always had, but perhaps my mileage has varied.
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?
How should we distinguish this case from rules that are *generally* but not
always an indication of a bug (policy's description of "should"), and from
one-time exception grants by the release team (the current use of the
"-ignore" tag)?
The current handling sanctioned by the BTS admins seems an appropriate
middle ground for distinguishing the cases that are most relevant to bug
handling across releases.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: