On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> 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?
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]
All critical and grave bugs are release critical, and most
serious bugs too. Any serious but which is non RC is tagged
<RELEAE>-ignore; and the ignore tag should only be set after
consultation with the release managers.
> 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)?
No one ever indicated that violations of a policy should
directive is release critical, or even serious. Are you suggesting we
should make _any_ policy violation the same?
Curently, violating a should policy directive means you get a
"normal" severuty bug.
> 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.
It muddies up the nice, clean distinction that has always been
in out technical policy:
a) MUST/REQUIRED violation: serious bug
If ignored
a1) not RC
else
a2) RC
b) SHOULD violation
normal bug
c) MAY/SUGGESTED violation
wishlist bug
manoj
--
If only you knew she loved you, you could face the uncertainty of
whether you love her.
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]
