diff --git a/en_US.ISO8859-1/articles/releng/article.sgml b/en_US.ISO8859-1/articles/releng/article.sgml index a57afe9b29..33bb80b809 100644 --- a/en_US.ISO8859-1/articles/releng/article.sgml +++ b/en_US.ISO8859-1/articles/releng/article.sgml @@ -69,7 +69,7 @@ - + Introduction @@ -90,7 +90,7 @@ FreeBSD development. An elected core-team[7] of very senior developers provides some level of direction over the project. - + The rapid pace of FreeBSD development leaves little time for polishing the development system into a production quality @@ -99,7 +99,7 @@ HEAD or trunk of our CVS tree, known as FreeBSD-CURRENT or -CURRENT for short. - + A more stable branch is maintained, known as FreeBSD-STABLE or -STABLE 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. - + In the interim period between releases, nightly snapshots are built automatically by the FreeBSD Project build machines and made available for download from - + Bug reports and feature requests are continuously submitted by users throughout the release cycle. Problems reports are entered into our GNATS[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 release-polishing. - + 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 RELENG_X_Y branches updated. - + discusses the different phases of the release engineering process leading up to the actual system build and @@ -172,7 +172,7 @@ From CURRENT and it describes the process of merging a tested change from our -CURRENT development branch to our -STABLE branch. - + Code Review @@ -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: - + Bug fixes. - + Documentation updates. - + Security-related fixes of any kind. - + Minor changes to device drivers, such as adding new Device IDs. - + Any additional change that the release engineering team feels is justified, given the potential risk. - + After the first 15 days of the code slush, a release candidate is released for widespread testing and the code enters a code @@ -220,56 +220,56 @@ different components required for a successful release are available. - + Final Release Checklist When several release candidates have been made available for widespread testing and all major issues have been resolved, the final release polishing can begin. - + Creating the Release Branch As described in the introduction, the RELENG_X_Y 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 RELENG_X sources that you want to branch from. - + /usr/src&prompt.root; cvs update -rRELENG_4 -P -d - + The next step is to create a branch point tag, so that diffs against the start of the branch are easier with CVS: - + /usr/src&prompt.root; cvs rtag -rRELENG_4 RELENG_4_8_BP src - + And then a new branch tag is created with: - + /usr/src&prompt.root; cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src - + The RELENG_* tags are restricted for use by the CVS-meisters and release engineers. - + A tag 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. - + - + @@ -277,14 +277,14 @@ &branches.ascii; - + - FreeBSD Development Branches + FreeBSD Development Branches - + Bumping up the Version Number @@ -322,19 +322,19 @@ src/release/Makefile - + src/release/doc/en_US.ISO8859-1/share/sgml/release.dsl - + src/release/doc/share/examples/Makefile.relnotesng - + src/release/doc/share/sgml/release.ent - + src/share/examples/cvsup/standard-supfile @@ -342,15 +342,15 @@ src/sys/conf/newvers.sh - + src/sys/sys/param.h - + src/usr.sbin/pkg_install/add/main.c - + www/en/docs.sgml @@ -364,26 +364,26 @@ - + 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): - + src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml - + src/release/doc/en_US.ISO8859-1/errata/article.sgml - Sysinstall should be updated to note + Sysinstall 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 src/release/sysinstall/dist.c. After the release has been built, a number of file should @@ -417,22 +417,22 @@ - + Creating Release Tags When the final release is ready, the following command will create the RELENG_4_8_0_RELEASE tag. - + /usr/src&prompt.root; cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src - + The Documentation and Ports managers are responsible for tagging the respective trees with the RELEASE_4_8_0 tag. - + Occasionally, a last minute fix may be required after the final tags have been created. In practice this isn't a problem, since CVS @@ -468,7 +468,7 @@ CDROM, installation floppies, and an FTP install directory. This command is aptly named make release. - + <command>make release</command> @@ -479,29 +479,29 @@ buildworld. The release target requires several variables be set properly to build a release: - + CHROOTDIR - The directory to be used as the chroot environment for the entire release build. - + BUILDNAME - The name of the release to be built. - + CVSROOT - The location of a CVS Repository. - + RELEASETAG - The CVS tag corresponding to the release you would like to build. - + - + If you do not already have access to a local CVS repository, then you may mirror one with CVSup. @@ -520,7 +520,7 @@ top of src/release/Makefile. The exact command used to build the official FreeBSD 4.7 (x86) release was: - + make release CHROOTDIR=/local3/release \ BUILDNAME=4.7-RELEASE \ CVSROOT=/host/cvs/usr/home/ncvs \ @@ -530,81 +530,81 @@ The release Makefile can be broken down into several distinct steps. - + - Creation of a sanitized system environment in a separate - directory hierarchy with make + Creation of a sanitized system environment in a separate + directory hierarchy with make installworld. - + - Checkout from CVS of a clean version of the system source, + Checkout from CVS of a clean version of the system source, documentation, and ports into the release build hierarchy. - + - Population of /etc and + Population of /etc and /dev in the chrooted environment. - + - chroot into the release build hierarchy, to make it harder for + chroot into the release build hierarchy, to make it harder for the outside environment to taint this build. - + make world in the chrooted environment. - + Build of Kerberos-related binaries. - + Build GENERIC kernel. - + - Creation of a staging directory tree where the binary + Creation of a staging directory tree where the binary distributions will be built and packaged. - + - Build and installation of the documentation toolchain needed to - convert the documentation source (SGML) into HTML and text documents + Build and installation of the documentation toolchain needed to + convert the documentation source (SGML) into HTML and text documents that will accompany the release. - + - Build and installation of the actual documentation - (user manuals, tutorials, release notes, hardware compatibility lists, + Build and installation of the actual documentation + (user manuals, tutorials, release notes, hardware compatibility lists, and so on.) - + - Build of the crunched binaries used for + Build of the crunched binaries used for installation floppies. - + Package up distribution tarballs of the binaries and sources. - + Create the boot media and a fixit floppy. - + Create FTP installation hierarchy. - + - (optionally) Create ISO images for + (optionally) Create ISO images for CDROM/DVD media. @@ -613,7 +613,7 @@ please see &man.release.7;. - + Building <application>&xfree86;</application> @@ -640,7 +640,7 @@ be unwise to distribute binaries that were built on a system with CPUTYPE set to a specific processor. - + @@ -659,7 +659,7 @@ in depth. - + Release ISOs @@ -675,11 +675,11 @@ provides a manifest for the disc. This manifest can be created with a simple command: - + /stage/cdrom&prompt.root; find . -type f | sed -e 's/^\.\///' | sort > filename.txt - + The specific requirements of each CD are outlined below. - + Disc 1 @@ -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. - + 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 @@ menus.c, and config.c will need to be updated. - + Disc 2 @@ -717,7 +717,7 @@ commercial software demos in the commerce directory. - + Discs 3 and 4 @@ -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. - + Creating Customized Boot floppies @@ -841,46 +841,46 @@ installation floppies. The quick and dirty way to accomplish this would be to modify the staging directory of an existing make release build hierarchy: - + Apply patches or add additional files inside the chroot release build directory. - + - rm + rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[59] - + rebuild &man.sysinstall.8;, the kernel, or whatever parts of the system your change affected. - + chroot ${CHROOTDIR} ./mk floppies - + - + New release floppies will be located in ${CHROOTDIR}/R/stage/floppies. - + Alternatively, the 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. - + Scripting <command>sysinstall</command> @@ -909,7 +909,7 @@ found in the earlier release candidates. A total of over 500 emails were sent to the &a.re; in little over a month. - + 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. - + Parallelism - Certain portions of the @@ -943,29 +943,29 @@ 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. - + Regression Testing - We need better automated correctness testing for FreeBSD. - + Installation Tools - 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. - + @@ -989,53 +989,53 @@ References - [1] CVS - Concurrent Versions System + [1] CVS - Concurrent Versions System - + [2] CVSup - The CVS-Optimized General Purpose Network File Distribution System - + [3] - - [4] FreeBSD Ports Collection + + [4] FreeBSD Ports Collection - - [5] The libh Project + + [5] The libh Project - - [6] FreeBSD Committers [6] FreeBSD Committers - - [7] FreeBSD Core-Team + + [7] FreeBSD Core-Team - - [8] FreeBSD Handbook + + [8] FreeBSD Handbook - + [9] GNATS: The GNU Bug Tracking System - + [10] FreeBSD PR Statistics - - [11] NetBSD Developer Documentation: Release Engineering + + [11] NetBSD Developer Documentation: Release Engineering - - [12] John Baldwin's FreeBSD Release Engineering Proposal + + [12] John Baldwin's FreeBSD Release Engineering Proposal - - [13] PXE Jumpstart Guide - [13] PXE Jumpstart Guide + - - [14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: + + [14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD