Re: Bug mass filling
On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek <vorlon@debian.org> said:
> 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.
That does not make sense. After etch is released, etch-ignore
tags are no-ops -- so there is no need to go back and untag anything.
And if there are anyissues that are policy must directives
that the release team has take upon itself to say are policy
directives it is not worth following, then they should file important
bugs against polocuy to either have the requirements removed, or the
issue resovled by the tech ctte.
This bit about "Oh, lets just ignore policy, for we know
better" is absolutely the wrong way to go about this. Fixing policy
is the right way.
manoj
--
Concept, n.: Any "idea" for which an outside consultant billed you
more than $25,000.
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: