Date: Wed, 12 Jul 2000 23:04:04 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Francisco Reyes <fran@reyes.somos.net> Cc: FreeBSd Chat list <chat@freebsd.org> Subject: Re: Is Stable really stable? Message-ID: <Pine.BSF.4.21.0007122247470.74613-100000@freefall.freebsd.org> In-Reply-To: <200007130542.BAA36692@vulcan.addy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 Jul 2000, Francisco Reyes wrote:
> The recent changes in the way of making new kernels plus the
Repeat after me: it's not a recent change - people just didn't get the
message until it was rammed down their throats recently.
There is a certain minimal investment required to aggressively track
-stable, namely the willingness to keep up with the mailing list, to read
what others write when they describe upgrade pitfalls and temporary
breakage after code changes, and to read the UPDATING file (which, by
definition, usually lags a few days behind the leading edge because we
can't predict all problems in advance).
Frankly, stable is a lot easier to manage if you don't try and upgrade to
the bleeding edge all the time, but gauge mailing list traffic for trouble
spots, and upgrade every so often to a "safe" date once troubles have died
down (e.g. you can use cvsup to update to specific dates, not just the
very latest in the tree). For example, I think you'll agree that picking a
date to upgrade when the mailing list is full of people crying "My stable
is broken! My stable is broken!" would be a pretty silly thing to do. And
of course, you don't blindly upgrade all of your machines at once, do you?
If you're not willing or able to put in the time to manage source-code
-stable upgrades coherently, then stick to discrete -RELEASE upgrades, or
binary snapshots.
With the 4.0 branch, developers are making a lot more of an effort to
ensure that 4.0 doesn't severely diverge from -current. This was a major
criticism of the 3.x branch, which soon lagged so far behind what was then
4.0-CURRENT that bugfixing became impossible, and the entire 3.x branch
suffered as a result.
On the one hand, you can have a -stable branch which becomes stagnant and
for which merging bugfixes becomes impossible, on the other hand you can
have a -stable branch which is actively maintained and developed, at the
expense of occasional merge fallout. And before you suggest it, no,
FreeBSD does not have the developer resources to maintain a third
development track.
If you're upset with -stable, I put it to you that you have the wrong
expectations from it, and are trying to use it in inappropriate ways for
your situation.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007122247470.74613-100000>