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 50107) +++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml (revision 50108) @@ -1,361 +1,362 @@ head/"> stable/"> stable/11/"> releng/"> releng/11.0/"> +release/11.0.0/"> ]>
&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 &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. 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. 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. &release.terminology; &release.major.version; &release.minor.version; &release.building; &release.mirrors; Wrapping up the Release Cycle This section describes general post-release tasks.
Index: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml =================================================================== --- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml (revision 50107) +++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml (revision 50108) @@ -1,237 +1,247 @@ Building &os; Installation Media This section describes the general procedures producing &os; development snapshots and releases. Release Build Scripts This section describes the build scripts used by &team.re; to produce development snapshots and releases. The <filename>release.sh</filename> Script Prior to &os; 9.0-RELEASE, src/release/Makefile was updated to support &man.bsdinstall.8;, and the src/release/generate-release.sh script was introduced as a wrapper to automate invoking the &man.release.7; targets. Prior to &os; 9.2-RELEASE, src/release/release.sh was introduced, which heavily based on src/release/generate-release.sh included support to specify configuration files to override various options and environment variables. Support for configuration files provided support for cross building each architecture for a release by specifying a separate configuration file for each invocation. As a brief example of using src/release/release.sh to build a single release in /scratch: &prompt.root; /bin/sh /usr/src/release/release.sh As a brief example of using src/release/release.sh to build a single, cross-built release using a different target directory, create a custom release.conf containing: # release.sh configuration for powerpc/powerpc64 CHROOTDIR="/scratch-powerpc64" TARGET="powerpc" TARGET_ARCH="powerpc64" KERNEL="GENERIC64" Then invoke src/release/release.sh as: &prompt.root; /bin/sh /usr/src/release/release.sh -c $HOME/release.conf See &man.release.7; and src/release/release.conf.sample for more details and example usage. The <filename>thermite.sh</filename> Wrapper Script In order to make cross building the full set of architectures supported on a given branch faster, easier, and reduce human error factors, a wrapper script around src/release/release.sh was written to iterate through the various combinations of architectures and invoke src/release/release.sh using a configuration file specific to that architecture. The wrapper script is called thermite.sh, which is available in the &os; Subversion repository at svn://svn.freebsd.org/base/user/gjb/thermite/, in addition to configuration files used to build &branch.head; and &branch.stablex; development snapshots. Using thermite.sh is covered in and . Each architecture and individual kernel have their own configuration file used by release.sh. Each branch has its own defaults-X.conf configuration which contains entries common throughout each architecture, where overrides or special variables are set and/or overridden in the per-build files. The per-build configuration file naming scheme is in the form of ${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf, where the uppercase variables are equivalent to what &man.make.1; uses in the build system, and lowercase variables are set within the configuration files, mapping to the major version of the respective branch. Each branch also has its own builds-X.conf configuration, which is used by thermite.sh. The thermite.sh script iterates through each ${revision}, ${TARGET_ARCH}, ${KERNCONF}, and ${type} value, creating a master list of what to build. However, a given combination from the list will only be built if the respective configuration file exists, which is where the naming scheme above is relevant. There are two paths of file sourcing: builds-11.conf -> main.conf This controls thermite.sh behavior 11-amd64-GENERIC-snap.conf -> defaults-11.conf -> main.conf This controls release/release.sh behavior within the build &man.chroot.8; The builds-11.conf, defaults-11.conf, and main.conf configuration files exist to reduce repetition between the various per-build files. Building &os; Development Snapshots The official release build machines have a specific filesystem layout, which using ZFS, thermite.sh takes heavy advantage of with clones and snapshots, ensuring a pristine build environment. The build scripts reside in /releng/scripts-snapshot/scripts or /releng/scripts-release/scripts respectfully, to avoid collisions between an RC build from a releng branch versus a STABLE snapshot from the respective stable branch. A separate dataset exists for the final build images, /snap/ftp. This directory contains both snapshots and releases directories. They are only used if the EVERYTHINGISFINE variable is defined in main.conf. The EVERYTHINGISFINE variable name was chosen to avoid colliding with a variable that might be possibly set in the user environment, accidentally enabling the behavior that depends on it being defined. As thermite.sh iterates through the master list of combinations and locates the per-build configuration file, a ZFS dataset is created under /releng, such as /releng/12-amd64-GENERIC-snap. The src/, ports/, and doc/ trees are checked out to separate ZFS datasets, such as /releng/12-src-snap, which are then cloned and mounted into the respective build datasets. This is done to avoid checking out a given tree more than once. Assuming these filesystem paths, thermite.sh would be invoked as: &prompt.root; cd /releng/scripts-snapshot/scripts &prompt.root; ./setrev.sh -b &branch.stablex; &prompt.root; ./zfs-setup.sh -c ./builds-11.conf &prompt.root; ./thermite.sh -c ./builds-11.conf Building &os; Releases Similar to building &os; development snapshots, thermite.sh would be invoked the same way. The difference between development snapshots and release builds, BETA and RC, included, is that the &man.chroot.8; configuration files must be named with release instead of snap as the "type", as mentioned above. In addition, the BUILDTYPE and types must be changed from snap to release in defaults-11.conf and builds-11.conf, respectively. When building BETA, RC, and the final RELEASE, also statically set BUILDSVNREV to the revision on the branch reflecting the name change, BUILDDATE to the date the builds are started in YYYYMMDD format. If the doc/ and ports/ trees have been tagged, also set PORTBRANCH and DOCBRANCH to the relevant tag path in the Subversion repository, replacing HEAD with the last changed revision. Also set releasesrc in builds-11.conf to the relevant branch, such as &branch.stablex; or &branch.relengx;. + + After building the final RELEASE, the + &branch.relengx; branch is tagged as &branch.releasex; using the + revision from which the RELEASE was built. + Similar to creating the &branch.stablex; and &branch.relengx; + branches, this is done with svn cp. From the + repository root: + + &prompt.user; svn cp ^/&branch.relengx;@r306420 ^/&branch.releasex; +&prompt.user; svn commit &branch.releasex;