Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Nov 1999 13:32:42 -0800
From:      Doug Barton <DougB@simplenet.com>
To:        Colin <cwass99@home.com>
Cc:        "Forrest W. Christian" <forrestc@iMach.com>, Stable@freebsd.org
Subject:   Re: Bug-fixing previous -RELEASE
Message-ID:  <38404DFA.16DE72C3@simplenet.com>
References:  <Pine.BSF.3.96.991125202746.24187B-100000@workhorse.iMach.com> <3840165D.CAF495E9@home.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Colin wrote:

>      My intent was actually a little different from the responses that
> are elswhere in this list. . .   

>      For systems where stability is the overriding concern, you never
> want to apply patches/fixes only because they are available.  Only fix
> problems that actually have an impact i.e. if SSH is broken, but you
> don't use it, don't worry about fixing it.  There's always a risk that
> code that fixes one problem will break something else, usually something
> important ;)

	I think your points here are well taken, however because of FreeBSD's
"whole system" development model, it's actually more likely that
introducing individual fixes to part of the system will break something
than the other way around. (At least in my opinion, I know that there is a
significant minority that hold a different view.) This is not to say that
we wouldn't welcome a system like what you propose, and in fact many have
been hashed out over the years. You can see the details in the mail
archives. However, what it always boils down to is that no one has the
right combination of time, equipment and willingness to do the regression
testing necessary to make such a system work. 

	The model I've used is to monitor the lists carefully and when I see a new
thing that I want (be it bug fix, performance enhancement, what have you) I
plan an upgrade for that time period. First I upgrade my workstation(s),
then a least-critical system, then eventually the whole enchilada. Of
course, I've got lots of freebsd systems in various flavors to work with,
but you could do the same thing by setting up a system as a hot spare, and
really, if the system is _that_ critical shouldn't you have a hot spare
anyway? :)

	I realize this isn't the answer you were hoping for, but hopefully knowing
that it is at least something we've given thought to is of some comfort to
you... 

Good luck,

Doug
-- 
"Welcome to the desert of the real." 

    - Laurence Fishburne as Morpheus, "The Matrix"


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38404DFA.16DE72C3>