BTS improvements (was: Re: 88 Priority violations in woody
On Tue, Apr 30, 2002 at 07:52:27AM +0200, Wichert Akkerman wrote:
> As the woody release comes closer you can expect a different between
> bugs with a severity of serious or higher and bugs that really are
> severe enough to be deemed release critical. In this case those bugs
> are a policy violation, but they are not something a user will ever
> notice which does not make them release critical.
Still, they are proper bugs and the severity serious is correct.
It bothers me that the severity of a bug can not be maintained during the
release process. Bug severities are downgraded to make the release happen,
and then upgraded afterwards (for example, this happens with architecture
specific bugs, depending on if the architecture is released or not).
There is room for improvement here. For one, an architecture tag on the
bugs could allow for severity serious and higher bugs on an unreleased
architecture without affecting the release.
For the type of thing in this thread, a special tag "not-release-critical"
could signal that despite the severity serious or higher, this is not
considered to be release critical.
My point is that a bug is a bug, and the severity is still defined in an
abstract way, independent of the release (at least in the documentation of
the BTS), and not only from the point of view of the release manager.
Instead struggling with each other we could just improve the meta-data
capabilities of the BTS to allow a better organization of the bugs.
This is one area were we are personally fighting a lot, although there are
very simple technical improvements possible that make it possible that
everybody gets his way and stays out of the way of everybody else.
`Rhubarb is no Egyptian god.' Debian http://www.debian.org email@example.com
Marcus Brinkmann GNU http://www.gnu.org firstname.lastname@example.org
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org