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 50099)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml (revision 50100)
@@ -1,170 +1,210 @@
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;
+
+
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.
Index: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml
===================================================================
--- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml (revision 50099)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml (revision 50100)
@@ -1,202 +1,196 @@
Release from &branch.head;
This section describes the general procedures of the &os;
release cycle from the &branch.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
&branch.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.
Creating the &branch.stablex; Branch
When creating the &branch.stable; branch, several changes
are required in both the new &branch.stable; branch and the
&branch.head; branch. The files listed are relative to the
repository root. To create the new &branch.stablex; branch
in Subversion:
&prompt.user; svn cp head &branch.stablex;
Once the &branch.stablex; branch has been committed, make
the following edits:
File to Edit
What to Change
stable/11/UPDATING
Update the &os; version, and remove the notice
about WITNESS
stable/11/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
#ifndef MALLOC_PRODUCTION
#define MALLOC_PRODUCTION
#endif
stable/11/sys/*/conf/GENERIC*
Remove debugging support
stable/11/release/release.conf.sample
Update SRCBRANCH
stable/11/sys/*/conf/GENERIC-NODEBUG
Remove these kernel configurations
stable/11/sys/conf/newvers.sh
Update the BRANCH value to
reflect BETA1
Then in the &branch.head; branch, which will now become
a new major version:
File to Edit
What to Change
head/UPDATING
Update the &os; version
head/gnu/usr.bin/groff/tmac/mdoc.local.in
Add the new &os; version
head/sys/conf/newvers.sh
Update the BRANCH value to
reflect CURRENT, and increment
REVISION
head/Makefile.inc1
Update TARGET_TRIPLE
head/sys/sys/param.h
Update __FreeBSD_version
head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
Update
__FreeBSD_cc_version
head/gnu/usr.bin/cc/cc_tools/freebsd-native.h
Update FBSD_MAJOR and
FBSD_CC_VER
head/contrib/gcc/config.gcc
Append the
freebsd<version>.h
section
head/release/Makefile
Remove the
debug.witness.trace entries
head/release/doc/en_US.ISO8859-1/readme/article.xml
Replace &a.current; with &a.stable;
head/release/doc/share/xml/release.ent
?>
head/lib/clang/clang.build.mk
Uncomment -DNDEBUG
head/lib/clang/freebsd_cc_version.h
Update
FREEBSD_CC_VERSION
-
-
- Code Thaw in &branch.head;
-
-
-
Index: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml
===================================================================
--- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (revision 50099)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (revision 50100)
@@ -1,180 +1,174 @@
Release from &branch.stable;
This section describes the general procedures of the &os;
release cycle from an extablished &branch.stable; branch.
&os; <literal>stable</literal> Branch Code Slush
In preparation for the code freeze on
a stable branch, several files need to be
updated to reflect the release cycle is officially in
progress. These files are all relative to the top-most level of
the stable branch:
File to Edit
What to Change
gnu/usr.bin/groff/tmac/mdoc.local.in
Add the new &os; version
sys/conf/newvers.sh
Update the BRANCH value to
reflect PRERELEASE
Makefile.inc1
Update TARGET_TRIPLE
&os; <literal>BETA</literal> Builds
Following the code slush, the next phase of the release
cycle is the code freeze. This is the point at which all
commits to the stable branch require explicit approval from
the &team.re;. This is enforced by pre-commit hooks in the
Subversion repository by editing
base/svnadmin/conf/approvers to include
a regular expression matching the &branch.stablex; branch for
the release:
^/&branch.stablex; re
There are two general exceptions to requiring commit
approval during the release cycle. The first is any change
that needs to be committed by the Release Engineer in order
to proceed with the day-to-day workflow of the release cycle,
the other is security fixes that may occur during the release
cycle.
Once the code freeze is in effect, the next build from the
branch is labeled BETA1. This is done by
updating the BRANCH value in
sys/conf/newvers.sh from
PRERELEASE to
BETA1.
Once this is done, the first set of BETA
builds are started. Subsequent BETA builds
do not require updates to any files other than
sys/conf/newvers.sh, incrementing the
BETA build number.
Creating the &branch.relengx; Branch
When the first RC (Release Candidate)
build is ready to begin, the &branch.releng; branch is created.
This is a multi-step process that must be done in a specific
order, in order to avoid anomalies such as overlaps with
__FreeBSD_version values, for example. The
paths listed below are relative to the repository root. The
order of commits and what to change are:
&prompt.user; svn cp &branch.stablex; &branch.relengx;
File to Edit
What to Change
releng/11.0/sys/conf/newvers.sh
Change
BETAX
to RC1
releng/11.0/sys/sys/param.h
Update __FreeBSD_version
releng/11.0/etc/pkg/FreeBSD.conf
Replace latest with
quarterly as the default package
repository location
releng/11.0/release/pkg_repos/release-dvd.conf
Replace latest with
quarterly as the default package
repository location
stable/11/sys/conf/newver.sh
Update
BETAX with
PRERELEASE
stable/11/sys/sys/param.h
Update __FreeBSD_version
svnadmin/conf/approvers
Add a new approvers line for the releng
branch as was done for the stable branch
&prompt.user; svn propdel -R svn:mergeinfo &branch.relengx;
&prompt.user; svn commit &branch.relengx;
&prompt.user; svn commit &branch.stablex;
Now that two new __FreeBSD_version values
exist, also update
head/en_US.ISO8859-1/books/porters-handbook/versions/chapter.xml
in the Documentation Project repository.
After the first RC build has completed
and tested, the &branch.stable; branch can be
thawed
by removing (or commenting) the
^/&branch.stablex; entry in
svnadmin/conf/approvers.
-
-
- &os; <literal>RC</literal> Builds
-
-
-