Date: Mon, 25 Aug 1997 23:16:41 -0600 (MDT) From: Wes Peters <softweyr@xmission.com> To: rdkeys@csemail.cropsci.ncsu.edu Cc: questions@freebsd.org Subject: Re: 2.2-STABLE Message-ID: <199708260516.XAA22495@obie.softweyr.ml.org> In-Reply-To: <9708251522.AA128968@csemail.cropsci.ncsu.edu> References: <19970825195938.31646@lemis.com> <9708251522.AA128968@csemail.cropsci.ncsu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
rdkeys@csemail.cropsci.ncsu.edu writes:
> Not to pick at nits.... but, I am still confused as to what EXACTLY
> is the ``stable'' FreeBSD. Please enlighten me, and tell me the
> reasoning behind it.
>
> I read all the various manuals, faq's, .txt's and everything else
> that I can find, but it still is not clear.
>
> That will help clarify the waters for me, and I am sure others,
> tremendously.
OK, I'll take a shot at this. To really understand what 2.2-STABLE is,
you have to have some idea of how the FreeBSD team uses 'branches'. In
particular, we are talking about branches as implemented by the CVS
source code control system, but other SCCS are similar.
Most FreeBSD development is done along a main line of code known as
CURRENT. You will often see this with the revision of the next major
release of software, for instance 3.0-CURRENT which we have now. This
is the development tree that gets improvements to basic kernel
functions, new network protocols, etc. added to it; it is where most of
the developers spend their time.
When a release of the software is being prepared, a branch off this main
code line is created. This allows 'release engineers' who are bringing
the code up to release quality to make changes to the release without
bugging (or debugging, as the case may be) new development on the main
branch. For instance, the 2.2-RELENG tree was created late last year to
produce 2.2-RELEASE; it's code has diverged from the 3.0-CURRENT tree
since then.
At some point, many of the bug fixes performed on a release branch are
brought back to the mainline code, if the code the bug was in hasn't
been replaced.
Now, back on our release tree, the release usually goes through several
minor revisions, getting better and more reliable. Again, these changes
usually find their way back to the -CURRENT line, but not as quickly.
One a release goes "out the door", it is quickly exposed to a much wider
user base, using different hardware, and quite often much higher loads
than members of the development team impose on their systems. Some of
us even have older, slower hardware than the core team. ;^) (This
message is being chiseled into the electrons on a 486/66, for instance.)
Since this wider user base usually kicks up a bunch of bugs the core
team and the release team did not find, these bugs get reported, fixed,
and new minor releases generated *on the release branch.* This, on the
2.2-RELENG branch we have 2.2.1, 2.2.2, etc. The 2.2 release team is
now working on 2.2.5.
Somewhere along the way, the 2.2 branch finally becomes (nearly) as
stable as the old 2.1 branch was. At this time, "production" FreeBSD
users like ISPs begin moving from 2.1-STABLE to 2.2-STABLE. When a
FreeBSD branch goes to -STABLE, it is usuall a sign that the code has
truly reached production levels of reliability; in my experience, it
matches and even exceeds the reliability of good commercial UNIX systems
such as Solaris and HP-UX. Not to mention far exceeds most, including
just about everything else on the PC architecture.
(Yes, this is a mild slam directed at Linux, the various SVR4 PC
platforms, and especially SCO.)
The -STABLE branch appears at the maturation point of a particular
FreeBSD release and is carefully bug-fixed and security-fixed to greater
and greater levels of stability. It can sometimes lag slightly behind
releases on the related development branch or keep right up with them;
the -STABLE team is driven quite a bit by the efforts of people who use
FreeBSD in a production environment. They are, by nature, a pretty
conservative lot.
So, at the current time, we still have a -STABLE release based on
2.1.7.1, which has been carefully nurtured for nearly a year and half
now into a close to rock-solid reliability at the STABLE team can make
it. We also have a 2.2-STABLE release, based on post-2.2.2 code, which
is approaching this level of reliability and features the performance
and system administration pluses found in the 2.2 release. We have the
impending 2.2.5 release, and this will affect the 2.2-STABLE release at
some time, to be decided by the -STABLE team.
That's the nice thing about FreeBSD: you make the choice which is most
appropriate for you. Hopefully now you have enough information to make
a good decision.
> Also, if it would be of merit, why not snapshot the handbook so it is
> current with the current development of FBSD? In my interpretation,
> and from what everyone says ``RTFHBK'', then I should consider it the
> ``bible'' of FreeBSD (actually it is the best reference to point to
> over the FAQ/.txt's, etc, from my experiences), it needs to be kept
> up to date like the sources. Thus, a daily snapshot might be of use.
> The May 19th date for the current handbook seems a little dated if
> anything other than 2.1.7.1 is the ``stable'' FreeBSD.
Good idea. If y'all will be so kind as to CC me on the inevitable
corrections to my description above, I will gladly resubmit it to this
group for approval when the comments trickle off and we can then stick
it into the appropriate section of the handbook. If my writing is too
stilted, I can *probably* get my wife to edit it; she just happens to be
a talented technical writer. ;^)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.xmission.com/~softweyr softweyr@xmission.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708260516.XAA22495>