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. > Hi, 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? pandora-inspired, 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