upgrading

Nick Barnes Nick.Barnes at pobox.com
Mon Sep 22 08:13:30 PDT 2003


At 2003-09-22 14:27:25+0000, Bill Woods writes:

> While I tend to agree with you on the steps you outline, there
> should NOT be a firestorm on stable, things should be fairly well
> tested BEFORE being commited to stable. Maby its time to revisit the
> branch naming scheme, considering the name "stable" carries with it
> certian implications.

I am generally in agreement, but the only way to flush out some bugs
seems to be to MFC the code to -STABLE.  The project clearly doesn't
have the resources to test every configuration, and few people are
prepared to run -CURRENT (I know I'm not).  The recent PAE problems
are not typical.  There's always a spectrum between getting the latest
code (new functionality, support for recent hardware, etc) and total
stability.  FreeBSD provides easy ways to select points on that
spectrum:

1. If you want the bleeding edge, run -CURRENT.

2. If you want code which has survived on -CURRENT, has been tested
fairly well, appears fine in general use, but might break under high
stress or in unusual configurations, run -STABLE.

3. If you want to do a little better than that, run -STABLE and pick
your cvsup times with care.

4. If you want code which you can really rely on, run x.y-RELENG.

5. If you want code which doesn't change, run x.y-RELEASE.

6. You can always stick to 2.2.8....

For the record, I've maintained machines at various different points
on this spectrum for some years now (I upgraded our last 2.2.x machine
to 4.x a while back), and have never experienced significant flakiness
(even with -CURRENT).  At present, my main externally-visible servers
run 4.7-RELENG and 4.8-RELENG, my internal servers run 4.8-RELEASE,
and my desktop runs -STABLE.  When a new -RELEASE comes out, I try it
out before deploying it internally, and usually wait a few weeks after
that before pushing it onto the external servers.

Nick B


More information about the freebsd-stable mailing list