Index: head/en_US.ISO8859-1/articles/freebsd-releng/article.xml =================================================================== --- head/en_US.ISO8859-1/articles/freebsd-releng/article.xml (revision 53239) +++ head/en_US.ISO8859-1/articles/freebsd-releng/article.xml (revision 53240) @@ -1,493 +1,497 @@ head/"> stable/"> stable/12/"> releng/"> releng/12.0/"> release/12.0.0/"> 12.0"> ]>
&os; Release Engineering Glen Barber The &os; Foundation Rubicon Communications, LLC (Netgate)
gjb@FreeBSD.org
 &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 &branch.head; branch, which reflects the top of the source tree. After a reasonable testing period, changes can then be merged to the &branch.stable; branches. The default minimum timeframe before merging to &branch.stable; branches is three (3) days. Although a general rule to wait a minimum of three days before merging from &branch.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 &branch.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 &branch.stable; branches, approximately every two (2) years, a release will be cut directly from &branch.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. Website Changes During the Release Cycle Terminology and general information, such as the code slush and code freeze, used throughout this document. The Release Engineering process for a dot-zero release. The Release Engineering process for a point release. Information related to the specific procedures to build installation medium. Procedures to publish installation medium. Wrapping up the release cycle. 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 &branch.head; slush: May 27, 2016 &branch.head; freeze: June 10, 2016 &branch.head; KBI freeze: June 24, 2016 doc/ tree slush [1]: June 24, 2016 Ports quarterly branch [2]: July 1, 2016 &branch.stablex; branch: July 8, 2016 doc/ tree tag [3]: July 8, 2016 BETA1 build starts: July 8, 2016 &branch.head; thaw: July 9, 2016 BETA2 build starts: July 15, 2016 BETA3 build starts [*]: July 22, 2016 &branch.relengx; branch: July 29, 2016 RC1 build starts: July 29, 2016 &branch.stablex; thaw: July 30, 2016 RC2 build starts: August 5, 2016 Final Ports package builds [4]: August 6, 2016 Ports release tag: August 12, 2016 RC3 build starts [*]: August 12, 2016 RELEASE build starts: August 19, 2016 RELEASE announcement: September 2, 2016 Items marked with "[*]" are "as needed". The doc/ tree slush is coordinated by the &team.doceng;. The Ports quarterly branch used is determined by when the final RC build is planned. A new quarterly branch is created on the first day of the quarter, so this metric should be used when taking the release cycle milestones into account. The quarterly branch is created by the &team.portmgr;. The doc/ tree is tagged by the &team.doceng;. The final Ports package build is done by the &team.portmgr; after the final (or what is expected to be final) RC build. If the release is being created from an existing &branch.stable; branch, the KBI freeze date can be excluded, since the KBI is already considered frozen on established &branch.stable; branches. When writing the release cycle schedule, a number of things need to be taken into consideration, in particular milestones where the target date depends on predefined milestones upon which there is a dependency. For example, the Ports Collection release tag originates from the active quarterly branch at the time of the last RC. This in part defines which quarterly branch is used, when the release tag can happen, and what revision of the ports tree is used for the final RELEASE build. 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. In order to keep track of blanket approvals, the &team.re; uses an internal repository to keep a running log of such requests, which defines the area upon which a blanket approval was granted, the author(s), when the blanket approval expires, and the reason the approval was granted. One example of this is granting blanket approval to release/doc/ to all &team.re; members until the final RC to update the release notes and other release-related documentation. The &team.re; also uses this repository to track pending approval requests that are received just prior to starting various builds during the release cycle, which the Release Engineer specifies the cutoff period with an email to the &os; developers. 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, especially if such dramatic changes do not exist in another branch. The schedule is also added to the Project website, in the doc/ repository, in head/en_US.ISO8859-1/htdocs/releases/&branch.revision;R/schedule.xml. This file is continuously updated as the release cycle progresses. In most cases, the schedule.xml can be copied from a prior release and updated accordingly. In addition to adding schedule.xml to the website, head/share/xml/navibar.ent and head/share/xml/release.ent are also updated to add the link to the schedule to various subpages, as well as enabling the link to the schedule on the Project website index page. The schedule is also linked from head/en_US.ISO8859-1/htdocs/releng/index.xml. Approximately one month prior to the scheduled code slush, the &team.re; sends a reminder email to the &os; Developers. Once the first builds of the release cycle are available, update the beta.local.where entity in head/en_US.ISO8859-1/htdocs/releases/&branch.revision;R/schedule.xml. replacing IGNORE with INCLUDE. If two parallel release cycles are happening at once, the beta2.local.where entity may be used instead. &release.terminology; &release.website; &release.major.version; &release.minor.version; &release.building; &release.mirrors; Wrapping up the Release Cycle This section describes general post-release tasks. Post-Release Errata Notices As the release cycle approaches conclusion, it is common to have several EN (Errata Notice) candidates to address issues that were discovered late in the cycle. Following the release, the &team.re; and the &team.secteam; revisit changes that were not approved prior to the final release, and depending on the scope of the change in question, may issue an EN. The actual process of issuing ENs is handled by the &team.secteam;. To request an Errata Notice after a release cycle has completed, it is most helpful to fill out the Errata Notice template, in particular the Background, Problem Description, Impact, and if applicable, Workaround sections. For Errata Notice requests immediately following the release, the request should be emailed to both &team.re; and &team.secteam;. Once the &branch.releng; branch has been handed over to &team.secteam; as described in , Errata Notice requests - should be sent to &team.secteam;. + should be sent to &team.secteam;. In either case, the email + should contain at least the patch against the &branch.releng; + branch (and the Errata Notice template, if it had been filled + in), or the revision(s) to be included in the Errata + Notice. Handoff to the &team.secteam; Roughly two weeks following the release, the Release Engineer updates svnadmin/conf/approvers changing the approver column from re to (so|security-officer) for the &branch.relengx; branch.