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

Re: RC bug #308477 and MIA maintainer (?)

On Sat, May 14, 2005 at 07:33:01AM -0500, Bill Allombert wrote:
> On Sat, May 14, 2005 at 04:23:02AM -0700, Steve Langasek wrote:
> > On Sat, May 14, 2005 at 05:59:07AM -0500, Bill Allombert wrote:
> > > On Thu, May 12, 2005 at 07:59:33PM -0700, Steve Langasek wrote:
> > > > severity 308477 important
> > > > thanks

> > > > You are correct that it is a policy violation.  However, not all policy
> > > > violations are release-critical for a given release; see

> > > Maybe I will sound procedural or something, but I would really prefer
> > > if such policy violation bug were severity serious with a sarge-ignore
> > > tag. It is important to keep track of policy violation bug that affect
> > > sid, and it will be hard to remember all bugs that should have their
> > > severity raised once sarge is released.

> > As it's been explained to me by the BTS folks, use of sarge-ignore implies
> > that the bug will become RC for etch immediately after sarge's release.  For
> > this bug, I don't see any reason to think that's the case.

> Is it really a problem ? Is not the bug worth fixing ? 

> Why not rename sarge-ignore to etch-ignore once sarge is released ?
> Why not both downgrade and tag the bug, or something ?

> I am concerned because in effect that hijack the definition of the
> serious severity (which is 'violate a must in the debian-policy')
> administrated by the Debian policy group.

	is a severe violation of Debian policy (*roughly*, it violates a
	"must" or "required" directive)

<http://www.debian.org/Bugs/Developer#severities>, emphasis added; note the
link to the sarge RC policy.

The definition of serious, as indicated by the BTS admins, includes RM

The bug in question doesn't actually break anything, so adherence to policy
is not release-critical; this won't change with the release of sarge, or
even with the release of etch.

> It is my understanding that the sarge-ignore tag was introduced for the
> express purpose to allow the Release team to define the release policy
> without stepping of the foot of the Debian policy group. If sarge-ignore
> is not suitable for that task, then we should reconsider its
> implementation.

> The Debian policy update follows an open process and is an important
> part of Debian. It should keep authority on the serious severity.

AIUI, the BTS admins have authority over the meaning of the different
severities and tags.  I have no opinion on the matter, as long as there is
some means the release team can use to differentiate between bugs that need
to be addressed before the release, and those that don't.  In this case, I'm
merely following what I understand to be the recommendation of the BTS

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: