3.t

早期freebsd实现

.\" Copyright (c) 1989 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)3.t	5.1 (Berkeley) 4/17/91
.\"
.NH
System Release
.PP
Once the decision has been made to halt development
and begin release engineering,
all currently unfinished projects are evaluated.
This evaluation involves computing the time required to complete
the project as opposed to how important the project is to the
upcoming release.
Projects that are not selected for completion are
removed from the distribution branch of the source code control system
and saved on branch deltas so they can be retrieved,
completed, and merged into a future release;
the remaining unfinished projects are brought to orderly completion.
.PP
Developments from
.SM CSRG
are released in three steps: alpha, beta, and final.
Alpha and beta releases are not true distributions\(emthey
are test systems.
Alpha releases are normally available to only a few sites,
usually those working closely with
.SM CSRG .
More sites are given beta releases,
as the system is closer to completion,
and needs wider testing to find more obscure problems.
For example, \*(b3 alpha was distributed to about fifteen
sites, while \*(b3 beta ran at more than a hundred.
.NH 2
Alpha Distribution Development
.PP
The first step in creating an alpha distribution is to evaluate the
existing state of the system and to decide what software should be
included in the release.
This decision process includes not only deciding what software should
be added, but also what obsolete software ought to be retired from the
distribution.
The new software includes the successful projects that have been
completed at
.SM CSRG
and elsewhere, as well as some portion of the vast quantity of
contributed software that has been offered during the development
period.
.PP
Once an initial list has been created,
a prototype filesystem corresponding to the distribution
is constructed, typically named
.PN /nbsd .
This prototype will eventually turn into the master source tree for the
final distribution.
During the period that the alpha distribution is being created,
.PN /nbsd
is mounted read-write, and is highly fluid.
Programs are created and deleted,
old versions of programs are completely replaced,
and the correspondence between the sources and binaries
is only loosely tracked.
People outside
.SM CSRG
who are helping with the distribution are free to
change their parts of the distribution at will.
.PP
During this period the newly forming distribution is
checked for interoperability.
For example,
in \*(b3 the output of context differences from
.PN diff
was changed to merge overlapping sections.
Unfortunately, this change broke the
.PN patch
program which could no longer interpret the output of
.PN diff .
Since the change to
.PN diff
and the
.PN patch
program had originated outside Berkeley,
.SM CSRG
had to coordinate the efforts of the respective authors
to make the programs work together harmoniously.
.PP
Once the sources have stabilized,
an attempt is made to compile the entire source tree.
Often this exposes errors caused by changed header files,
or use of obsoleted C library interfaces.
If the incompatibilities affect too many programs,
or require excessive amounts of change in the programs
that are affected,
the incompatibility is backed out or some backward-compatible
interface is provided.
The incompatibilities that are found and left in are noted
in a list that is later incorporated into the release notes.
Thus, users upgrading to the new system can anticipate problems
in their own software that will require change.
.PP
Once the source tree compiles completely,
it is installed and becomes the running system that
.SM CSRG
uses on its main development machine.
Once in day-to-day use,
other interoperability problems become apparent
and are resolved.
When all known problems have been resolved, and the system has been
stable for some period of time, an alpha distribution tape is made
from the contents of
.PN /nbsd .
.PP
The alpha distribution is sent out to a small set of test sites.
These test sites are selected as having a
sophisticated user population, not only capable of finding bugs,
but also of determining their cause and developing a fix for the problem.
These sites are usually composed of groups that are contributing
software to the distribution or groups that have a particular expertise
with some portion of the system.
.NH 2
Beta Distribution Development
.PP
After the alpha tape is created,
the distribution filesystem is mounted read-only.
Further changes are requested in a change log rather than
being made directly to the distribution.
The change requests are inspected and implemented by a
.SM CSRG
staff person, followed by a compilation of the affected
programs to ensure that they still build correctly.
Once the alpha tape has been cut,
changes to the distribution are no longer made by people outside
.SM CSRG .
.PP
As the alpha sites install and begin running the alpha distribution,
they monitor the problems that they encounter.
For minor bugs, they typically report back the bug along with
a suggested fix.
Since many of the alpha sites are selected from among the people
working closely with
.SM CSRG ,
they often have accounts on, and access to, the primary
.SM CSRG
development machine.
Thus, they are able to directly install the fix themselves,
and simply notify
.SM CSRG
when they have fixed the problem.
After verifying the fix, the affected files are added to
the list to be updated on
.PN /nbsd .
.PP
The more important task of the alpha sites is to test out the
new facilities that have been added to the system.
The alpha sites often find major design flaws
or operational shortcomings of the facilities.
When such problems are found,
the person in charge of that facility is responsible
for resolving the problem.
Occasionally this requires redesigning and reimplementing
parts of the affected facility.
For example,
in 4.2\s-1BSD\s+1,
the alpha release of the networking system did not have connection queueing.
This shortcoming prevented the network from handling many
connections to a single server.
The result was that the networking interface had to be
redesigned to provide this functionality.