Release-critical bugs, and #97671
Branden Robinson writes ("Re: Processed: yawn"):
> reassign 97671 tech-ctte,xutils
> Anthony has offered no basis for his latest manipulation of my bug list
> aside from the derisive remark in the Subject:.
> I am requesting the Technical Committee's resolution of this dispute
> under Section 6.1 of the Constitution. Both parties stipulate that the
> bug in question is not release critical. Therefore, this bug does not
> fall within the Release Manager's jurisdiction, and I am not aware of
> any other grounds upon which the package maintainer's discretion can be
> overridden on issues like this.
Can you explain what you think the technical dispute is between you
and Anthony, if any ? It seems to me that you're disagreeing about
process. As you know, if you're disagreeing about process, the
Technical Committee's involvement is limited to stating its
non-binding opinion - not that we would necessarily avoid that :-).
Looking at the situation, I think that the definition of `serious' bug
report is rather unhelpful and does not match up with the use of
`must' or `required' in policy. The idea in the BTS seems to be that
a serious bug is one which makes a package unsuitable for release.
But, the idea in the policy manual is that a `must' is a rule for
which there are not expected to be exceptions; it doesn't touch on how
damaging a breach of the rule is.
Part of the dispute seems to stem from this discrepancy. The bug in
question is agreed by everyone to be a violation of a `must' in
policy, but not to make the package unsuitable for release. If our
processes make it difficult to reconcile this then they should be
How about if we change the wording in `Severity levels' in the BTS
Currently it says:
is a severe violation of Debian policy (that is, it violates a
"must" or "required" directive), or, in the package
maintainer's opinion, makes the package unsuitable for
is a severe violation of Debian policy or any other problem,
which makes the package unsuitable for release.
This definition makes `serious' correspond identically to the
package's suitability for release. It avoids defining `severe'
violation of policy as a violation of a `must'; that seems to me to be
the core error. This change would avoid violations of exceptionless
policies (which are of course always bugs) always being treated as
release critical even if they're unimportant.
If you and Anthony agree then maybe we should see if we can get that
changed. If you disagree I'm sure you'll let us know :-).
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org