Re: Linux 2.0.36 in slink?
On Thu, Dec 17, 1998 at 07:07:31PM -0500, Zephaniah E, Hull wrote:
> 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...
This kind of dogma is neither necessary, nor dignified.
I'm aware of the publications. It doesn't alter the fact that
absolutes make sophomoric criteria. Just because there is a potential
for a crash or data loss doesn't mean it makes sense to hold up a
release. It is a cost/value proposition where each side must be
weighed. The real issue here is not whether we should put the newer
kernel in. I personal think there are sufficient problems with 2.0.35
to upgrade (or downgrade). Yet, we can't make an intelligent claim
about the cost of upgrading because we have no testing infrastructure.
> 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)
I've been over this a couple of times. Parameters for release are not
"when person X says it's ok", or "when the bugs of certain classes are
resolved." Without testing and especially regression testing, we
cannot make any claim that slink is ready to ship. Heck, the last two
sets of install disks haven't worked. What we do have are some good
ideas about that a releasable distribution looks like.
Reply to: