On Thu, Dec 17, 1998 at 12:11:40PM -0800, Oscar Levi wrote:
<snip>
> Not necessarily true. A crash bug that affects 1 out of 10000 runs of
> a program is not release critical. A security hole, in of itself, is
> not a release critical bug. I ship shrink-wrapped software for a
> living--part of a living. All software has bugs. I ship on using
> concrete criteria and I ship software with known bugs when the cost of
> fixing it is greater than the value.
I would direct you to the developers' info on our web page, at
http://www.debian.org/Bugs/Developer.html#severities..
Specificly
The severity levels are:
critical
makes unrelated software on the system (or the whole system)
break, or causes serious data loss, or INTRODUCES A SECURITY
HOLE ON SYSTEMS WHERE YOU INSTALL THE PACKAGE.
Release critical bugs are defined as bugs with severity important or
higher, there is no higher severity bug then critical..
End of argument, if you have a problem with this then take it up on
debian-policy...
> We don't have guidelines for release that we can use to decide if this
> is important or not. In your opinion, is it worth a three-week delay
> to switch kernels? I am not saying it would take that long. I am
> saying that a change like the kernel deserves extensive testing which
> we are not now doing. I'd rather ship a kernel with alleged security
> holes than a broken distribution.
We do have guidelines for release, granted its spread out, but on almost
everything its covered on our web site..
(Yes, I really should come up with a URL or three but I'm quite tired at
the moment)
<snip>
--
PGP EA5198D1-Zephaniah E, Hull <warp@whitestar.soark.net>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
CCs of replies from mailing lists are encouraged.
Attachment:
pgpvUoVAXjRyP.pgp
Description: PGP signature