Re: Release-critical bugs, and #97671
>>"Ian" == Ian Jackson <firstname.lastname@example.org> writes:
Ian> Looking at the situation, I think that the definition of
Ian> `serious' bug report is rather unhelpful and does not match up
Ian> with the use of `must' or `required' in policy.
What makes you say that? Serious is defined as a violation of
a must or required directive of policy; I fail to see how this could
not match up with the use of `must' or `required' in policy; they are
identical ways of saying the same thing.
Ian> The idea in the BTS seems to be that a serious bug is one which
Ian> makes a package unsuitable for release.
This is where the disconnect is. The release manager decides
what is or is not fit for release. The general guideline is that a
violation of a must directive in policy is likely to be cause for the
release manager to reject the package. The final decision lies with
the release manager.
Ian> How about if we change the wording in `Severity levels' in the BTS
Ian> documentation (http://www.debian.org/Bugs/Developer#severities).
Ian> Currently it says:
Ian> is a severe violation of Debian policy (that is, it violates a
Ian> "must" or "required" directive), or, in the package
Ian> maintainer's opinion, makes the package unsuitable for
Ian> How about:
Ian> is a severe violation of Debian policy or any other problem,
Ian> which makes the package unsuitable for release.
This is bogus. You have changed a stright forward, objective
criteria for a serious bug, softening it to where it has no meaning.
The output of your program makes my nose twitch, this is
obviously a problem, and this bug is thus critical.
Ian> This definition makes `serious' correspond identically to the
Ian> package's suitability for release. It avoids defining `severe'
Ian> violation of policy as a violation of a `must'; that seems to me to be
Ian> the core error. This change would avoid violations of exceptionless
Ian> policies (which are of course always bugs) always being treated as
Ian> release critical even if they're unimportant.
No, the core error is that you are taking away from the
release manager the task and responsibility of determining release
criteria. Did you ignore everything that I and aj wrote? Would you
please catch up instead of jumping in late, and ignoring the advances
and arguments already made?
The core error is that bug severities should not be rigidly
connected to release criticalness. *THAT* is the place where we need
to make case by case, subjective decisions
Ian> If you and Anthony agree then maybe we should see if we can get that
Ian> changed. If you disagree I'm sure you'll let us know :-).
I strongly object to turning the criteria upside down and
creating a situation where bug severities are even more
subjective. This is a far worse situation than we find ourselves in
A lady with one of her ears applied To an open keyhole heard, inside,
Two female gossips in converse free -- The subject engaging them was
she. "I think", said one, "and my husband thinks That she's a prying,
inquisitive minx!" As soon as no more of it she could hear The lady,
indignant, removed her ear. "I will not stay," she said with a pout,
"To hear my character lied about!" Gopete Sherany
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com