diff --git a/en_US.ISO8859-1/articles/releng/article.sgml b/en_US.ISO8859-1/articles/releng/article.sgml index 553ba6df96..94aef75d3a 100644 --- a/en_US.ISO8859-1/articles/releng/article.sgml +++ b/en_US.ISO8859-1/articles/releng/article.sgml @@ -156,7 +156,7 @@ date when the release engineer sends an email to the development mailing lists to remind developers that they only have 15 days to integrate new changes before the code freeze. During this time, - many developers perform what have become know as MFC + many developers perform what have become known as MFC sweeps. MFC stands for Merge From CURRENT and it describes the process of merging a tested change from our -CURRENT development branch to our -STABLE @@ -407,10 +407,10 @@ FreeBSD releases can be built by anyone with a fast machine and access to a source repository. (That should be everyone, since we offer anonymous CVS! See The Handbook for - details.). The only special requirement is - that the vn (On -CURRENT, this - device has been replaced by the new md - memory disk driver .) device must be available. If the + details.) The only special requirement is + that the &man.vn.4; device must be available. (On -CURRENT, this + device has been replaced by the new &man.md.4; + memory disk driver.) If the device is not loaded into your kernel, then the kernel module should be automatically loaded when &man.vnconfig.8; is executed during the boot media creation phase. All of the tools necessary @@ -420,17 +420,17 @@ actually be built with only a single command, including the creation of ISO images suitable for burning to CDROM, installation floppies, and an FTP install directory. This - command is aptly named make - release. + command is aptly named make + release. - <quote>make release</quote> + <command>make release</command> To successfully build a release, you must first populate - /usr/obj by running make - world or simply - make - buildworld. The release + /usr/obj by running make + world or simply + make + buildworld. The release target requires several variables be set properly to build a release: @@ -465,7 +465,7 @@ repository. If RELEASETAG is omitted, then the - release will be built from the HEAD (a.k.a. -CURRENT) branch. + release will be built from the HEAD (a.k.a. -CURRENT) branch. Releases built from this branch are normally referred to as -CURRENT snapshots. @@ -510,7 +510,7 @@ - make world + make world in the chrooted environment. @@ -519,7 +519,7 @@ - Build GENERIC kernel. + Build GENERIC kernel. @@ -630,9 +630,9 @@ Disc 1 The first disc is almost completely created by - make - release. The only changes - that should be made to the disc1 directory are the addition of + make + release. The only changes + that should be made to the disc1 directory are the addition of a tools directory, XFree86, and as many popular third party software packages as will fit on the disc. The @@ -654,8 +654,8 @@ Disc 2 - The second disc is also largely created by make - release. This disc contains a live + The second disc is also largely created by make + release. This disc contains a live filesystem that can be used from &man.sysinstall.8; to troubleshoot a FreeBSD installation. This disc should be bootable and should also contain a compressed copy of the CVS @@ -689,8 +689,7 @@ FreeBSD public FTP sites are all mirrors of a master server that is open only to other FTP sites. This site is known as ftp-master. When the release is ready, the - following files must be modified on ftp-master - : + following files must be modified on ftp-master: @@ -740,14 +739,14 @@ It may take many hours after updating ftp-master before a majority of the Tier-1 FTP sites have the new software. It is imperative that the release - engineers coordinate with &a.hubs; before announcing the general + engineers coordinate with the &a.hubs; before announcing the general availability of new software on the FTP sites. CD-ROM Replication - Coming soon : Tips for sending FreeBSD ISOs to a replicator + Coming soon: Tips for sending FreeBSD ISOs to a replicator and quality assurance measures to be taken. @@ -777,7 +776,7 @@ additional kernel modules or userland tools be added to the installation floppies. The quick and dirty way to accomplish this would be to modify the staging directory of - an existing make release build hierarchy: + an existing make release build hierarchy: @@ -810,15 +809,15 @@ ${CHROOTDIR}/R/stage/floppies. Alternatively, the - boot.flp make + boot.flp make target can be called, or the filesystem creating script, src/release/scripts/doFS.sh, may be invoked directly. Local patches may also be supplied to the release build by - defining the LOCAL_PATCH variable in make - release. + defining the LOCAL_PATCH variable in make + release. @@ -875,20 +874,20 @@ release build are actually embarrassingly parallel. Most of the tasks are very I/O intensive, so having multiple high-speed disk drives is actually more important than - using multiple processors in speeding up the make - release process. If multiple disks are used for - different hierarchies in the chroot - environment, then the CVS checkout of the ports and doc trees - can be happening simultaneously to the make - world on another disk. Using a + using multiple processors in speeding up the make + release process. If multiple disks are used for + different hierarchies in the &man.chroot.2; + environment, then the CVS checkout of the ports and doc trees + can be happening simultaneously as the make + world on another disk. Using a RAID solution (hardware or software) can significantly decrease the overall build time. Cross-building releases - Building - IA-64 or Alpha release on x86 hardware? make - TARGET=ia64 release. + IA-64 or Alpha release on x86 hardware? make + TARGET=ia64 release.