From 2ceb7e0f9dea782b1fb5b4cf3bade106b700fd09 Mon Sep 17 00:00:00 2001 From: Benedict Reuschling Date: Tue, 12 Jun 2018 18:19:12 +0000 Subject: [PATCH] Revert until I figure out the build breakage. Yes, I should have tested it locally first. Pointy hat to: me --- en_US.ISO8859-1/articles/releng/article.xml | 1386 +++++++++---------- 1 file changed, 685 insertions(+), 701 deletions(-) diff --git a/en_US.ISO8859-1/articles/releng/article.xml b/en_US.ISO8859-1/articles/releng/article.xml index c8d38e2c70..749b5ee5e6 100644 --- a/en_US.ISO8859-1/articles/releng/article.xml +++ b/en_US.ISO8859-1/articles/releng/article.xml @@ -2,39 +2,28 @@ -
- - - &os; Release Engineering +
+ + &os; Release Engineering + + November 2001 BSDCon Europe - - - Murray - Stokely - - - I've been involved in the development of &os; based - products since 1997 at Walnut Creek CDROM, BSDi, and now - Wind River Systems. &os; 4.4 was the first official - release of &os; that I played a significant part - in. - - -
- murray@FreeBSD.org - https://people.FreeBSD.org/~murray/ -
- - + MurrayStokely + I've been involved in the development of &os; based products + since 1997 at Walnut Creek CDROM, BSDi, and now Wind River Systems. + &os; 4.4 was the first official release of &os; that I played + a significant part in. + +
murray@FreeBSD.org + https://people.FreeBSD.org/~murray/ +
+ @@ -46,402 +35,395 @@ $FreeBSD$ - - This document is outdated and does not accurately - describe the current release procedures of the &os; Release - Engineering team. It is retained for historical purposes. - The current procedures used by the &os; Release Engineering - team are available in the &os; - Release Engineering article. + + + This document is outdated and does not accurately + describe the current release procedures of the &os; + Release Engineering team. It is retained for historical + purposes. The current procedures used by the &os; Release + Engineering team are available in the &os; + Release Engineering article. + + + This paper describes the approach used by the &os; + release engineering team to make production quality releases + of the &os; Operating System. It details the methodology + used for the official &os; releases and describes the tools + available for those interested in producing customized &os; + releases for corporate rollouts or commercial + productization. + - This paper describes the approach used by the &os; - release engineering team to make production quality releases - of the &os; Operating System. It details the methodology - used for the official &os; releases and describes the tools - available for those interested in producing customized &os; - releases for corporate rollouts or commercial - productization. - - + - - Introduction + + Introduction - The development of &os; is a very open process. &os; is - comprised of contributions from thousands of people around the - world. The &os; Project provides Subversion - Subversion, http://subversion.apache.org - access to the general public so that - others can have access to log messages, diffs (patches) - between development branches, and other productivity - enhancements that formal source code management provides. - This has been a huge help in attracting more talented - developers to &os;. However, I think everyone would agree - that chaos would soon manifest if write access to the main - repository was opened up to everyone on the Internet. - Therefore only a select group of nearly 300 - people are given write access to the Subversion repository. - These committers - - FreeBSD - committers - - - are usually the people who do the bulk of &os; development. - An elected Core - Team - - &os; - Core Team - - of developers provide some level of direction over the - project. + The development of &os; is a very open process. &os; is + comprised of contributions from thousands of people around the + world. The &os; Project provides + Subversion + + + Subversion, http://subversion.apache.org + + + access to the general public so that + others can have access to log messages, diffs (patches) between + development branches, and other productivity enhancements that + formal source code management provides. This has been a huge help + in attracting more talented developers to &os;. However, I + think everyone would agree that chaos would soon manifest if write + access to the main repository was opened up to everyone on the Internet. + Therefore only a select group of nearly 300 people are + given write access to the Subversion repository. These + committers + + + FreeBSD committers + + + are usually the people who do the bulk of &os; development. An elected + Core Team + + + &os; Core Team + + + of developers provide some level of direction over the project. - The rapid pace of &os; - development makes the main development branch unsuitable for - the everyday use by the general public. In particular, - stabilizing efforts are required for polishing the development - system into a production quality release. To solve this - conflict, development continues on several parallel tracks. - The main development branch is the HEAD - or trunk of our Subversion tree, known as - &os;-CURRENT or -CURRENT for - short. + The rapid pace of &os; + development makes the main development branch unsuitable for the + everyday use by the general public. In particular, stabilizing + efforts are required for polishing the development system into a + production quality release. To solve this conflict, development + continues on several parallel tracks. The main development branch + is the HEAD or trunk of + our Subversion tree, known as &os;-CURRENT or + -CURRENT for short. - A set of more stable branches are maintained, known as - &os;-STABLE or -STABLE for - short. All branches live in a master Subversion repository - maintained by the &os; Project. &os;-CURRENT is the - bleeding-edge of &os; development where all new - changes first enter the system. &os;-STABLE is the - development branch from which major releases are made. - Changes go into this branch at a different pace, and with the - general assumption that they have first gone into &os;-CURRENT - and have been thoroughly tested by our user community. + A set of more stable branches are maintained, known as + &os;-STABLE or -STABLE for short. + All branches live in a master Subversion repository maintained by the + &os; Project. &os;-CURRENT is the bleeding-edge of + &os; development where all new changes first enter the system. + &os;-STABLE is the development branch from which major releases + are made. Changes go into this branch at a different pace, and + with the general assumption that they have first gone into + &os;-CURRENT and have been thoroughly tested by our user + community. - The term stable in the name of the - branch refers to the presumed Application Binary Interface - stability, which is promised by the project. This means that - a user application compiled on an older version of the system - from the same branch works on a newer system from the same - branch. The ABI stability has improved greatly from the - compared to previous releases. In most cases, binaries from - the older STABLE systems run unmodified - on newer systems, including HEAD, - assuming that the system management interfaces are not - used. + The term stable in the name of the branch + refers to the presumed Application Binary Interface stability, + which is promised by the project. This means that a user + application compiled on an older version of the system from the + same branch works on a newer system from the same branch. The + ABI stability has improved greatly from the compared to previous + releases. In most cases, binaries from the older + STABLE systems run unmodified on newer systems, + including HEAD, assuming that the system + management interfaces are not used. - In the interim period between releases, weekly snapshots - are built automatically by the &os; Project build machines and - made available for download from - ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. - The widespread availability of binary release snapshots, and - the tendency of our user community to keep up with -STABLE - development with Subversion and make - buildworld - Rebuilding - "world" helps to keep - &os;-STABLE in a very reliable condition even before the - quality assurance activities ramp up pending a major - release. + In the interim period between releases, weekly snapshots are + built automatically by the &os; Project build machines and made + available for download from ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. + The widespread availability of binary release snapshots, and the + tendency of our user community to keep up with -STABLE development + with Subversion and make + buildworld + + + Rebuilding "world" + + + helps to keep + &os;-STABLE in a very reliable condition even before the + quality assurance activities ramp up pending a major + release. - In addition to installation ISO snapshots, weekly virtual - machine images are also provided for use with - VirtualBox, - qemu, or other popular emulation - software. The virtual machine images can be downloaded from - ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/. + In addition to installation ISO snapshots, weekly virtual + machine images are also provided for use with + VirtualBox, + qemu, or other popular emulation + software. The virtual machine images can be downloaded from + ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/. - The virtual machine images are approximately 150MB - &man.xz.1; compressed, and contain a 10GB sparse filesystem - when attached to a virtual machine. + The virtual machine images are approximately 150MB &man.xz.1; + compressed, and contain a 10GB sparse filesystem when attached to + a virtual machine. - Bug reports and feature requests are continuously - submitted by users throughout the release cycle. Problems - reports are entered into our - Bugzilla database through the web - interface provided at https://www.freebsd.org/support/bugreports.html. + Bug reports and feature requests are continuously submitted by + users throughout the release cycle. Problems reports are entered into our + Bugzilla database + through the web + interface provided at https://www.freebsd.org/support/bugreports.html. + + To service our most conservative users, individual release + branches were introduced with &os; 4.3. + These release branches are created shortly before a final release + is made. After the release goes out, only the most critical + security fixes and additions are merged onto the release branch. + In addition to source updates via Subversion, binary patchkits are + available to keep systems on the + releng/X.Y + branches updated. + + + What this article describes + + The following sections of this article describe: + + + + + + + The different phases of the release engineering process + leading up to the actual system build. + + + + + + + + The actual build process. + + + + + - To service our most conservative users, individual release - branches were introduced with &os; 4.3. These release - branches are created shortly before a final release is made. - After the release goes out, only the most critical security - fixes and additions are merged onto the release branch. In - addition to source updates via Subversion, binary patchkits - are available to keep systems on the - releng/X.Y - branches updated. + + How the base release may be extended by third parties. + + + + + - - What This Article Describes + + Some of the lessons learned through the release of &os; 4.4. + + - The following sections of this article describe: + + - - - - - - The different phases of the release engineering - process leading up to the actual system build. - - - - - - - - The actual build process. - - - - - - - - How the base release may be extended by third - parties. - - - - - - - - Some of the lessons learned through the release of - &os; 4.4. - - - - - - - - Future directions of development. - - - - - + + Future directions of development. + + + + + - - Release Process + + Release Process - New releases of &os; are released from the -STABLE branch - at approximately four month intervals. The &os; release - process begins to ramp up 70-80 days before the anticipated - release 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 - known as MFC sweeps. + New releases of &os; are released from the -STABLE branch + at approximately four month intervals. The &os; release + process begins to ramp up 70-80 days before the anticipated release + 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 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 branch. Project policy requires any change to be - first applied to trunk, and merged to the -STABLE branches - after sufficient external testing was done by -CURRENT users - (developers are expected to extensively test the change before - committing to -CURRENT, but it is impossible for a person to - exercise all usages of the general-purpose operating system). - Minimal MFC period is 3 days, which is typically used only for - trivial or critical bugfixes. + MFC stands for Merge From + CURRENT and it describes the process of merging a tested + change from our -CURRENT development branch to our -STABLE branch. + Project policy requires any change to be first applied to + trunk, and merged to the -STABLE branches after sufficient + external testing was done by -CURRENT users (developers are + expected to extensively test the change before committing to + -CURRENT, but it is impossible for a person to exercise all usages + of the general-purpose operating system). Minimal MFC period is 3 + days, which is typically used only for trivial or critical + bugfixes. - - Code Review + + Code Review - Sixty days before the anticipated release, the source - repository enters a code freeze. During this - time, all commits to the -STABLE branch must be approved by - &a.re;. The approval process is technically enforced by a - pre-commit hook. The kinds of changes that are allowed - during this period include: + Sixty days before the anticipated release, the source + repository enters a code freeze. During this + time, all commits to the -STABLE branch must be approved by + &a.re;. The approval process is technically enforced by a + pre-commit hook. The kinds of changes that are allowed during + this period include: - - - Bug fixes. - + + + Bug fixes. + - - Documentation updates. - + + Documentation updates. + - - Security-related fixes of any kind. - + + Security-related fixes of any kind. + - - Minor changes to device drivers, such as adding new - Device IDs. - + + Minor changes to device drivers, such as adding new Device + IDs. + - - Driver updates from the vendors. - + + Driver updates from the vendors. + - - Any additional change that the release engineering - team feels is justified, given the potential - risk. - - + + Any additional change that the release engineering team feels + is justified, given the potential risk. + + - Shortly after the code freeze is started, a - BETA1 image is built and released for - widespread testing. During the code freeze, at least one - beta image or release candidate is released every two weeks - until the final release is ready. During the days preceding - the final release, the release engineering team is in - constant communication with the security-officer team, the - documentation maintainers, and the port maintainers to - ensure that all of the different components required for a - successful release are available. + Shortly after the code freeze is started, a + BETA1 image is built and released for + widespread testing. During the code freeze, at least one beta + image or release candidate is released every two weeks until the + final release is ready. During the days preceeding the final + release, the release engineering team is in constant + communication with the security-officer team, the documentation + maintainers, and the port maintainers to ensure that all of the + different components required for a successful release are + available. - After the quality of the BETA images is satisfying - enough, and no large and potentially risky changes are - planned, the release branch is created and Release - Candidate (RC) images are built from the - release branch, instead of the BETA images from the STABLE - branch. Also, the freeze on the STABLE branch is lifted and - release branch enters a hard code freeze - where it becomes much harder to justify new changes to the - system unless a serious bug-fix or security issue is - involved. - + After the quality of the BETA images is satisfying enough, + and no large and potentially risky changes are planned, the + release branch is created and Release + Candidate (RC) images are built from the release + branch, instead of the BETA images from the STABLE branch. + Also, the freeze on the STABLE branch is lifted and release + branch enters a hard code freeze where it becomes + much harder to justify new changes to the system unless a + serious bug-fix or security issue is involved. + - - Final Release Checklist + + Final Release Checklist - When several BETA images have been made available for - widespread testing and all major issues have been resolved, - the final release polishing can begin. + When several BETA images have been made available for + widespread testing and all major issues have been resolved, the + final release polishing can begin. - - Creating the Release Branch - - - In all examples below, - $FSVN refers to the location - of the &os; Subversion repository, - svn+ssh://svn.FreeBSD.org/base/. - - - The layout of &os; branches in Subversion is described - in the Committer's - Guide. The first step in creating a branch is to - identify the revision of the - stable/X - sources that you want to branch - from. - - &prompt.root; svn log -v $FSVN/stable/9 - - The next step is to create the release - branch - - &prompt.root; svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2 - - This branch can be checked out: - - &prompt.root; svn co $FSVN/releng/9.2 src + + Creating the Release Branch - Creating the releng branch and - release tags is done by the Release - Engineering Team. + In all examples below, $FSVN + refers to the location of the &os; Subversion repository, + svn+ssh://svn.FreeBSD.org/base/. + + + The layout of &os; branches in Subversion is + described in the Committer's Guide. + The first step in creating a branch is to + identify the revision of the + stable/X sources + that you want to branch from. + + &prompt.root; svn log -v $FSVN/stable/9 + + The next step is to create the release branch + + + &prompt.root; svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2 + + This branch can be checked out: + + &prompt.root; svn co $FSVN/releng/9.2 src + + + Creating the releng branch and + release tags is done by the Release + Engineering Team. + - - - + + + - - &os; Development Branch - + + &os; Development Branch + - - - + + + - - &os; 3.x STABLE Branch - + + &os; 3.x STABLE Branch + - - - + + + - - &os; 4.x STABLE Branch - + + &os; 4.x STABLE Branch + - - - + + + - - &os; 5.x STABLE Branch - + + &os; 5.x STABLE Branch + - - - + + + - - &os; 6.x STABLE Branch - + + &os; 6.x STABLE Branch + - - - + + + - - &os; 7.x STABLE Branch - + + &os; 7.x STABLE Branch + - - - + + + - - &os; 8.x STABLE Branch - + + &os; 8.x STABLE Branch + - - - + + + - - &os; 9.x STABLE Branch - + + &os; 9.x STABLE Branch + @@ -449,98 +431,104 @@ Bumping up the Version Number Before the final release can be tagged, built, and - released, the following files need to be modified to reflect - the correct version of &os;: + released, the following files need to be modified to reflect + the correct version of &os;: - - doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml - + + doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml + + - - doc/en_US.ISO8859-1/books/porters-handbook/book.xml - + + doc/en_US.ISO8859-1/books/porters-handbook/book.xml + + - - doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi - + + doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi + - - ports/Tools/scripts/release/config - + + ports/Tools/scripts/release/config + - - doc/share/xml/freebsd.ent - - - src/Makefile.inc1 - + + doc/share/xml/freebsd.ent + - - src/UPDATING - + + src/Makefile.inc1 + - - src/gnu/usr.bin/groff/tmac/mdoc.local - + + src/UPDATING + - - src/release/Makefile - + + src/gnu/usr.bin/groff/tmac/mdoc.local + - - src/release/doc/en_US.ISO8859-1/share/xml/release.dsl - + + src/release/Makefile + - - src/release/doc/share/examples/Makefile.relnotesng - + + src/release/doc/en_US.ISO8859-1/share/xml/release.dsl + - - src/release/doc/share/xml/release.ent - + + src/release/doc/share/examples/Makefile.relnotesng + - - src/sys/conf/newvers.sh - + + src/release/doc/share/xml/release.ent + - - src/sys/sys/param.h - + + src/sys/conf/newvers.sh + - - src/usr.sbin/pkg_install/add/main.c - + + src/sys/sys/param.h + - - doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml - + + src/usr.sbin/pkg_install/add/main.c + + + + doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml + - The release notes and errata files also need to be - adjusted for the new release (on the release branch) and - truncated appropriately (on the stable/current branch): + The release notes and errata files also need to be adjusted for the + new release (on the release branch) and truncated appropriately + (on the stable/current branch): - - src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml - + + src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml + + - - src/release/doc/en_US.ISO8859-1/errata/article.xml - + + src/release/doc/en_US.ISO8859-1/errata/article.xml + + - Sysinstall should be updated to - note the number of available ports and the amount of disk - space required for the Ports Collection. - - &os; Ports Collection https://www.FreeBSD.org/ports - - This information is currently kept in + Sysinstall should be updated to note + the number of available ports and the amount of disk space required + for the Ports Collection. + + + &os; Ports Collection + https://www.FreeBSD.org/ports + + + This information is currently kept in src/usr.sbin/bsdinstall/dist.c. After the release has been built, a number of files should @@ -549,57 +537,62 @@ doc/ subversion tree. - - share/images/articles/releng/branches-relengX.pic - + + share/images/articles/releng/branches-relengX.pic + - + head/share/xml/release.ent - + - + en_US.ISO8859-1/htdocs/releases/* - + - + en_US.ISO8859-1/htdocs/releng/index.xml - + - + share/xml/news.xml - + Additionally, update the BSD Family Tree file: - - src/share/misc/bsd-family-tree - + + src/share/misc/bsd-family-tree + + + Creating the Release Tag When the final release is ready, the following command - will create the release/9.2.0 tag. + will create the release/9.2.0 + tag. &prompt.root; svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0 The Documentation and Ports managers are responsible for - tagging their respective trees with the - tags/RELEASE_9_2_0 tag. + tagging their respective trees with the tags/RELEASE_9_2_0 + tag. - When the Subversion svn cp command is - used to create a release tag, this - identifies the source at a specific point in time. By - creating tags, we ensure that future release builders will - always be able to use the exact same source we used to - create the official &os; Project releases. + When the Subversion svn cp command + is used to create a release tag, + this identifies the source at a specific point in time. + By creating tags, we ensure that future release builders + will always be able to use the exact same source we used to create the + official &os; Project releases. + + @@ -609,134 +602,132 @@ Release Building &os; releases can be built by anyone with a - fast machine and access to a source repository. (That should be - everyone, since we offer Subversion access! See the Subversion section in - the Handbook for details.) The only - special requirement is that the &man.md.4; device must be - available. If the device is not loaded into your kernel, then the - kernel module should be automatically loaded when &man.mdconfig.8; - is executed during the boot media creation phase. All of the - tools necessary to build a release are available from the - Subversion repository in src/release. These - tools aim to provide a consistent way to build &os; releases. A - complete release can actually be built with only a single command, - including the creation of ISO images suitable - for burning to CDROM or DVD, and an FTP install directory. - &man.release.7; fully documents the - src/release/generate-release.sh script which is - used to build a release. generate-release.sh - is a wrapper around the Makefile target: make - release. + fast machine and access to a source repository. (That should be + everyone, since we offer Subversion access ! + See the + Subversion section + in the Handbook for + details.) The only special requirement is + that the &man.md.4; device must be available. If the + device is not loaded into your kernel, then the kernel module + should be automatically loaded when &man.mdconfig.8; is executed + during the boot media creation phase. All of the tools necessary + to build a release are available from the Subversion repository in + src/release. These tools aim to provide a + consistent way to build &os; releases. A complete release can + actually be built with only a single command, including the + creation of ISO images suitable for burning to + CDROM or DVD, and an FTP install directory. &man.release.7; fully + documents the src/release/generate-release.sh + script which is used to build a release. generate-release.sh + is a wrapper around the Makefile target: make release. Building a Release &man.release.7; documents the exact commands required to - build a &os; release. The following sequences of commands can - build an 9.2.0 release: + build a &os; release. The following sequences of commands can build + an 9.2.0 release: - &prompt.root; cd /usr/src/release -&prompt.root; sh generate-release.sh release/9.2.0 /local3/release + &prompt.root; cd /usr/src/release + &prompt.root; sh generate-release.sh release/9.2.0 /local3/release - After running these commands, all prepared release files are - available in /local3/release/R + After running these commands, all prepared release + files are available in /local3/release/R directory. - The release Makefile can be broken down - into several distinct steps. + The release Makefile can be broken down into several distinct + steps. - Creation of a sanitized system environment in a separate - directory hierarchy with make - installworld. + Creation of a sanitized system environment in a separate + directory hierarchy with make + installworld. + - Checkout from Subversion of a clean version of the - system source, documentation, and ports into the release - build hierarchy. + Checkout from Subversion of a clean version of the system source, + documentation, and ports into the release build hierarchy. - Population of /etc and - /dev in the chrooted - environment. + Population of /etc and + /dev in the chrooted + environment. - chroot into the release build hierarchy, to make it - harder for the outside environment to taint this - build. + chroot into the release build hierarchy, to make it harder for + the outside environment to taint this build. - make world in the chrooted - environment. + make world + in the chrooted environment. - Build of Kerberos-related binaries. + Build of Kerberos-related binaries. - Build GENERIC kernel. + Build GENERIC kernel. - Creation of a staging directory tree where the binary - distributions will be built and packaged. + 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 that will accompany the release. + 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, and so on.) + Build and installation of the actual documentation + (user manuals, tutorials, release notes, hardware compatibility lists, + and so on.) - Package up distribution tarballs of the binaries and - sources. + Package up distribution tarballs of the binaries and sources. + - Create FTP installation hierarchy. + Create FTP installation hierarchy. - (optionally) Create ISO images for - CDROM/DVD media. + (optionally) Create ISO images for + CDROM/DVD media. For more information about the release build infrastructure, please see &man.release.7;. - - It is important to remove any site-specific settings from - /etc/make.conf. For example, it would be - unwise to distribute binaries that were built on a system with - CPUTYPE set to a specific - processor. - + It is important to remove any site-specific settings + from /etc/make.conf. For example, it would + be unwise to distribute binaries that were built on a system + with CPUTYPE set to a specific + processor. + Contributed Software (<quote>ports</quote>) - The &os; - Ports collection is a collection of over &os.numports; - third-party software packages available for &os;. The - &a.portmgr; is responsible for maintaining a consistent ports - tree that can be used to create the binary packages that - accompany official &os; releases. + The &os; Ports + collection is a collection of over &os.numports; + third-party software packages available for &os;. The &a.portmgr; + is responsible for maintaining a consistent ports tree that can be used + to create the binary packages that accompany official &os; + releases. @@ -745,76 +736,74 @@ Starting with &os; 4.4, the &os; Project decided to release all four ISO images that were previously sold on the BSDi/Wind River Systems/FreeBSD Mall - official CDROM distributions. Each of the four + official CDROM distributions. Each of the four discs must contain a README.TXT file that explains the contents of the disc, a CDROM.INF file that provides meta-data for the disc so that &man.bsdinstall.8; can validate and use the contents, and a filename.txt file that - provides a manifest for the disc. This + 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. + The specific requirements of each CD are outlined below. 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 a tools directory, and as - many popular third party software packages as will fit on the - disc. The tools directory contains - software that allow users to create 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. + make + release. The only changes + that should be made to the disc1 directory are the addition of + a tools directory, and as many popular + third party software packages as will fit on the disc. The + tools directory contains software that allow users to create + 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 a custom kernel of &os; is to be included, then - &man.bsdinstall.8; and &man.release.7; must be updated to - include installation instructions. The relevant code is - contained in src/release and - src/usr.sbin/bsdinstall. Specifically, - the file src/release/Makefile, and - dist.c, dist.h, - menus.c, install.c, - and Makefile will need to be updated - under src/usr.sbin/bsdinstall. - Optionally, you may choose to update - bsdinstall.8. + &man.bsdinstall.8; and &man.release.7; must be updated to + include installation instructions. The relevant code is contained + in src/release and src/usr.sbin/bsdinstall. + Specifically, the file src/release/Makefile, and + dist.c, dist.h, + menus.c, install.c, and + Makefile will need to be updated under + src/usr.sbin/bsdinstall. Optionally, you may choose + to update bsdinstall.8. + Disc 2 The second disc is also largely created by make - release. This disc contains a live - filesystem that can be used from &man.bsdinstall.8; - to troubleshoot a &os; installation. This disc should be - bootable and should also contain a compressed copy of the CVS - repository in the CVSROOT directory and - commercial software demos in the commerce - directory. + release. This disc contains a live + filesystem that can be used from &man.bsdinstall.8; to + troubleshoot a &os; installation. This disc should be + bootable and should also contain a compressed copy of the CVS + repository in the CVSROOT directory and + commercial software demos in the commerce + directory. - Multi-volume Support + Multi-volume support Sysinstall supports multiple - volume package installations. This requires that each disc - have an INDEX file containing all of the - packages on all volumes of a set, along with an extra field - that indicates which volume that particular package is on. - Each volume in the set must also have the - CD_VOLUME variable set in the - cdrom.inf file so that bsdinstall can - tell which volume is which. When a user attempts to install a - package that is not on the current disc, bsdinstall will - prompt the user to insert the appropriate one. + volume package installations. This requires that each disc + have an INDEX file containing all of the + packages on all volumes of a set, along with an extra field + that indicates which volume that particular package is on. + Each volume in the set must also have the + CD_VOLUME variable set in the + cdrom.inf file so that bsdinstall can + tell which volume is which. When a user attempts to install a + package that is not on the current disc, bsdinstall will + prompt the user to insert the appropriate one. @@ -826,83 +815,72 @@ FTP Sites - When the release has been thoroughly tested and packaged for - distribution, the master FTP site must be updated. The official - &os; 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: + When the release has been thoroughly tested and packaged for + distribution, the master FTP site must be updated. The official + &os; 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: - - - /pub/FreeBSD/releases/arch/X.Y-RELEASE/ - - The installable FTP directory as output from - make release. - - + + + /pub/FreeBSD/releases/arch/X.Y-RELEASE/ + + The installable FTP directory as output from make + release. + + - - /pub/FreeBSD/ports/arch/packages-X.Y-release/ - - The complete package build for this - release. - - + + /pub/FreeBSD/ports/arch/packages-X.Y-release/ + The complete package build for this + release. + - - /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools - - A symlink to - ../../../tools. - - + + /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools + A symlink to + ../../../tools. + - - /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages - - A symlink to - ../../../ports/arch/packages-X.Y-release. - - + + /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages + A symlink to + ../../../ports/arch/packages-X.Y-release. + - - /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso - - The ISO images. The * is - disc1, disc2, - etc. Only if there is a disc1 and - there is an alternative first installation CD (for example - a stripped-down install with no windowing system) there - may be a mini as well. - - - + + /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso + The ISO images. The * is + disc1, disc2, etc. + Only if there is a disc1 and there is an + alternative first installation CD (for example a + stripped-down install with no windowing system) there may + be a mini as well. + + + - For more information about the distribution mirror - architecture of the &os; FTP sites, please see the Mirroring &os; - article. + For more information about the distribution mirror + architecture of the &os; FTP sites, please see the Mirroring &os; article. - It may take many hours to two days after updating - ftp-master before a majority of the - Tier-1 FTP sites have the new software depending on whether or - not a package set got loaded at the same time. It is imperative - that the release engineers coordinate with the - &a.mirror-announce; before announcing the general availability - of new software on the FTP sites. Ideally the release package - set should be loaded at least four days prior to release day. - The release bits should be loaded between 24 and 48 hours before - the planned release time with other file - permissions turned off. This will allow the mirror sites to - download it but the general public will not be able to download - it from the mirror sites. Mail should be sent to - &a.mirror-announce; at the time the release bits get posted - saying the release has been staged and giving the time that the - mirror sites should begin allowing access. Be sure to include a - time zone with the time, for example make it relative to - GMT. + It may take many hours to two days after updating + ftp-master before a majority of the Tier-1 FTP + sites have the new software depending on whether or not a package + set got loaded at the same time. It is imperative that the release + engineers coordinate with the &a.mirror-announce; before announcing the general + availability of new software on the FTP sites. Ideally + the release package set should be loaded at least four + days prior to release day. The release bits should be + loaded between 24 and 48 hours before the planned release + time with other file permissions turned off. + This will allow the mirror sites to download it but the + general public will not be able to download it from the mirror + sites. Mail should be sent to &a.mirror-announce; at the time + the release bits get posted saying the release has been staged + and giving the time that the mirror sites should begin allowing + access. Be sure to include a time zone with the + time, for example make it relative to GMT. @@ -920,30 +898,31 @@ Although &os; forms a complete operating system, there is nothing that forces you to use the system exactly as we have - packaged it up for distribution. We have tried to design the + packaged it up for distribution. We have tried to design the system to be as extensible as possible so that it can serve as a - platform that other commercial products can be built on top of. - The only rule we have about this is that if you are - going to distribute &os; with non-trivial changes, we encourage - you to document your enhancements! The &os; community can only - help support users of the software we provide. We certainly - encourage innovation in the form of advanced installation and - administration tools, for example, but we cannot be expected to - answer questions about it. + platform that other commercial products can be built on top + of. The only rule we have about this is that if you + are going to distribute &os; with non-trivial changes, we + encourage you to document your enhancements! The &os; community + can only help support users of the software we provide. We + certainly encourage innovation in the form of advanced + installation and administration tools, for example, but we cannot + be expected to answer questions about it. Scripting <command>bsdinstall</command> The &os; system installation and configuration tool, - &man.bsdinstall.8;, can be scripted to provide automated - installs for large sites. This functionality can be used in - conjunction with &intel; PXE + &man.bsdinstall.8;, can be scripted to provide automated installs + for large sites. This functionality can be used in conjunction + with &intel; PXE - &url.books.handbook;/network-pxe-nfs.html - + + &url.books.handbook;/network-pxe-nfs.html + - to bootstrap systems from the network. + to bootstrap systems from the network. + @@ -954,21 +933,22 @@ The release engineering process for 4.4 formally began on August 1st, 2001. After that date all commits to the RELENG_4 branch of &os; had to be explicitly - approved by the &a.re;. The first release candidate for the x86 - architecture was released on August 16, followed by 4 more release - candidates leading up to the final release on September 18th. The - security officer was very involved in the last week of the process - as several security issues were found in the earlier release - candidates. A total of over 500 emails were - sent to the &a.re; in little over a month. + approved by the &a.re;. The first + release candidate for the x86 architecture was released on August + 16, followed by 4 more release candidates leading up to the final + release on September 18th. The security officer was very involved + in the last week of the process as several security issues were + 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 &os; release should not be sacrificed for any - self-imposed deadlines or target release dates. The &os; Project - has grown tremendously over its lifetime and the need for + and stability of a &os; release should not be sacrificed for + any self-imposed deadlines or target release dates. The &os; + Project has grown tremendously over its lifetime and the need for standardized release engineering procedures has never been more - apparent. This will become even more important as &os; is ported - to new platforms. + apparent. This will become even more important as &os; is + ported to new platforms. @@ -976,45 +956,45 @@ Future Directions It is imperative for our release engineering activities to - scale with our growing userbase. Along these lines we are working + scale with our growing userbase. Along these lines we are working very hard to document the procedures involved in producing &os; releases. Parallelism - Certain portions of the - 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 - &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. + 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 &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. + Regression Testing - We need better - automated correctness testing for &os;. + automated correctness testing for &os;. 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. The libh project was one - such project that aimed to provide an intelligent new package - framework and GUI installation program. + program has long since outlived its intended life span. + Several projects are under development to provide a more + advanced installation mechanism. The libh project was one + such project that aimed to provide an intelligent new package + framework and GUI installation program. @@ -1022,39 +1002,43 @@ - Acknowledgements +Acknowledgements I would like to thank Jordan Hubbard for giving me the opportunity to take on some of the release engineering responsibilities for &os; 4.4 and also for all of his work - throughout the years making &os; what it is today. Of course the - release would not have been possible without all of the - release-related work done by &a.asami.email;, &a.steve.email;, - &a.bmah.email;, &a.nik.email;, &a.obrien.email;, &a.kris.email;, - &a.jhb.email; and the rest of the &os; development community. I - would also like to thank &a.rgrimes.email;, &a.phk.email;, and - others who worked on the release engineering tools in the very - early days of &os;. This article was influenced by release - engineering documents from the CSRG + throughout the years making &os; what it is today. Of course + the release would not have been possible without all of the + release-related work done by &a.asami.email;, &a.steve.email;, &a.bmah.email;, &a.nik.email;, + &a.obrien.email;, &a.kris.email;, &a.jhb.email; and the rest of the &os; development + community. I would also like to thank &a.rgrimes.email;, &a.phk.email;, and others + who worked on the release engineering tools in the very early days + of &os;. This article was influenced by release engineering + documents from the CSRG - Marshall Kirk McKusick, Michael J. Karels, and Keith - Bostic: - The Release Engineering of - 4.3BSD + + Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: + + The Release Engineering of 4.3BSD , - the NetBSD Project, + the NetBSD Project , - NetBSD Developer Documentation: Release Engineering - http://www.NetBSD.org/developers/releng/index.html + + NetBSD Developer Documentation: Release Engineering + http://www.NetBSD.org/developers/releng/index.html - , and John Baldwin's proposed release engineering process notes. + , and John + Baldwin's proposed release engineering process notes. - John Baldwin's &os; Release Engineering Proposal https://people.FreeBSD.org/~jhb/docs/releng.txt - -
+ + John Baldwin's &os; Release Engineering Proposal + https://people.FreeBSD.org/~jhb/docs/releng.txt + + + + + +