I've reviewed the entire discussion in this bug, and I don't believe there is a problem here other than possibly confusing or incomplete documentation of the workflow involved in Debian. Let me recap to ensure that I understood the problem report and then try to explain why I don't believe this bug should remain open.
My understanding of the report is this: Debian Policy does not place any restrictions or requirements on things other than packages of software. Specifically, it does not include requiremnets for the Debian Bug Tracking System or for Debian Policy itself. There are three bug severities that are considered release-critical. Two of them (critical and grave) are specific to malfunctioning software. The third (serious) is described as either meaning that the maintainer of a package considers it unsuited for release or that the package violates Policy. Therefore, the concern is that RC bugs cannot be filed against infrastructure other than packages, such as the BTS or Debian Policy, because none of those severities apply. Here are the reasons why I don't believe a change in Debian Policy is warranted: 1. Debian Policy is specifically about technical requirements for the distribution, by which it means the packages and software that a user would install on their systems. Debian Policy does not set requirements for project infrastructure, governance, or other issues other than the technical makeup and functioning of packaged software. Requirements for the project infrastructure, except insofar as they are directly involved with the contents of packages, are out of scope for Debian Policy. 2. The original report is primarily concerned with bugs in project infrastructure or documentation that result in RC bugs in packages. However, RC status is not transitive. A documentation bug that leads a maintainer to introduce an RC bug is not itself necessarily RC. RC has a specific meaning: the bug must be fixed in order to be included in the release or in order to allow the release to proceed. Inaccuracies in the Policy manual or problems with the BTS do not meet this definition. We can release a stable version of Debian without fixing them. This may not be ideal, but it happens that Policy can get out of date with reality. That needs to be fixed, but it doesn't warrant release-critical levels of attention nor does it warrant holding the release until that bug is fixed. 3. The concern about requiring a relevant statement in Policy in order to set a bug to release-critical status is based on a very literal reading of the BTS instructions. Instructions of this sort usually should be written to discourage people from filing high-criticality bugs. The experience of nearly every publicly-accessible bug-tracking system is that most people err on the side of assigning too high a severity, not too low. Bug reporting instructions are therefore usually written to discourage high severities to compensate. If someone is confident of their understanding of a problem and the way the project wants to deal with it, they can use bug severities according to the spirit rather than the letter of their description. I've seen this happen many times with RC bugs, where something is clearly release-critical and hence should have a serious or grave severity even though it doesn't quite meet the normal definitions of those severities. I think this sort of fuzziness is inevitable in any system used by humans, and it's better to assume some fuzziness than to try to specify every detail. I think one could argue that the definition of serious could be usefully broadened a little to encompass other release-critical problems that aren't covered by the text that you cite, although I would hesitate to propose any wording. I think that one could also argue that such edge cases where point 3 above would come into play aren't the sort of thing that should be documented but instead should be left to human discretion. The documentation isn't absolute. While I can see some faint justification for reassigning this bug to the appropriate package for bug-maint-info.txt (I'm not sure which that would be off-hand), given that Don has already commented extensively on this bug and given the above point about leaving it to human discretion, I'm inclined to close it instead. I don't think there's really a problem here. There's some degree of "insider knowledge" about other things that can be RC, but I think that's inevitable and I think the example used frequently in this bug report is actually not an RC bug. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org