Bug#509732: Debian Policy doesn't include directive for filing RC bugs against the Policy

[Russ Allbery <rra@debian.org>]

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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>