On Tue, Oct 03, 2000 at 10:24:12AM -0700, Sean 'Shaleh' Perry wrote:
> I find this to be problematic. Numerous bugs were downgraded because we did
> not want a package to hold up release.
Look, there are two questions here, they're both fairly straightforward:
1) "important", "grave" and "critical" bugs generally ensure a
package will *not* be released. What, exactly, are the sorts of
bugs that should come under these categories? What, exactly, makes
a package unsuitable for release?
2) How can we better categorise bugs so maintainers can manage them,
and -qa people can find useful things to do?
Blithely abusing the "important" severity to answer question two is *not*
particularly good for either organising bugs *or* for release management.
Using the "important" severity for bugs that aren't important enough to get
the package dropped is not the way to go.
> So here is yet another "maybe we need a neew ..." and say that perhaps a bug
> should be marked "release critical" independant of its current severity. Or
> perhaps only grave is release critical and we up/downgrade bugs from there.
No. If anything we need a more fine grained method of organising bugs
so they can be fixed. Randomly adding severities isn't the way to go
about this.
Cheers,
aj, proving things by bald assertion since 1978
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpprBtQeXPp0.pgp
Description: PGP signature