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 50078)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml (revision 50079)
@@ -1,366 +1,341 @@
head/">
stable/">
stable/11/">
releng/">
releng/11.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.
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
&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.
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;
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
-
-
-
-
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 (nonexistent)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml (revision 50079)
@@ -0,0 +1,75 @@
+
+
+
+ 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. See &man.release.7; and
+ src/release/release.conf.sample for more
+ details.
+
+
+
+ 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/user/gjb/thermite/,
+ in addition to configuration files used to build
+ &branch.head; and &branch.stablex; development
+ snapshots.
+
+
+
+
+ Building &os; Development Snapshots
+
+
+
+
+
+ Building &os; Releases
+
+
+
+
Property changes on: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml
___________________________________________________________________
Added: svn:keywords
## -0,0 +1 ##
+FreeBSD=%H
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/xml
\ No newline at end of property