Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Nov 2002 13:51:29 -0500
From:      Bob Johnson <bob@eng.ufl.edu>
To:        Jonathan Chen <jonc@chen.org.nz>
Cc:        Mike Hoskins <mike@adept.org>, "Sameer R. Manek" <manek@ecst.csuchico.edu>, freebsd-stable@FreeBSD.ORG, re@FreeBSD.ORG
Subject:   Re: restoring definition of -stable
Message-ID:  <3DDA8831.D80CBA7F@eng.ufl.edu>
References:  <LMEMIKHGPPEEMMMMGIENOEHCFAAA.manek@ecst.csuchico.edu> <20021118150756.W33033-100000@fubar.adept.org> <20021118233258.GA80653@grimoire.chen.org.nz>

next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Chen wrote:
> 
> On Mon, Nov 18, 2002 at 03:12:25PM -0800, Mike Hoskins wrote:
> > On Mon, 18 Nov 2002, Sameer R. Manek wrote:
> 
> [..]
> > > The definition of what is -stable has been relaxed in the past 2 years. If
> > > you look at the handbook from 2 years ago, you will see this is what they
> > > define it as.
> >
> > Not surprisingly, I find a lot of changes in the past two years.  The
> > handbook is a living document, it will change.  The current definitions
> > explain how FreeBSD works now.  If you don't like how it works, it's much
> > more effective to volunteer and effect change from the inside out than it
> > is to point fingers and make empty suggestions.  If you are not qualified
> > to help, then it is also unlikely you understand all the issues pertaining
> > to your request.
> 
[...]
> What we don't have is buy-in from -core; and the only way that will
> happen is if enough people voice their concern. It's hard to work from
> the inside if you're on the outside, and no one's asking you in.
> 

I don't think this requires more from -core than a desire to try to 
stabilize -stable after 5.0-RELEASE.  My understanding is that right now 
an MFC often requires a lot of patching to account for the divergent 
code bases, and in some cases new code can't be tested on -current at all.  
Being able to test things on -current and then move them to -stable with 
minimal patching would put us back where we were when -stable was 
considered "stable".

Now, I understand that -stable was never 100% "stable", but making it so 
was at least a target that was aimed for.  There is some validity to the 
view that a production system shouldn't be trying to keep up with all of 
the bells and whistles that show up in the latest version of -stable, but 
at the same time, it would be nice to have some confidence that I can do 
an upgrade without breaking something.  I haven't managed to do that for 
a few months now (maybe I'm just unlucky).  

For production servers I use the RELENG_4_x (a.k.a. "secure") branch, and 
I'm quite happy with it.  It keeps my servers on line with minimal risk of 
breaking something.  But for personal workstations that aren't quite so 
critical, it's nice to be able to upgrade them regularly and keep up with 
the new features without planning to spend a day figuring out what broke.  


In summary:

- It seems likely (to me) that the release of 5.0-R will automatically 
solve some of the stability problems on -stable if that is a goal of the 
committers.

- It seems reasonable to me to tell people that -stable is stable enough 
for a typical workstation (where only one person stops working when it 
stops), but shouldn't be used on production servers that will affect many 
people if they break.

- It seems reasonable to me to tell people that production servers ought 
to be using the "secure" codebase rather than the "stable" codebase.  
Leave the bells and whistles to systems that aren't so critical.

- There may be room for redefinition of what constitutes a "critical" patch, 
but it is a very narrow issue compared to "the stability of -stable".  
Should a patch to the VM system that substantially improves the performance 
of a heavily loaded server be considered "critical"?  I don't know, but if 
I follow my argument to its conclusion, I find myself saying "yes" (to my 
surprise).  Since I'm claiming that production systems should stick with 
the "secure" branch, and that is arguably the primary "market" for that 
branch, I guess I should also claim that their performance should be 
considered significant when deciding what goes into that branch.  If 
maximum stability is considered essential, however, then the answer is "no".

- Bob

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?3DDA8831.D80CBA7F>