On Fri, Oct 20, 2006 at 05:18:41PM -0700, Steve Langasek wrote:
> 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.
>
Hi Steve,
One of Debian's principal attributes is openness, as with all FLOSS
projects. With each release, would it useful to have, in addition to the
Release notes, a _document_ like this:
$RELEASE_NAME-ignore list:
===============================================================================================
PACKAGE|BUG NUMBER|BUG DESCIPTION |REASON FOR IGNORING ISSUE[|OPTIONAL_NAME|OPTIONAL_DATE]
foo | 1234 | deletes db on mips | no one uses it on mips | joe RM | 01-01-1969
foo | 1234 | deletes db on mips | happens only on sundays | jane RM | 01-02-1969
===============================================================================================
so that users, sysadmin and such could see what issue may affect them.
Similarly,
this document could _first_ be started as a _wiki page_ which could be
generated from the current BTS info and during the release the RM's
could have a location where they can state their reasons and then the
package maintainer can have a centralized place for this info and an
easy way to see and comment upon it.
Because it seems that release issues between package maintainers and
release managers happens in various place and have conflicting or subtly
different answers depending upon person asked, when asked, etc. So a
solid single point of update would seem to at least address some of this
so that if 2 people or RM's give what seems to be confusing or
contradictory info, it would have a single place to reference, where
this would be easily seen by all involved.
happy cat hurding,
Kev
--
| .''`. == Debian GNU/Linux == | my web site: |
| : :' : The Universal | debian.home.pipeline.com |
| `. `' Operating System | go to counter.li.org and |
| `- http://www.debian.org/ | be counted! #238656 |
| my keysever: pgp.mit.edu | my NPO: cfsg.org |
Attachment:
signature.asc
Description: Digital signature