os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Correct a grammo.

Browse source 
Remove whitespace at EOL while I'm here.
No content changes; translators please ignore.
This commit is contained in:
Jens Schweikhardt 2004-01-12 07:10:21 +00:00
parent c327f4f8e2
commit a18a572ce0
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=19604
1 changed files with 133 additions and 133 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

266
en_US.ISO8859-1/articles/releng/article.sgml
View file

@ -69,7 +69,7 @@
</abstract>
</articleinfo>
<!-- Introduction -->
<sect1 id="introduction">
<title>Introduction</title>
@ -90,7 +90,7 @@
FreeBSD development. An elected <emphasis>core-team[7]</emphasis>
of very senior developers provides some level of direction over
the project.</para>
<para>The rapid pace of <systemitem
class="osname">FreeBSD</systemitem> development leaves little time
for polishing the development system into a production quality
@ -99,7 +99,7 @@
<emphasis>HEAD</emphasis> or <emphasis>trunk</emphasis> of our CVS
tree, known as <quote>FreeBSD-CURRENT</quote> or
<quote>-CURRENT</quote> for short.</para>
<para>A more stable branch is maintained, known as
<quote>FreeBSD-STABLE</quote> or <quote>-STABLE</quote> for short.
Both branches live in a master CVS repository in California and
@ -112,7 +112,7 @@
with general assumption that they have first gone into
FreeBSD-CURRENT and have been thoroughly tested by our user
community.</para>
<para>In the interim period between releases, nightly snapshots are
built automatically by the FreeBSD Project build machines and made
available for download from <systemitem
@ -124,7 +124,7 @@
FreeBSD-STABLE in a very reliable condition even before the
quality assurance activities ramp up pending a major
release.</para>
<para>Bug reports and feature requests are continuously submitted by
users throughout the release cycle. Problems reports are entered into our
<application class="software">GNATS</application>[9] database
@ -134,7 +134,7 @@
In addition to the multitude of different technical mailing lists
about FreeBSD, the &a.qa; provides a forum for discussing the finer
points of <quote>release-polishing</quote>.</para>
<para>To service our most conservative users, individual release
branches were introduced with FreeBSD 4.3.
These release branches are created shortly before a final release
@ -144,7 +144,7 @@
available to keep systems on the
<emphasis>RELENG_<replaceable>X</replaceable>_<replaceable>Y</replaceable></emphasis>
branches updated.</para>
<para><xref linkend="release-proc"> discusses the
different phases of the release engineering process leading up to
the actual system build and <xref linkend="release-build">
@ -172,7 +172,7 @@
From CURRENT</quote> and it describes the process of merging a
tested change from our -CURRENT development branch to our -STABLE
branch.</para>
<sect2>
<title>Code Review</title>
@ -181,31 +181,31 @@
time, all commits to the -STABLE branch must be approved by the
&a.re;. The kinds of changes that are allowed during this 15 day
period include:</para>
<itemizedlist>
<listitem>
<para>Bug fixes.</para>
</listitem>
<listitem>
<para>Documentation updates.</para>
</listitem>
<listitem>
<para>Security-related fixes of any kind.</para>
</listitem>
<listitem>
<para>Minor changes to device drivers, such as adding new Device
IDs.</para>
</listitem>
<listitem>
<para>Any additional change that the release engineering team feels
is justified, given the potential risk.</para>
</listitem>
</itemizedlist>
<para>After the first 15 days of the code slush, a
<emphasis>release candidate</emphasis> is released for
widespread testing and the code enters a <quote>code
@ -220,56 +220,56 @@
different components required for a successful release are
available.</para>
</sect2>
<sect2>
<title>Final Release Checklist</title>
<para>When several release candidates have been made available for
widespread testing and all major issues have been resolved, the
final release <quote>polishing</quote> can begin.</para>
<sect3>
<title>Creating the Release Branch</title>
<para>As described in the introduction, the
<literal>RELENG_<replaceable>X</replaceable>_<replaceable>Y</replaceable></literal>
release branch is a relatively new addition to our release
engineering
engineering
methodology. The first step in creating this branch is to
ensure that you are working with the newest version of the
<literal>RELENG_<replaceable>X</replaceable></literal> sources
that you want to branch <emphasis>from</emphasis>.</para>
<screen>/usr/src&prompt.root; <userinput>cvs update -rRELENG_4 -P -d</userinput></screen>
<para>The next step is to create a branch point
<emphasis>tag</emphasis>, so that diffs against the start of
the branch are easier with CVS:</para>
<screen>/usr/src&prompt.root; <userinput>cvs rtag -rRELENG_4 RELENG_4_8_BP src</userinput></screen>
<para>And then a new branch tag is created with:</para>
<screen>/usr/src&prompt.root; <userinput>cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src</userinput></screen>
<note>
<para><emphasis>The
<literal>RELENG_<replaceable>*</replaceable></literal> tags
are restricted for use by the CVS-meisters and release
engineers.</emphasis></para>
</note>
<sidebar>
<para>A <quote><emphasis>tag</emphasis></quote> is CVS
vernacular for a label that identifies the source at a specific point
in time. By tagging the tree, we ensure that future release builders
will always be able to use the same source we used to create the
will always be able to use the same source we used to create the
official FreeBSD Project releases.</para>
</sidebar>
<mediaobject>
<imageobject>
<imagedata fileref="branches" align="center">
<imagedata fileref="branches" align="center">
</imageobject>
<textobject>
@ -277,14 +277,14 @@
&branches.ascii;
</literallayout>
</textobject>
<textobject>
<phrase>FreeBSD Development Branches</phrase>
<phrase>FreeBSD Development Branches</phrase>
</textobject>
</mediaobject>
</sect3>
<sect3 id="versionbump">
<title>Bumping up the Version Number</title>
@ -322,19 +322,19 @@
<listitem>
<para><filename>src/release/Makefile</filename></para>
</listitem>
<listitem>
<para><filename>src/release/doc/en_US.ISO8859-1/share/sgml/release.dsl</filename></para>
</listitem>
<listitem>
<para><filename>src/release/doc/share/examples/Makefile.relnotesng</filename></para>
</listitem>
<listitem>
<para><filename>src/release/doc/share/sgml/release.ent</filename></para>
</listitem>
<listitem>
<para><filename>src/share/examples/cvsup/standard-supfile</filename></para>
</listitem>
@ -342,15 +342,15 @@
<listitem>
<para><filename>src/sys/conf/newvers.sh</filename></para>
</listitem>
<listitem>
<para><filename>src/sys/sys/param.h</filename></para>
</listitem>
<listitem>
<para><filename>src/usr.sbin/pkg_install/add/main.c</filename></para>
</listitem>
<listitem>
<para><filename>www/en/docs.sgml</filename></para>
</listitem>
@ -364,26 +364,26 @@
</listitem>
</itemizedlist>
<para>The release notes and errata files also need to be adjusted for the
new release (on the release branch) and truncated appropriately
new release (on the release branch) and truncated appropriately
(on the stable/current branch):</para>
<itemizedlist>
<listitem>
<para><filename>src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml
</filename></para>
</listitem>
<listitem>
<para><filename>src/release/doc/en_US.ISO8859-1/errata/article.sgml
</filename></para>
</listitem>
</itemizedlist>
<para><application>Sysinstall</application> should be updated to note
<para><application>Sysinstall</application> should be updated to note
the number of available ports and the amount of disk space required
for the Ports Collection. This information is currently kept in
for the Ports Collection. This information is currently kept in
<filename>src/release/sysinstall/dist.c</filename>.</para>
<para>After the release has been built, a number of file should
@ -417,22 +417,22 @@
</itemizedlist>
</sect3>
<sect3>
<title>Creating Release Tags</title>
<para>When the final release is ready, the following command
will create the <literal>RELENG_4_8_0_RELEASE</literal>
tag.</para>
<screen>
/usr/src&prompt.root; <userinput>cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src</userinput>
</screen>
<para>The Documentation and Ports managers are responsible for
tagging the respective trees with the <literal>RELEASE_4_8_0</literal>
tag.</para>
<para>Occasionally, a last minute fix may be required
<emphasis>after</emphasis> the final tags have been created.
In practice this isn't a problem, since <acronym>CVS</acronym>
@ -468,7 +468,7 @@
CDROM, installation floppies, and an FTP install directory. This
command is aptly named <command>make
release</command>.</para>
<sect2>
<title><command>make release</command></title>
@ -479,29 +479,29 @@
buildworld</command>. The release
target requires several variables be set properly to build a
release:</para>
<itemizedlist>
<listitem>
<para><makevar>CHROOTDIR</makevar> - The directory to be used as the
chroot environment for the entire release build.</para>
</listitem>
<listitem>
<para><makevar>BUILDNAME</makevar> - The name of the release to be
built.</para>
</listitem>
<listitem>
<para><makevar>CVSROOT</makevar> - The location of a CVS Repository.
</para>
</listitem>
<listitem>
<para><makevar>RELEASETAG</makevar> - The CVS tag corresponding to the
release you would like to build.</para>
</listitem>
</listitem>
</itemizedlist>
<para>If you do not already have access to a local CVS
repository, then you may mirror one with <ulink
url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/synching.html#CVSUP">CVSup</ulink>.
@ -520,7 +520,7 @@
top of <filename>src/release/Makefile</filename>. The exact
command used to build the official FreeBSD 4.7 (x86) release
was:</para>
<screen><command>make <literal>release CHROOTDIR=/local3/release \
BUILDNAME=4.7-RELEASE \
CVSROOT=/host/cvs/usr/home/ncvs \
@ -530,81 +530,81 @@
<para>The release <filename>Makefile</filename> can be broken down into several distinct
steps.</para>
<itemizedlist>
<listitem>
<para>Creation of a sanitized system environment in a separate
directory hierarchy with <quote><command>make
<para>Creation of a sanitized system environment in a separate
directory hierarchy with <quote><command>make
<literal>installworld</literal></command></quote>.
</para>
</listitem>
<listitem>
<para>Checkout from CVS of a clean version of the system source,
<para>Checkout from CVS of a clean version of the system source,
documentation, and ports into the release build hierarchy.</para>
</listitem>
<listitem>
<para>Population of <filename>/etc</filename> and
<para>Population of <filename>/etc</filename> and
<filename>/dev</filename> in the chrooted
environment.</para>
</listitem>
<listitem>
<para>chroot into the release build hierarchy, to make it harder for
<para>chroot into the release build hierarchy, to make it harder for
the outside environment to taint this build.</para>
</listitem>
<listitem>
<para><command>make world</command>
in the chrooted environment.</para>
</listitem>
<listitem>
<para>Build of Kerberos-related binaries.</para>
</listitem>
<listitem>
<para>Build <filename>GENERIC</filename> kernel.</para>
</listitem>
<listitem>
<para>Creation of a staging directory tree where the binary
<para>Creation of a staging directory tree where the binary
distributions will be built and packaged.</para>
</listitem>
<listitem>
<para>Build and installation of the documentation toolchain needed to
convert the documentation source (SGML) into HTML and text documents
<para>Build and installation of the documentation toolchain needed to
convert the documentation source (SGML) into HTML and text documents
that will accompany the release.</para>
</listitem>
<listitem>
<para>Build and installation of the actual documentation
(user manuals, tutorials, release notes, hardware compatibility lists,
<para>Build and installation of the actual documentation
(user manuals, tutorials, release notes, hardware compatibility lists,
and so on.)</para>
</listitem>
<listitem>
<para>Build of the <quote>crunched</quote> binaries used for
<para>Build of the <quote>crunched</quote> binaries used for
installation floppies.</para>
</listitem>
<listitem>
<para>Package up distribution tarballs of the binaries and sources.
</para>
</listitem>
<listitem>
<para>Create the boot media and a <quote>fixit</quote> floppy.</para>
</listitem>
<listitem>
<para>Create FTP installation hierarchy.</para>
</listitem>
<listitem>
<para><emphasis>(optionally)</emphasis> Create ISO images for
<para><emphasis>(optionally)</emphasis> Create ISO images for
CDROM/DVD media.</para>
</listitem>
</itemizedlist>
@ -613,7 +613,7 @@
please see &man.release.7;.</para>
</sect2>
<sect2>
<title>Building <application>&xfree86;</application></title>
@ -640,7 +640,7 @@
be unwise to distribute binaries that were built on a system
with <varname>CPUTYPE</varname> set to a specific
processor.</para></note>
</sect2>
<sect2>
@ -659,7 +659,7 @@
in depth.</para>
</sect2>
<sect2>
<title>Release ISOs</title>
@ -675,11 +675,11 @@
provides a manifest for the disc. This
<emphasis>manifest</emphasis> can be created with a simple
command:</para>
<screen>/stage/cdrom&prompt.root; <userinput>find . -type f | sed -e 's/^\.\///' | sort > filename.txt</userinput></screen>
<para>The specific requirements of each CD are outlined below.</para>
<sect3>
<title>Disc 1</title>
@ -694,7 +694,7 @@
installation floppies from other operating systems. This disc
should be made bootable so that users of modern PCs do not
need to create installation floppy disks.</para>
<para>If an alternate version of &xfree86; is to be provided, then
&man.sysinstall.8; must be updated to reflect the new location
and installation instructions. The relevant code is contained
@ -704,7 +704,7 @@
<filename>menus.c</filename>, and
<filename>config.c</filename> will need to be updated.</para>
</sect3>
<sect3>
<title>Disc 2</title>
@ -717,7 +717,7 @@
commercial software demos in the <filename>commerce</filename>
directory.</para>
</sect3>
<sect3>
<title>Discs 3 and 4</title>
@ -832,7 +832,7 @@
certainly encourage innovation in the form of advanced
installation and administration tools, for example, but we can't
be expected to answer questions about it.</para>
<sect2>
<title>Creating Customized Boot floppies</title>
@ -841,46 +841,46 @@
installation floppies. The <quote>quick and dirty</quote> way
to accomplish this would be to modify the staging directory of
an existing <command>make release</command> build hierarchy:</para>
<itemizedlist>
<listitem>
<para>Apply patches or add additional files inside the chroot
release build directory.</para>
</listitem>
<listitem>
<para><command>rm
<para><command>rm
${CHROOTDIR}/usr/obj/usr/src/release/release.[59]</command></para>
</listitem>
<listitem>
<para>rebuild &man.sysinstall.8;, the kernel, or whatever
parts of the system your change affected.</para>
</listitem>
<listitem>
<para><command>chroot ${CHROOTDIR} ./mk floppies
</command></para>
</listitem>
</itemizedlist>
<para>New release floppies will be located in
<filename>${CHROOTDIR}/R/stage/floppies</filename>.</para>
<para>Alternatively, the
<filename>boot.flp</filename> make
target can be called, or the filesystem
creating script,
<filename>src/release/scripts/doFS.sh</filename>, may be invoked
directly.</para>
<para>Local patches may also be supplied to the release build by
defining the <makevar>LOCAL_PATCH</makevar> variable in <command>make
release</command>.
</para>
</sect2>
<sect2>
<title>Scripting <command>sysinstall</command></title>
@ -909,7 +909,7 @@
found in the earlier release candidates. A total of over
<emphasis>500</emphasis> emails were sent to the &a.re; in
little over a month.</para>
<para>Our user community has made it very clear that the security
and stability of a FreeBSD release should not be sacrificed for
any self-imposed deadlines or target release dates. The FreeBSD
@ -927,7 +927,7 @@
scale with our growing userbase. Along these lines we are working
very hard to document the procedures involved in producing FreeBSD
releases.</para>
<itemizedlist>
<listitem>
<para><emphasis>Parallelism</emphasis> - Certain portions of the
@ -943,29 +943,29 @@
<acronym>RAID</acronym> solution (hardware or software) can
significantly decrease the overall build time.</para>
</listitem>
<listitem>
<para><emphasis>Cross-building releases</emphasis> - Building
IA-64 or Alpha release on x86 hardware? <command>make
TARGET=ia64 release</command>.
</para>
</listitem>
<listitem>
<para><emphasis>Regression Testing</emphasis> - We need better
automated correctness testing for FreeBSD.</para>
</listitem>
<listitem>
<para><emphasis>Installation Tools</emphasis> - Our installation
program has long since outlived its intended life span.
Several projects are under development to provide a more
advanced installation mechanism. One of the most promising is
the libh project[5] which aims to provided an intelligent new
the libh project[5] which aims to provide an intelligent new
package framework and GUI installation program.</para>
</listitem>
</itemizedlist>
</sect1>
<!-- Acknowledgements -->
@ -989,53 +989,53 @@
<!-- Reference / Biblio Section -->
<sect1 id="biblio">
<title>References</title>
<para>[1] CVS - Concurrent Versions System
<para>[1] CVS - Concurrent Versions System
<ulink url="http://www.cvshome.org"></ulink></para>
<para>[2] CVSup - The CVS-Optimized General Purpose Network File Distribution
System <ulink url="http://www.polstra.com/projects/freeware/CVSup"></ulink>
</para>
<para>[3] <ulink url="http://bento.FreeBSD.org"></ulink></para>
<para>[4] FreeBSD Ports Collection
<para>[4] FreeBSD Ports Collection
<ulink url="http://www.FreeBSD.org/ports"></ulink></para>
<para>[5] The libh Project
<para>[5] The libh Project
<ulink url="http://www.FreeBSD.org/projects/libh.html"></ulink></para>
<para>[6] FreeBSD Committers <ulink
<para>[6] FreeBSD Committers <ulink
url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html"></ulink>
</para>
<para>[7] FreeBSD Core-Team
<para>[7] FreeBSD Core-Team
<ulink url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-core.html"></ulink></para>
<para>[8] FreeBSD Handbook
<para>[8] FreeBSD Handbook
<ulink url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook"></ulink>
</para>
<para>[9] GNATS: The GNU Bug Tracking System
<ulink url="http://www.gnu.org/software/gnats"></ulink>
</para>
<para>[10] FreeBSD PR Statistics
<ulink url="http://www.FreeBSD.org/prstats/index.html"></ulink></para>
<para>[11] NetBSD Developer Documentation: Release Engineering
<para>[11] NetBSD Developer Documentation: Release Engineering
<ulink url="http://www.NetBSD.org/developers/releng/index.html"></ulink>
</para>
<para>[12] John Baldwin's FreeBSD Release Engineering Proposal
<para>[12] John Baldwin's FreeBSD Release Engineering Proposal
<ulink url="http://people.FreeBSD.org/~jhb/docs/releng.txt"></ulink>
</para>
<para>[13] PXE Jumpstart Guide
<ulink
<para>[13] PXE Jumpstart Guide
<ulink
url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/pxe/index.html"></ulink>
</para>
<para>[14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic:
<para>[14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic:
<ulink url="http://docs.FreeBSD.org/44doc/papers/releng.html">
<emphasis>The Release Engineering of 4.3BSD</emphasis></ulink>
</para>