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

Re: Bug mass filling

On Tue, Oct 24, 2006 at 04:04:54PM -0700, Steve Langasek wrote:
> On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
> > > Well, I did say that it was a very rough draft. ;)
> > > Second try:
> > >   "... However, this is not a direct mapping, and the release
> > >   managers determine the severity of each violation."
> >         Direct mapping of *WHAT*? are you falling into the assumption
> >  that serious == RC? Why?
> Because your choice of mapping blurs the distinction between one-time
> exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy
> violations that the release team does not believe should be promoted to RC
> status at any time in the foreseeable future.  "etch-ignore" is most useful
> as a tag if its use is restricted to those bugs whose
> *non*-release-criticality is transient in nature -- the alternative is that
> the release team is stuck going through the BTS after each release and
> re-adding new tags to those bugs about policy violations whose severity does
> not justify exclusion from the release.
So certain bugs can be marked $STABLE-ignore to allow transient rc
issues to be ignored for a release and will become no-ops after release.
Are you suggesting that each package can have a related list of
non-transient bugs that should be marked (with a new tags called )
ignore-this-policy-violation where this can be attached to any package
related bug for any length of time until the issues is deemed
worthy/necessary to be addressed?

|  .''`.  == 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

Reply to: