Re: Bug mass filling
Manoj Srivastava <srivasta@debian.org> wrote:
> On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek <vorlon@debian.org> said:
>
>> 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.
The work would be to change the tag to "whatever-ignore".
> 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.
I don't like your wording of "not worth following". A policy dictum
might well be important to follow, but non-conformance may still (always
or in particular cases) not be a reason to exclude it from the release.
But you're of course right that Policy and the release-policy should be
synchronized...
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: