Re: Bug mass filling
* Mike Hommey (mh@glandium.org) [061019 20:42]:
> Note how subtly the Etch RC policy removes the first alternative of the
> serious bug description...
Which do you mean? Please read the Etch RC policy. It tells:
| In addition to the issues listed in this document, an issue is release
| critical if it:
| [...]
| * in the maintainer's opinion, makes the package unsuitable
| for release
So, what does the Etch RC policy remove from the bugs.d.o description?
> Anyways, I've always thought the bts severity levels and release
> criticality were orthogonal things. i.e. it's more complicated than
> just saying "critical, grave and serious levels are RC".
That is wrong.
> There are
> important or even normal issues (as per definition of the severity
> levels) that are more release critical than serious (again, as per
> definition of the severity levels) bugs.
Wrong. A bug is release-critical :<=> the bug has severity serious,
grave, critical and has not been given an excemption by the release team
> But yet, violation of the Debian policy should be granted serious level.
> etch-ignore is here to make the issue not release critical.
Wrong. Etch-ignore is for exemptions for issues that otherwise match the
definition of release critical on that page. It is not for "normal
sorting" of issues.
A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
should be the same as the must-directives in policy, but - well, I hope
that I have finally time post-etch to sync that finally).
Any other policy violation is at most important level (unless it
conincides with one of the other criteria for RC bugs, of course).
Cheers,
Andi
Debian Release Manager
--
http://home.arcor.de/andreas-barth/
Reply to: