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):
BEGIN QUOTE:
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:
critical
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.
grave
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.
serious
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.
important
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.
normal
the default value, applicable to most bugs.
minor
a problem which doesn't affect the package's usefulness, and is
presumably trivial to fix.
wishlist
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.
END QUOTE.
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
this.)
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: