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

Re: Bug mass filling

On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek <vorlon@debian.org> 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
         a2) RC
 b) SHOULD violation
    normal bug
 c) MAY/SUGGESTED violation
    wishlist bug

If only you knew she loved you, you could face the uncertainty of
whether you love her.
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: