3.t

早期freebsd实现

.PP
The alpha sites are also responsible for ferreting out interoperability
problems between different utilities.
The user populations of the test sites differ from the user population at
.SM CSRG ,
and, as a result, the utilities are exercised in ways that differ
from the ways that they are used at
.SM CSRG .
These differences in usage patterns turn up problems that
do not occur in our initial test environment.
.PP
The alpha sites frequently redistribute the alpha tape to several
of their own alpha sites that are particularly interested
in parts of the new system.
These additional sites are responsible for reporting
problems back to the site from which they received the distribution,
not to
.SM CSRG .
Often these redistribution sites are less sophisticated than the
direct alpha sites, so their reports need to be filtered
to avoid spurious, or site dependent, bug reports.
The direct alpha sites sift through the reports to find those that
are relevant, and usually verify the suggested fix if one is given,
or develop a fix if none is provided.
This hierarchical testing process forces
bug reports, fixes, and new software
to be collected, evaluated, and checked for inaccuracies
by first-level sites before being forwarded to
.SM CSRG ,
allowing the developers at
.SM CSRG
to concentrate on tracking the changes being made to the system
rather than sifting through information (often voluminous) from every
alpha-test site.
.PP
Once the major problems have been attended to,
the focus turns to getting the documentation synchronized
with the code that is being shipped.
The manual pages need to be checked to be sure that
they accurately reflect any changes to the programs that
they describe.
Usually the manual pages are kept up to date as
the program they describe evolves.
However, the supporting documents frequently do not get changed,
and must be edited to bring them up to date.
During this review, the need for other documents becomes evident.
For example, it was
during this phase of \*(b3 that it was decided
to add a tutorial document on how to use the socket
interprocess communication primitives.
.PP
Another task during this period is to contact the people that
have contributed complete software packages
(such as
.PN RCS
or
.PN MH )
in previous releases to see if they wish to
make any revisions to their software.
For those who do,
the new software has to be obtained,
and tested to verify that it compiles and runs
correctly on the system to be released.
Again, this integration and testing can often be done by the
contributors themselves by logging directly into the master machine.
.PP
After the stream of bug reports has slowed down
to a reasonable level,
.SM CSRG
begins a careful review of all the changes to the
system since the previous release.
The review is done by running a recursive
.PN diff
of the entire source tree\(emhere, of
.PN /nbsd
with 4.2\s-1BSD\s+1.
All the changes are checked to ensure that they are reasonable,
and have been properly documented.
The process often turns up questionable changes.
When such a questionable change is found,
the source code control system log is examined to find
out who made the change and what their explanation was
for the change.
If the log does not resolve the problem,
the person responsible for the change is asked for an explanation
of what they were trying to accomplish.
If the reason is not compelling,
the change is backed out.
Facilities deemed inappropriate in \*(b3 included new options to
the directory-listing command and a changed return value for the
.RN fseek
library routine;
the changes were removed from the source before final distribution.
Although this process is long and tedious,
it forces the developers to obtain a coherent picture of the entire set of
changes to the system.
This exercise often turns up inconsistencies that would
otherwise never be found.
.PP
The outcome of the comparison results in
a pair of documents detailing
changes to every user-level command
.[
Bug Fixes and Changes
.]
and to every kernel source file.
.[
Changes to the Kernel
.]
These documents are delivered with the final distribution.
A user can look up any command by name and see immediately
what has changed,
and a developer can similarly look up any kernel
file by name and get a summary of the changes to that file.
.PP
Having completed the review of the entire system,
the preparation of the beta distribution is started.
Unlike the alpha distribution, where pieces of the system
may be unfinished and the documentation incomplete,
the beta distribution is put together as if it were
going to be the final distribution.
All known problems are fixed, and any remaining development
is completed.
Once the beta tape has been prepared,
no further changes are permitted to
.PN /nbsd
without careful review,
as spurious changes made after the system has been
.PN diff ed
are unlikely to be caught.
.NH 2
Final Distribution Development
.PP
The beta distribution goes to more sites than the
alpha distribution for three main reasons.
First, as it is closer to the final release, more sites are willing
to run it in a production environment without fear of catastrophic failures.
Second, more commercial sites delivering
.SM BSD -\c
derived systems are interested in getting a preview of the
upcoming changes in preparation for merging them into their
own systems.
Finally, because the beta tape has fewer problems,
it is beneficial to offer it to more sites in hopes of
finding as many of the remaining problems as possible.
Also, by handing the system out to less sophisticated sites,
issues that would be ignored by the users of the alpha sites
become apparent.
.PP
The anticipation is that the beta tape will not require
extensive changes to either the programs or the documentation.
Most of the work involves sifting through the reported bugs
to find those that are relevant and devising the minimal
reasonable set of changes to fix them.
After throughly testing the fix, it is listed in the update log for
.PN /nbsd .
One person at
.SM CSRG
is responsible for doing the update of
.PN /nbsd
and ensuring that everything affected by the change is rebuilt and tested.
Thus, a change to a C library routine requires that the entire
system be rebuilt.
.PP
During this period, the documentation is all printed and proofread.
As minor changes are made to the manual pages and documentation,
the affected pages must be reprinted.
.PP
The final step in the release process is to check the distribution tree
to ensure that it is in a consistent state.
This step includes verification that every file and directory
on the distribution has the proper owner, group, and modes.
All source files must be checked to be sure that they have
appropriate copyright notices and source code control system headers.
Any extraneous files must be removed.
Finally, the installed binaries must be checked to ensure that they correspond
exactly to the sources and libraries that are on the distribution.
.PP
This checking is a formidable task given that there are over 20,000 files on
a typical distribution.
Much of the checking can be done by a set of programs set to scan
over the distribution tree.
Unfortunately, the exception list is long, and requires
hours of tedious hand checking; this has caused
.SM CSRG
to develop even
more comprehensive validation programs for use in our next release.
.PP
Once the final set of checks has been run,
the master tape can be made, and the official distribution started.
As for the staff of
.SM CSRG ,
we usually take a brief vacation before plunging back into
a new development phase.