Manoj Srivastava <[EMAIL PROTECTED]> wrote: > On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek <[EMAIL PROTECTED]> 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)
