On Wed, May 17, 2006 at 12:37:56PM +0000, Brian M. Carlson wrote: > Then when are we removing the debian-policy package from the archive? > But seriously, if violating Debian Policy has no consequences, then it > probably won't be followed. As it stands now, Policy is useless because > the worst that can happen is an important bug, which can be safely > ignored almost forever. The release team is not going to enforce all policy violations as RC bugs, because although all policy violations should be considered bugs, not all of them should warrant delaying the release or removing the package from the release. So whether or not such bugs are labelled "serious" is irrelevant, because labelling them "serious" would just mean that sev: serious no longer correctly identifies RC bugs and we would then need some other way to separate RC from non-RC serious bugs. > As far as the etch_rc_policy.txt, there are at least 10 different issues > with that document that may be unintended, one of which is that as it > stands now, all perl-using packages *must* depend on perl-base, Perl-base is Essential: yes. It is not a bug to not depend on an Essential package, so nor is it an *RC* Bug to not depend on an Essential package. > and all python-using packages *must* depend on the package providing the > interpreter (/usr/bin/python is *not* an interpreter, merely a symlink), > such as python2.3, python2.4, or python2.5[0]. This is a lame argument. The RC policy says "package providing the interpreter", not "package containing the binary". /usr/bin/python is clearly an interpreter provided by the "python" package. Patches to improve the wording of the RC bug policy are certainly welcome, but I'm not going to spend a lot of my own time trying to idiot-proof it; both of your examples seem terribly contrived to me, and if the etch RC policy is read with the understanding that it identifies those violations of *existing* policy that are RC, rather than attempting to declare *new* policy, I don't see that there's any reason for confusion here. > Finally, I would prefer if some tag existed that would indicate that a > bug is not a concern for the release but is still a major error in terms > of Debian Policy. I understand that such tags *do* exist, and that they > are called "sid" and "experimental". I also understand that these are > deprecated with BTS version tracking; however, since these tags have the > desired effect, and there are no other ones with equivalent effect, I > will use them for all of my current and future bugs. No, the "sid" tag does not have the desired effect. It has the effect of causing britney to regard the version of the package in sid as having an RC bug, and take it into consideration when evaluating the sid version of the package for propagation to testing. Please don't try to use tags this way, it's inconsistent with how the software works (and is intended to work, TTBOMK). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature