On Wed, 2006-05-17 at 09:19 +0100, Adam D. Barratt wrote: > On Wednesday, May 17, 2006 7:59 AM, Lionel Elie Mamane <[EMAIL PROTECTED]> > wrote: > > On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote: > >> ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti: > [...] > >>> AFAIK, vilolating policy always waarent a serious bug: > [...] > >> This is not what Steve Langasek tells me (or else I'm seriously > >> misunderstanding). The etch_rc_policy.txt document is what documents > >> what is release critical. > > > > Doesn't that mean the bug is severity serious, but should be tagged > > "etch-ignore"? That's what we did with sarge, if I remember well? > > No. The "foo-ignore" tags mean "this issue /is/ RC, but we're ignoring it > for the release of foo". Any bug tagged "etch-ignore" is by definition RC > the moment etch is released. > > The exact definition of what qualifies for a severity of serious or above > (i.e. RC) are the purview of the Release team, as noted at > http://www.debian.org/Bugs/Developer#severities. A "severe violation of > Debian policy" is one which violates the current release policy, as laid out > by the Release team.
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. 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, 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]. At least with debian-policy, any changes must actually be discussed and viewed by several people, which increases the probability that this type of error is found and corrected, hopefully before it even becomes policy. 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. [0] 5g of the the etch RC policy [sic][1]: Scripts must include the appropriate #! line, and set executable. The package providing the script must Depend: on the appropriate package providing the interpreter. [1] The text in [0] should say "be set executable" or "be executable" or even "have been set executable", instead of "set executable".
signature.asc
Description: This is a digitally signed message part
