[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#509732: Kalle's message #68

On Fri, 26 Dec 2008 12:05:15 +0200 Kalle wrote:

> I think what José is reporting is that in his opinion the BTS (and
> actually all pseudopackages available in the BTS) should be considered
> a part of the release and there should be Policy instructions as to
> how the BTS should work

Only with regard to the Policy.
>From the note in the retitling message:

"Please see the severities in bug-maint-info.txt."

>From bug-maint-info.txt (unrelated to #227941):


Severity levels

   The bug system records a severity level with each bug report. This is
   set to normal by default, but can be overridden either by supplying a
   Severity line in the pseudo-header when the bug is submitted (see the
   instructions for reporting bugs), or by using the severity command
   with the control request server.

   The severity levels are:

          makes unrelated software on the system (or the whole system)
          break, or causes serious data loss, or introduces a security
          hole on systems where you install the package.

          makes the package in question unusable or mostly so, or causes
          data loss, or introduces a security hole allowing access to the
          accounts of users who use the package.

          is a severe violation of Debian policy (roughly, it violates a
          "must" or "required" directive), or, in the package
          maintainer's opinion, makes the package unsuitable for release.

          a bug which has a major effect on the usability of a package,
          without rendering it completely unusable to everyone.

          the default value, applicable to most bugs.

          a problem which doesn't affect the package's usefulness, and is
          presumably trivial to fix.

          for any feature request, and also for any bugs that are very
          difficult to fix due to major design considerations.

   Certain severities are considered release-critical, meaning the bug
   will have an impact on releasing the package with the stable release
   of Debian. Currently, these are critical, grave and serious. For
   complete and canonical rules on what issues merit these severities,
   see the list of Release-Critical Issues for Etch.


Since the Policy isn't a package, the critical and grave severities
don't apply to a bug caused by the policy that would be Release
Critical. Since a bug is serious when it «is a severe violation of
Debian policy (roughly, it violates a "must" or "required" directive),
or, in the package maintainer's opinion, makes the package unsuitable
for release» it is impossible to file a serious bug about it (the bug
caused by the Policy which is Release Critical) since there's nothing
in the Policy that mandates what is required to happen when there is a
RC bug caused by the Policy. The only solution would be to mail the
mantainer of the debian-policy package asking that he raises the
severity of the bug against the debian-policy *package* to serious
since the Policy is causing a release-critical bug so the *package* is
unsuitable for release.

If you still don't understand, imagine that a text is mistakenly
introduced in the Policy and it causes a RC bug. How should this bug
about the Policy be reported? According to the Policy Manual:

"If you discover an error in this manual or if you want to give any
comments, suggestions, or criticisms please send an email to the
Debian Policy List, debian-policy@lists.debian.org, or submit a bug
report against the debian-policy package."

If the error is reported to the list it can remain and the package with
the erroneous policy be released if it is included in the package and
the Policy isn't amended before. If it is amended before Debian is
released and the package includes the unamended text a bug with RC
severity could only be filed by the mantainer (if an NMU can fix it
then the description in bug-maint-info.txt should be updated to reflect

If the error is reported to the Bug Tracking System we are in a similar
case as with the mailing list. Only if a mantainer raises severity of
the debian-policy *package* to serious would the bug be considered as
RC. If the mantainer doesn't and no other developer does the error in
the Policy that is causing a RC bug would not be considered RC. If the
erroneous Policy Manual gets into the package the bug against the
package wouldn't be considered RC until a mantainer raises severity to
serious. If no mantainer raises severity to serious the package could
be released with the erroneous Policy Manual (that is causing the RC
bug) in the next Debian release.  The only solution would be to include
a directive in the Policy requiring that errors in the manual that
cause RC bugs are required not to get into the debian-policy package.

Reply to: