Index: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml =================================================================== --- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml (revision 49889) +++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml (revision 49890) @@ -1,427 +1,427 @@ ]>
&os; Release Engineering &tm-attrib.freebsd; &tm-attrib.intel; &tm-attrib.general; $FreeBSD$ This article describes the release engineering process of the &os; Project. Introduction to the &os; Release Engineering Process Development of &os; has a very specific workflow. In general, all changes to the &os; base system are committed to the head/ branch, which reflects the top of the source tree. After a reasonable testing period, changes can then be merged to the stable/ branches. The default minimum timeframe before merging to stable/ branches is three (3) days. Although a general rule to wait a minimum of three days before merging from head/, there are a few special circumstances where an immediate merge may be necessary, such as a critical security fix, or a bug fix that directly inhibits the release build process. After several months, and the number of changes in the stable/ branch have grown significantly, it is time to release the next version of &os;. These releases have been historically referred to as point releases. In between releases from the stable/ branches, approximately every two (2) years, a release will be cut directly from head/. These releases have been historically referred to as dot-zero releases. This article will highlight the workflow and responsibilities of the &team.re; for both dot-zero and point' releases. The following sections of this article describe: General information and preparation before starting the release cycle. General information about the code slush and code freeze. The Release Engineering process for a dot-zero release. The Release Engineering process for a point release. Wrapping up the release cycle. Information related to the specific procedures to build installation medium. General Information and Preparation Approximately two months before the start of the release cycle, the &team.re; decides on a schedule for the release. The schedule includes the various milestone points of the release cycle, such as freeze dates, branch dates, and build dates. For example: Milestone Anticipated Date head/ slush: August 24 head/ freeze: September 7 head/ KBI freeze: September 21 stable/10/ branch: October 10 BETA1 build starts: October 12 BETA2 build starts: October 18 releng/10.0/ branch: November 1 RC1 build starts: November 1 RC2 build starts: November 9 RELEASE build starts: November 19 If the release is being created from an existing stable/ branch, the KBI freeze date can be excluded, since the KBI is already considered frozen on established stable/ branches. After general agreement on the schedule, the &team.re; emails the schedule to the &os; Developers. It is somewhat typical that many developers will inform the &team.re; about various works-in-progress. In some cases, an extension for the in-progress work will be requested, and in other cases, a request for blanket approval to a particular subset of the tree will be made. When such requests are made, it is important to make sure timelines (even if estimated) are discussed. For blanket approvals, the length of time for the blanket approval should be made clear. For example, a &os; developer may request blanket approvals from the start of the code slush until the start of the -RC builds. Depending on the underlying set of code in question, and the overall impact the set of code has on &os; as a whole, such requests may be approved or denied by the &team.re;. The same applies to work-in-progress extensions. For example, in-progress work for a new device driver that is otherwise isolated from the rest of the tree may be granted an extension. A new scheduler, however, may not be feasible, - expecially if such dramatic changes do not exist in another + especially if such dramatic changes do not exist in another branch. Freezing the &os; Source Tree This section describes the general procedures related to the code slush and code freeze during the &os; release cycle. This applies to both head/ and stable/ branches. The Code Slush Approximately one month prior to the scheduled code slush, the &team.re; sends a reminder email to the &os; Developers. Although the code slush is technically not a hard freeze on the tree, the &team.re; requests that bugs in the existing code base take priority over new features. The code slush does not enforce commit approvals to the branch. The Code Freeze Approximately one week prior to the scheduled code freeze, the &team.re; sends a reminder email to the &os; Developers. The code freeze marks the point in time where all commits to the branch require explicit approval from the &team.re;. The &os; Subversion repository contains several hooks to perform sanity checks before any commit is actually committed to the tree. One of these hooks will evaluate if committing to a particular branch requires specific approval. To enforce commit approvals by the &team.re;, the Release Engineer updates base/svnadmin/conf/approvers, and commits the change back to the repository. Once this is done, any change to the branch must include an Approved by: line in the commit message. The Approved by: line must match the second column in base/svnadmin/conf/approvers, otherwise the commit will be rejected by the repository hooks. Release from <literal>head/</literal> This section describes the general procedures of the &os; release cycle from the head/ branch. &os; <quote><literal>ALPHA</literal></quote> Builds Starting with the &os; 10.0-RELEASE cycle, the notion of -ALPHA builds was introduced. Unlike the -BETA and -RC builds, -ALPHA builds are not included in the &os; Release schedule. The idea behind -ALPHA builds is to provide regular &os;-provided builds before the creation of the stable/ branch. &os; -ALPHA snapshots should be built approximately once a week. For the first -ALPHA build, the BRANCH value in sys/conf/newvers.sh needs to be changed from CURRENT to ALPHA1. For subsequent -ALPHA builds, increment each ALPHAN value by one. See for information on building the -ALPHA images. The <acronym>KBI</acronym>/<acronym>KPI</acronym> Freeze   Creating the <literal>stable/<replaceable>N</replaceable></literal> Branch   Code Thaw in <literal>head/</literal>   Release from <literal>stable/</literal> This section describes the general procedures of the &os; release cycle from an extablished stable/ branch. &os; <literal>-BETA</literal> Builds   Creating the <literal>releng/<replaceable>N.M/</replaceable></literal> Branch   Code Thaw in the <literal>stable/<replaceable>N/</replaceable></literal> Branch   &os; <literal>-RC</literal> Builds   The &os; <literal>-RELEASE</literal> Build   Wrapping up the Release Cycle This section describes general post-release tasks. Building the Installer Images This section describes how to build the installation images as part of the &os; release cycle. The <filename>release.sh</filename> Script   The <filename>release.conf</filename> Configuration   Information About <filename>release.sh</filename> and <filename>release.conf</filename> for Specific Architectures