Merge the ^/user/gjb/releng-rewrite branch to ^/head, which updates
the Release Engineering process of the Project. Sponsored by: The FreeBSD Foundation
This commit is contained in:
Glen Barber
parent
d08a502f93
commit
2fad27b2f0
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=50119
11 changed files with 1245 additions and 8 deletions
|
|
@ -11,6 +11,7 @@ SUBDIR+= explaining-bsd
|
|||
SUBDIR+= filtering-bridges
|
||||
SUBDIR+= fonts
|
||||
SUBDIR+= freebsd-questions
|
||||
SUBDIR+= freebsd-releng
|
||||
SUBDIR+= freebsd-update-server
|
||||
SUBDIR+= geom-class
|
||||
SUBDIR+= gjournal-desktop
|
||||
|
|
|
|||
20
en_US.ISO8859-1/articles/freebsd-releng/Makefile
Normal file
20
en_US.ISO8859-1/articles/freebsd-releng/Makefile
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
#
|
||||
# $FreeBSD$
|
||||
#
|
||||
# Article: FreeBSD Release Engineering
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html html-split
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.xml
|
||||
|
||||
CSS_SHEET_ADDITIONS=extra.css
|
||||
|
||||
URL_RELPREFIX?= ../../../..
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
415
en_US.ISO8859-1/articles/freebsd-releng/article.xml
Normal file
415
en_US.ISO8859-1/articles/freebsd-releng/article.xml
Normal file
|
|
@ -0,0 +1,415 @@
|
|||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
|
||||
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [
|
||||
|
||||
<!-- local entities -->
|
||||
<!ENTITY team.doceng "&os; Documentation Engineering Team">
|
||||
<!ENTITY team.portmgr "&os; Ports Management Team">
|
||||
<!ENTITY team.postmaster "&os; Postmaster Team">
|
||||
<!ENTITY team.re "&os; Release Engineering Team">
|
||||
<!ENTITY team.secteam "&os; Security Team">
|
||||
<!ENTITY branch.head "<literal xmlns='http://docbook.org/ns/docbook'>head/</literal>">
|
||||
<!ENTITY branch.stable "<literal xmlns='http://docbook.org/ns/docbook'>stable/</literal>">
|
||||
<!ENTITY branch.stablex "<literal xmlns='http://docbook.org/ns/docbook'>stable/<replaceable>11</replaceable>/</literal>">
|
||||
<!ENTITY branch.releng "<literal xmlns='http://docbook.org/ns/docbook'>releng/</literal>">
|
||||
<!ENTITY branch.relengx "<literal xmlns='http://docbook.org/ns/docbook'>releng/<replaceable>11.0</replaceable>/</literal>">
|
||||
<!ENTITY branch.releasex "<literal xmlns='http://docbook.org/ns/docbook'>release/<replaceable>11.0.0</replaceable>/</literal>">
|
||||
<!ENTITY branch.revision "<replaceable xmlns='http://docbook.org/ns/docbook'>11.0</replaceable>">
|
||||
|
||||
<!-- Externally included files -->
|
||||
<!ENTITY release.building SYSTEM "./releng-building.xml">
|
||||
<!ENTITY release.major.version SYSTEM "./releng-major-version.xml">
|
||||
<!ENTITY release.minor.version SYSTEM "./releng-minor-version.xml">
|
||||
<!ENTITY release.mirrors SYSTEM "./releng-mirrors.xml">
|
||||
<!ENTITY release.terminology SYSTEM "./releng-terminology.xml">
|
||||
]>
|
||||
<article xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||||
xml:lang="en">
|
||||
|
||||
<info>
|
||||
<title>&os; Release Engineering</title>
|
||||
|
||||
<legalnotice xml:id="trademarks" role="trademarks">
|
||||
&tm-attrib.freebsd;
|
||||
&tm-attrib.intel;
|
||||
&tm-attrib.general;
|
||||
</legalnotice>
|
||||
|
||||
<pubdate>$FreeBSD$</pubdate>
|
||||
|
||||
<abstract>
|
||||
<para>This article describes the release engineering process of
|
||||
the &os; Project.</para>
|
||||
</abstract>
|
||||
</info>
|
||||
|
||||
<sect1 xml:id="introduction">
|
||||
<title>Introduction to the &os; Release Engineering
|
||||
Process</title>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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 <quote>point</quote>
|
||||
releases.</para>
|
||||
|
||||
<para>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 <quote>dot-zero</quote>
|
||||
releases.</para>
|
||||
|
||||
<para>This article will highlight the workflow and
|
||||
responsibilities of the &team.re; for both
|
||||
<quote>dot-zero</quote> and <quote>point</quote>'
|
||||
releases.</para>
|
||||
|
||||
<para>The following sections of this article describe:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><xref linkend="releng-prep"/></term>
|
||||
|
||||
<listitem>
|
||||
<para>General information and preparation before
|
||||
starting the release cycle.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><xref linkend="releng-terms"/></term>
|
||||
|
||||
<listitem>
|
||||
<para>Terminology and general information, such as the
|
||||
<quote>code slush</quote> and <quote>code
|
||||
freeze</quote>, used throughout this document.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><xref linkend="releng-head"/></term>
|
||||
|
||||
<listitem>
|
||||
<para>The Release Engineering process for a
|
||||
<quote>dot-zero</quote> release.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><xref linkend="releng-stable"/></term>
|
||||
|
||||
<listitem>
|
||||
<para>The Release Engineering process for a
|
||||
<quote>point</quote> release.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><xref linkend="releng-building"/></term>
|
||||
|
||||
<listitem>
|
||||
<para>Information related to the specific procedures to
|
||||
build installation medium.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><xref linkend="releng-mirrors"/></term>
|
||||
|
||||
<listitem>
|
||||
<para>Procedures to publish installation medium.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><xref linkend="releng-wrapup"/></term>
|
||||
|
||||
<listitem>
|
||||
<para>Wrapping up the release cycle.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="releng-prep">
|
||||
<title>General Information and Preparation</title>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<informaltable frame="none" pgwide="0">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Milestone</entry>
|
||||
<entry>Anticipated Date</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>&branch.head; slush:</entry>
|
||||
<entry>May 27, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>&branch.head; freeze:</entry>
|
||||
<entry>June 10, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>&branch.head; KBI freeze:</entry>
|
||||
<entry>June 24, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>doc/</literal> tree slush [1]:</entry>
|
||||
<entry>June 24, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>Ports quarterly branch [2]:</entry>
|
||||
<entry>July 1, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>&branch.stablex; branch:</entry>
|
||||
<entry>July 8, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>doc/</literal> tree tag [3]:</entry>
|
||||
<entry>July 8, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>BETA1 build starts:</entry>
|
||||
<entry>July 8, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>&branch.head; thaw:</entry>
|
||||
<entry>July 9, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>BETA2 build starts:</entry>
|
||||
<entry>July 15, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>BETA3 build starts [*]:</entry>
|
||||
<entry>July 22, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>&branch.relengx; branch:</entry>
|
||||
<entry>July 29, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>RC1 build starts:</entry>
|
||||
<entry>July 29, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>&branch.stablex; thaw:</entry>
|
||||
<entry>July 30, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>RC2 build starts:</entry>
|
||||
<entry>August 5, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>Final Ports package builds [4]:</entry>
|
||||
<entry>August 6, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>Ports release tag:</entry>
|
||||
<entry>August 12, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>RC3 build starts [*]:</entry>
|
||||
<entry>August 12, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>RELEASE build starts:</entry>
|
||||
<entry>August 19, 2016</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>RELEASE announcement:</entry>
|
||||
<entry>September 2, 2016</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<note>
|
||||
<para>Items marked with "[*]" are "as
|
||||
needed".</para>
|
||||
</note>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The <literal>doc/</literal> tree slush is coordinated by
|
||||
the &team.doceng;.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The Ports quarterly branch used is determined by when
|
||||
the final <acronym>RC</acronym> 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;.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <literal>doc/</literal> tree is tagged by the
|
||||
&team.doceng;.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The final Ports package build is done by the
|
||||
&team.portmgr; after the final (or what is expected to be
|
||||
final) <acronym>RC</acronym> build.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<note>
|
||||
<para>If the release is being created from an existing
|
||||
&branch.stable; branch, the <acronym>KBI</acronym>
|
||||
freeze date can be excluded, since the <acronym>KBI</acronym>
|
||||
is already considered frozen on established
|
||||
&branch.stable; branches.</para>
|
||||
</note>
|
||||
|
||||
<para>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 <acronym>RC</acronym>. 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
|
||||
<literal>RELEASE</literal> build.</para>
|
||||
|
||||
<para>After general agreement on the schedule, the &team.re;
|
||||
emails the schedule to the &os; Developers.</para>
|
||||
|
||||
<para>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 <quote>blanket approval</quote>
|
||||
to a particular subset of the tree will be made.</para>
|
||||
|
||||
<para>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 <acronym>RC</acronym> builds.</para>
|
||||
|
||||
<para>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;.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The schedule is also added to the Project website, in the
|
||||
<literal>doc/</literal> repository, in
|
||||
<filename>head/en_US.ISO8859-1/htdocs/releases/&branch.revision;R/schedule.xml</filename>.
|
||||
This file is continuously updated as the release cycle
|
||||
progresses.</para>
|
||||
|
||||
<note>
|
||||
<para>In most cases, the <filename>schedule.xml</filename> can
|
||||
be copied from a prior release and updated accordingly.</para>
|
||||
</note>
|
||||
|
||||
<para>The schedule is also linked from
|
||||
<filename>head/en_US.ISO8859-1/htdocs/releng/index.xml</filename>.</para>
|
||||
|
||||
<para>Approximately one month prior to the scheduled <quote>code
|
||||
slush</quote>, the &team.re; sends a reminder email to the
|
||||
&os; Developers.</para>
|
||||
|
||||
<para>Once the first builds of the release cycle are available,
|
||||
update the <literal>beta.local.where</literal> entity in
|
||||
<filename>head/en_US.ISO8859-1/htdocs/releases/&branch.revision;R/schedule.xml</filename>.
|
||||
replacing <literal>IGNORE</literal> with
|
||||
<literal>INCLUDE</literal>.</para>
|
||||
|
||||
<note>
|
||||
<para>If two parallel release cycles are happening at once, the
|
||||
<literal>beta2.local.where</literal> entity may be used
|
||||
instead.</para>
|
||||
</note>
|
||||
</sect1>
|
||||
|
||||
&release.terminology;
|
||||
&release.major.version;
|
||||
&release.minor.version;
|
||||
&release.building;
|
||||
&release.mirrors;
|
||||
|
||||
<sect1 xml:id="releng-wrapup">
|
||||
<title>Wrapping up the Release Cycle</title>
|
||||
|
||||
<para>This section describes general post-release tasks.</para>
|
||||
|
||||
<sect2 xml:id="releng-wrapup-en">
|
||||
<title>Post-Release Errata Notices</title>
|
||||
|
||||
<para>As the release cycle approaches conclusion, it is common
|
||||
to have several <acronym>EN</acronym> (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 <acronym>EN</acronym>.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-wrapup-handoff">
|
||||
<title>Handoff to the &team.secteam;</title>
|
||||
|
||||
<para>Roughly two weeks following the release, the Release
|
||||
Engineer updates <filename>svnadmin/conf/approvers</filename>
|
||||
changing the approver column from <literal>re</literal> to
|
||||
<literal>(so|security-officer)</literal> for the
|
||||
&branch.relengx; branch.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</article>
|
||||
7
en_US.ISO8859-1/articles/freebsd-releng/extra.css
Normal file
7
en_US.ISO8859-1/articles/freebsd-releng/extra.css
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
/*
|
||||
* $FreeBSD$
|
||||
*/
|
||||
|
||||
DIV.TITLEPAGE {
|
||||
text-align: center;
|
||||
}
|
||||
247
en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml
Normal file
247
en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml
Normal file
|
|
@ -0,0 +1,247 @@
|
|||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
<sect1 xml:id="releng-building">
|
||||
<title>Building &os; Installation Media</title>
|
||||
|
||||
<para>This section describes the general procedures producing &os;
|
||||
development snapshots and releases.</para>
|
||||
|
||||
<sect2 xml:id="releng-build-scripts">
|
||||
<title>Release Build Scripts</title>
|
||||
|
||||
<para>This section describes the build scripts used by &team.re;
|
||||
to produce development snapshots and releases.</para>
|
||||
|
||||
<sect3 xml:id="releng-build-scripts-single">
|
||||
<title>The <filename>release.sh</filename> Script</title>
|
||||
|
||||
<para>Prior to &os; 9.0-RELEASE,
|
||||
<filename>src/release/Makefile</filename> was updated to
|
||||
support &man.bsdinstall.8;, and the
|
||||
<filename>src/release/generate-release.sh</filename> script
|
||||
was introduced as a wrapper to automate invoking the
|
||||
&man.release.7; targets.</para>
|
||||
|
||||
<para>Prior to &os; 9.2-RELEASE,
|
||||
<filename>src/release/release.sh</filename> was introduced,
|
||||
which heavily based on
|
||||
<filename>src/release/generate-release.sh</filename> 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.</para>
|
||||
|
||||
<para>As a brief example of using
|
||||
<filename>src/release/release.sh</filename> to build a single
|
||||
release in <filename
|
||||
class="directory">/scratch</filename>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/bin/sh /usr/src/release/release.sh</userinput></screen>
|
||||
|
||||
<para>As a brief example of using
|
||||
<filename>src/release/release.sh</filename> to build a single,
|
||||
cross-built release using a different target directory, create
|
||||
a custom <filename>release.conf</filename> containing:</para>
|
||||
|
||||
<programlisting># release.sh configuration for powerpc/powerpc64
|
||||
CHROOTDIR="/scratch-powerpc64"
|
||||
TARGET="powerpc"
|
||||
TARGET_ARCH="powerpc64"
|
||||
KERNEL="GENERIC64"</programlisting>
|
||||
|
||||
<para>Then invoke <filename>src/release/release.sh</filename>
|
||||
as:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/bin/sh /usr/src/release/release.sh -c <replaceable>$HOME/release.conf</replaceable></userinput></screen>
|
||||
|
||||
<para>See &man.release.7; and
|
||||
<filename>src/release/release.conf.sample</filename> for more
|
||||
details and example usage.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3 xml:id="releng-build-scripts-multiple">
|
||||
<title>The <filename>thermite.sh</filename> Wrapper
|
||||
Script</title>
|
||||
|
||||
<para>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
|
||||
<filename>src/release/release.sh</filename> was written to
|
||||
iterate through the various combinations of architectures and
|
||||
invoke <filename>src/release/release.sh</filename> using
|
||||
a configuration file specific to that architecture.</para>
|
||||
|
||||
<para>The wrapper script is called
|
||||
<filename>thermite.sh</filename>, which is available in the
|
||||
&os; Subversion repository at
|
||||
<literal>svn://svn.freebsd.org/base/user/gjb/thermite/</literal>,
|
||||
in addition to configuration files used to build
|
||||
&branch.head; and &branch.stablex; development
|
||||
snapshots.</para>
|
||||
|
||||
<para>Using <filename>thermite.sh</filename> is covered in <xref
|
||||
linkend="releng-build-snapshot"/> and <xref
|
||||
linkend="releng-build-release"/>.</para>
|
||||
|
||||
<para>Each architecture and individual kernel have their own
|
||||
configuration file used by <filename>release.sh</filename>.
|
||||
Each branch has its own <filename>defaults-X.conf</filename>
|
||||
configuration which contains entries common throughout each
|
||||
architecture, where overrides or special variables are set
|
||||
and/or overridden in the per-build files.</para>
|
||||
|
||||
<para>The per-build configuration file naming scheme is in the
|
||||
form of
|
||||
<filename>${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf</filename>,
|
||||
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.</para>
|
||||
|
||||
<para>Each branch also has its own
|
||||
<filename>builds-X.conf</filename> configuration, which is
|
||||
used by <filename>thermite.sh</filename>. The
|
||||
<filename>thermite.sh</filename> 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.</para>
|
||||
|
||||
<para>There are two paths of file sourcing:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>builds-<replaceable>11</replaceable>.conf</filename>
|
||||
-> <filename>main.conf</filename></para>
|
||||
<para>This controls <filename>thermite.sh</filename>
|
||||
behavior</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename><replaceable>11</replaceable>-<replaceable>amd64</replaceable>-<replaceable>GENERIC</replaceable>-<replaceable>snap</replaceable>.conf</filename>
|
||||
->
|
||||
<filename>defaults-<replaceable>11</replaceable>.conf</filename>
|
||||
-> <filename>main.conf</filename></para>
|
||||
<para>This controls <filename>release/release.sh</filename>
|
||||
behavior within the build &man.chroot.8;</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<para>The
|
||||
<filename>builds-<replaceable>11</replaceable>.conf</filename>,
|
||||
<filename>defaults-<replaceable>11</replaceable>.conf</filename>,
|
||||
and <filename>main.conf</filename> configuration files exist
|
||||
to reduce repetition between the various per-build
|
||||
files.</para>
|
||||
</note>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-build-snapshot">
|
||||
<title>Building &os; Development Snapshots</title>
|
||||
|
||||
<para>The official release build machines have a specific
|
||||
filesystem layout, which using <acronym>ZFS</acronym>,
|
||||
<filename>thermite.sh</filename> takes heavy advantage of with
|
||||
clones and snapshots, ensuring a pristine build
|
||||
environment.</para>
|
||||
|
||||
<para>The build scripts reside in <filename
|
||||
class="directory">/releng/scripts-snapshot/scripts</filename>
|
||||
or <filename
|
||||
class="directory">/releng/scripts-release/scripts</filename>
|
||||
respectfully, to avoid collisions between an
|
||||
<acronym>RC</acronym> build from a releng branch versus
|
||||
a <literal>STABLE</literal> snapshot from the respective stable
|
||||
branch.</para>
|
||||
|
||||
<para>A separate dataset exists for the final build images,
|
||||
<filename class="directory">/snap/ftp</filename>. This
|
||||
directory contains both snapshots and releases directories.
|
||||
They are only used if the <literal>EVERYTHINGISFINE</literal>
|
||||
variable is defined in <filename>main.conf</filename>.</para>
|
||||
|
||||
<note>
|
||||
<para>The <literal>EVERYTHINGISFINE</literal> 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.</para>
|
||||
</note>
|
||||
|
||||
<para>As <filename>thermite.sh</filename> iterates through the
|
||||
master list of combinations and locates the per-build
|
||||
configuration file, a <acronym>ZFS</acronym> dataset is created
|
||||
under <filename class="directory">/releng</filename>, such as
|
||||
<filename
|
||||
class="directory">/releng/12-amd64-GENERIC-snap</filename>.
|
||||
The <literal>src/</literal>, <literal>ports/</literal>, and
|
||||
<literal>doc/</literal> trees are checked out to separate
|
||||
<acronym>ZFS</acronym> datasets, such as <filename
|
||||
class="directory">/releng/12-src-snap</filename>, which are
|
||||
then cloned and mounted into the respective build datasets.
|
||||
This is done to avoid checking out a given tree more than
|
||||
once.</para>
|
||||
|
||||
<para>Assuming these filesystem paths,
|
||||
<filename>thermite.sh</filename> would be invoked as:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd /releng/scripts-snapshot/scripts</userinput>
|
||||
&prompt.root; <userinput>./setrev.sh -b &branch.stablex;</userinput>
|
||||
&prompt.root; <userinput>./zfs-setup.sh -c ./builds-<replaceable>11</replaceable>.conf</userinput>
|
||||
&prompt.root; <userinput>./thermite.sh -c ./builds-<replaceable>11</replaceable>.conf</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-build-release">
|
||||
<title>Building &os; Releases</title>
|
||||
|
||||
<para>Similar to building &os; development snapshots,
|
||||
<filename>thermite.sh</filename> would be invoked the same way.
|
||||
The difference between development snapshots and release builds,
|
||||
<literal>BETA</literal> and <acronym>RC</acronym>, included, is
|
||||
that the &man.chroot.8; configuration files must be named with
|
||||
<literal>release</literal> instead of <literal>snap</literal> as
|
||||
the "type", as mentioned above.</para>
|
||||
|
||||
<para>In addition, the <literal>BUILDTYPE</literal> and
|
||||
<literal>types</literal> must be changed from
|
||||
<literal>snap</literal> to <literal>release</literal> in
|
||||
<filename>defaults-<replaceable>11</replaceable>.conf</filename>
|
||||
and
|
||||
<filename>builds-<replaceable>11</replaceable>.conf</filename>,
|
||||
respectively.</para>
|
||||
|
||||
<para>When building <literal>BETA</literal>,
|
||||
<acronym>RC</acronym>, and the final <literal>RELEASE</literal>,
|
||||
also statically set <literal>BUILDSVNREV</literal> to the
|
||||
revision on the branch reflecting the name change,
|
||||
<literal>BUILDDATE</literal> to the date the builds are started
|
||||
in <literal>YYYYMMDD</literal> format. If the
|
||||
<literal>doc/</literal> and <literal>ports/</literal> trees have
|
||||
been tagged, also set <literal>PORTBRANCH</literal> and
|
||||
<literal>DOCBRANCH</literal> to the relevant tag path in the
|
||||
Subversion repository, replacing <literal>HEAD</literal> with
|
||||
the last changed revision. Also set
|
||||
<literal>releasesrc</literal> in
|
||||
<filename>builds-<replaceable>11</replaceable>.conf</filename>
|
||||
to the relevant branch, such as &branch.stablex; or
|
||||
&branch.relengx;.</para>
|
||||
|
||||
<para>After building the final <literal>RELEASE</literal>, the
|
||||
&branch.relengx; branch is tagged as &branch.releasex; using the
|
||||
revision from which the <literal>RELEASE</literal> was built.
|
||||
Similar to creating the &branch.stablex; and &branch.relengx;
|
||||
branches, this is done with <command>svn cp</command>. From the
|
||||
repository root:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>svn cp ^/&branch.relengx;@r<replaceable>306420</replaceable> &branch.releasex;</userinput>
|
||||
&prompt.user; <userinput>svn commit &branch.releasex;</userinput></screen>
|
||||
</sect2>
|
||||
</sect1>
|
||||
196
en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml
Normal file
196
en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml
Normal file
|
|
@ -0,0 +1,196 @@
|
|||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
<sect1 xml:id="releng-head">
|
||||
<title>Release from &branch.head;</title>
|
||||
|
||||
|
||||
<para>This section describes the general procedures of the &os;
|
||||
release cycle from the &branch.head; branch.</para>
|
||||
|
||||
<sect2 xml:id="releng-head-builds-alpha">
|
||||
<title>&os; <quote><literal>ALPHA</literal></quote> Builds</title>
|
||||
|
||||
<para>Starting with the &os; 10.0-RELEASE cycle, the notion
|
||||
of <quote><literal>ALPHA</literal></quote> builds was
|
||||
introduced. Unlike the <literal>BETA</literal> and
|
||||
<literal>RC</literal> builds, <literal>ALPHA</literal> builds
|
||||
are not included in the &os; Release schedule.</para>
|
||||
|
||||
<para>The idea behind <literal>ALPHA</literal> builds is to
|
||||
provide regular &os;-provided builds before the creation of the
|
||||
&branch.stable; branch.</para>
|
||||
|
||||
<para>&os; <literal>ALPHA</literal> snapshots should be built
|
||||
approximately once a week.</para>
|
||||
|
||||
<para>For the first <literal>ALPHA</literal> build, the
|
||||
<varname>BRANCH</varname> value in
|
||||
<filename>sys/conf/newvers.sh</filename> needs to be changed
|
||||
from <literal>CURRENT</literal> to <literal>ALPHA1</literal>.
|
||||
For subsequent <literal>ALPHA</literal> builds, increment each
|
||||
<literal>ALPHA<replaceable>N</replaceable></literal> value by
|
||||
one.</para>
|
||||
|
||||
<para>See <xref linkend="releng-building"/> for information on
|
||||
building the <literal>ALPHA</literal> images.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-head-branching">
|
||||
<title>Creating the &branch.stablex; Branch</title>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>svn cp head &branch.stablex;</userinput></screen>
|
||||
|
||||
<para>Once the &branch.stablex; branch has been committed, make
|
||||
the following edits:</para>
|
||||
|
||||
<informaltable frame="none" pgwide="0">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>File to Edit</entry>
|
||||
<entry>What to Change</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/UPDATING</filename></entry>
|
||||
<entry>Update the &os; version, and remove the notice
|
||||
about <literal>WITNESS</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h</filename></entry>
|
||||
<entry><screen>#ifndef MALLOC_PRODUCTION
|
||||
#define MALLOC_PRODUCTION
|
||||
#endif</screen></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/sys/*/conf/GENERIC*</filename></entry>
|
||||
<entry>Remove debugging support</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/release/release.conf.sample</filename></entry>
|
||||
<entry>Update <varname>SRCBRANCH</varname></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/sys/*/conf/GENERIC-NODEBUG</filename></entry>
|
||||
<entry>Remove these kernel configurations</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/sys/conf/newvers.sh</filename></entry>
|
||||
<entry>Update the <varname>BRANCH</varname> value to
|
||||
reflect <literal>BETA1</literal></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Then in the &branch.head; branch, which will now become
|
||||
a new major version:</para>
|
||||
|
||||
<informaltable frame="none" pgwide="0">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>File to Edit</entry>
|
||||
<entry>What to Change</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>head/UPDATING</filename></entry>
|
||||
<entry>Update the &os; version</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/gnu/usr.bin/groff/tmac/mdoc.local.in</filename></entry>
|
||||
<entry>Add the new &os; version</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/sys/conf/newvers.sh</filename></entry>
|
||||
<entry>Update the <varname>BRANCH</varname> value to
|
||||
reflect <literal>CURRENT</literal>, and increment
|
||||
<literal>REVISION</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/Makefile.inc1</filename></entry>
|
||||
<entry>Update <varname>TARGET_TRIPLE</varname></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/sys/sys/param.h</filename></entry>
|
||||
<entry>Update <literal>__FreeBSD_version</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp</filename></entry>
|
||||
<entry>Update
|
||||
<literal>__FreeBSD_cc_version</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/gnu/usr.bin/cc/cc_tools/freebsd-native.h</filename></entry>
|
||||
<entry>Update <literal>FBSD_MAJOR</literal> and
|
||||
<literal>FBSD_CC_VER</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/contrib/gcc/config.gcc</filename></entry>
|
||||
<entry>Append the
|
||||
<literal>freebsd<version>.h</literal>
|
||||
section</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/release/Makefile</filename></entry>
|
||||
<entry>Remove the
|
||||
<literal>debug.witness.trace</literal> entries</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/release/doc/en_US.ISO8859-1/readme/article.xml</filename></entry>
|
||||
<entry>Replace &a.current; with &a.stable;</entry>
|
||||
</row>
|
||||
|
||||
<?ignore
|
||||
|
||||
<row>
|
||||
<entry><filename>head/release/doc/share/xml/release.ent</filename></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
|
||||
?>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/lib/clang/clang.build.mk</filename></entry>
|
||||
<entry>Uncomment <literal>-DNDEBUG</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>head/lib/clang/freebsd_cc_version.h</filename></entry>
|
||||
<entry>Update
|
||||
<literal>FREEBSD_CC_VERSION</literal></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</sect2>
|
||||
</sect1>
|
||||
174
en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml
Normal file
174
en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml
Normal file
|
|
@ -0,0 +1,174 @@
|
|||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
<sect1 xml:id="releng-stable">
|
||||
<title>Release from &branch.stable;</title>
|
||||
|
||||
<para>This section describes the general procedures of the &os;
|
||||
release cycle from an extablished &branch.stable; branch.</para>
|
||||
|
||||
<sect2 xml:id="releng-stable-slush">
|
||||
<title>&os; <literal>stable</literal> Branch Code Slush</title>
|
||||
|
||||
<para>In preparation for the code freeze on
|
||||
a <literal>stable</literal> 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:</para>
|
||||
|
||||
<informaltable frame="none" pgwide="0">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>File to Edit</entry>
|
||||
<entry>What to Change</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>gnu/usr.bin/groff/tmac/mdoc.local.in</filename></entry>
|
||||
<entry>Add the new &os; version</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>sys/conf/newvers.sh</filename></entry>
|
||||
<entry>Update the <varname>BRANCH</varname> value to
|
||||
reflect <literal>PRERELEASE</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>Makefile.inc1</filename></entry>
|
||||
<entry>Update <varname>TARGET_TRIPLE</varname></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-stable-builds-beta">
|
||||
<title>&os; <literal>BETA</literal> Builds</title>
|
||||
|
||||
<para>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
|
||||
<filename>base/svnadmin/conf/approvers</filename> to include
|
||||
a regular expression matching the &branch.stablex; branch for
|
||||
the release:</para>
|
||||
|
||||
<programlisting>^/&branch.stablex; re</programlisting>
|
||||
|
||||
<note>
|
||||
<para>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.</para>
|
||||
</note>
|
||||
|
||||
<para>Once the code freeze is in effect, the next build from the
|
||||
branch is labeled <literal>BETA1</literal>. This is done by
|
||||
updating the <varname>BRANCH</varname> value in
|
||||
<filename>sys/conf/newvers.sh</filename> from
|
||||
<literal>PRERELEASE</literal> to
|
||||
<literal>BETA1</literal>.</para>
|
||||
|
||||
<para>Once this is done, the first set of <literal>BETA</literal>
|
||||
builds are started. Subsequent <literal>BETA</literal> builds
|
||||
do not require updates to any files other than
|
||||
<filename>sys/conf/newvers.sh</filename>, incrementing the
|
||||
<literal>BETA</literal> build number.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-stable-branching">
|
||||
<title>Creating the &branch.relengx; Branch</title>
|
||||
|
||||
<para>When the first <acronym>RC</acronym> (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
|
||||
<varname>__FreeBSD_version</varname> values, for example. The
|
||||
paths listed below are relative to the repository root. The
|
||||
order of commits and what to change are:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>svn cp &branch.stablex; &branch.relengx;</userinput></screen>
|
||||
|
||||
<informaltable frame="none" pgwide="0">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>File to Edit</entry>
|
||||
<entry>What to Change</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>releng/<replaceable>11.0</replaceable>/sys/conf/newvers.sh</filename></entry>
|
||||
<entry>Change
|
||||
<literal>BETA<replaceable>X</replaceable></literal>
|
||||
to <literal>RC1</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>releng/<replaceable>11.0</replaceable>/sys/sys/param.h</filename></entry>
|
||||
<entry>Update <varname>__FreeBSD_version</varname></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>releng/<replaceable>11.0</replaceable>/etc/pkg/FreeBSD.conf</filename></entry>
|
||||
<entry>Replace <literal>latest</literal> with
|
||||
<literal>quarterly</literal> as the default package
|
||||
repository location</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>releng/<replaceable>11.0</replaceable>/release/pkg_repos/release-dvd.conf</filename></entry>
|
||||
<entry>Replace <literal>latest</literal> with
|
||||
<literal>quarterly</literal> as the default package
|
||||
repository location</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/sys/conf/newver.sh</filename></entry>
|
||||
<entry>Update
|
||||
<literal>BETA<replaceable>X</replaceable></literal> with
|
||||
<literal>PRERELEASE</literal></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>stable/<replaceable>11</replaceable>/sys/sys/param.h</filename></entry>
|
||||
<entry>Update <varname>__FreeBSD_version</varname></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>svnadmin/conf/approvers</filename></entry>
|
||||
<entry>Add a new approvers line for the releng
|
||||
branch as was done for the stable branch</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<screen>&prompt.user; <userinput>svn propdel -R svn:mergeinfo &branch.relengx;</userinput>
|
||||
&prompt.user; <userinput>svn commit &branch.relengx;</userinput>
|
||||
&prompt.user; <userinput>svn commit &branch.stablex;</userinput></screen>
|
||||
|
||||
<para>Now that two new <varname>__FreeBSD_version</varname> values
|
||||
exist, also update
|
||||
<filename>head/en_US.ISO8859-1/books/porters-handbook/versions/chapter.xml</filename>
|
||||
in the Documentation Project repository.</para>
|
||||
|
||||
<para>After the first <acronym>RC</acronym> build has completed
|
||||
and tested, the &branch.stable; branch can be
|
||||
<quote>thawed</quote> by removing (or commenting) the
|
||||
^/&branch.stablex; entry in
|
||||
<filename>svnadmin/conf/approvers</filename>.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
113
en_US.ISO8859-1/articles/freebsd-releng/releng-mirrors.xml
Normal file
113
en_US.ISO8859-1/articles/freebsd-releng/releng-mirrors.xml
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
<sect1 xml:id="releng-mirrors">
|
||||
<title>Publishing &os; Installation Media to Project Mirrors</title>
|
||||
|
||||
<para>This section describes the procedure to publish &os;
|
||||
development snapshots and releases to the Project mirrors.</para>
|
||||
|
||||
<sect2 xml:id="releng-mirrors-staging">
|
||||
<title>Staging &os; Installation Media Images</title>
|
||||
|
||||
<para>Staging &os; snapshots and releases is a two part
|
||||
process:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Creating the directory structure to match the hierarchy
|
||||
on <systemitem>ftp-master</systemitem></para>
|
||||
|
||||
<para>If <literal>EVERYTHINGISFINE</literal> is defined in the
|
||||
build configuration files, <filename>main.conf</filename> in
|
||||
the case of the build scripts referenced above, this happens
|
||||
automatically in the &man.chroot.8; after the build is
|
||||
complete, creating the directory structure in <filename
|
||||
class="directory">${DESTDIR}/R/ftp-stage</filename>
|
||||
with a path structure matching what is expected on
|
||||
<systemitem>ftp-master</systemitem>. This is equivalent to
|
||||
running the following in the &man.chroot.8; directly:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage</userinput></screen>
|
||||
|
||||
<para>After each architecture is built,
|
||||
<filename>thermite.sh</filename> will
|
||||
<application>rsync</application> the <filename
|
||||
class="directory">${DESTDIR}/R/ftp-stage</filename>
|
||||
from the build &man.chroot.8; to <filename
|
||||
class="directory">/snap/ftp/snapshots</filename> or
|
||||
<filename class="directory">/snap/ftp/releases</filename> on
|
||||
the build host, respectively.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Copying the files to a staging directory on
|
||||
<systemitem>ftp-master</systemitem> before moving the files
|
||||
into <filename class="directory">pub/</filename> to begin
|
||||
propagation to the Project mirrors</para>
|
||||
|
||||
<para>Once all builds have finished, <filename
|
||||
class="directory">/snap/ftp/snapshots</filename>, or
|
||||
<filename class="directory">/snap/ftp/releases</filename>
|
||||
for a release, is polled by
|
||||
<systemitem>ftp-master</systemitem> using
|
||||
<application>rsync</application> to <filename
|
||||
class="directory">/archive/tmp/snapshots</filename> or
|
||||
<filename class="directory">/snap/ftp/releases</filename>,
|
||||
respectively.</para>
|
||||
|
||||
<note>
|
||||
<para>On <systemitem>ftp-master</systemitem> in the &os;
|
||||
Project infrastructure, this step requires
|
||||
<literal>root</literal> level access, as this step must
|
||||
be executed as the <literal>archive</literal> user.</para>
|
||||
</note>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-mirrors-publishing">
|
||||
<title>Publishing &os; Installation Media</title>
|
||||
|
||||
<para>Once the images are staged in <filename
|
||||
class="directory">/archive/tmp/</filename>, they are ready to
|
||||
be made public by putting them in <filename
|
||||
class="directory">/archive/pub/FreeBSD</filename>. In order
|
||||
to reduce propagation time, &man.pax.1; is used to create hard
|
||||
links from <filename class="directory">/archive/tmp</filename>
|
||||
to <filename
|
||||
class="directory">/archive/pub/FreeBSD</filename>.</para>
|
||||
|
||||
<note>
|
||||
<para>In order for this to be effective, both <filename
|
||||
class="directory">/archive/tmp</filename> and <filename
|
||||
class="directory">/archive/pub</filename> must reside on the
|
||||
same logical filesystem.</para>
|
||||
</note>
|
||||
|
||||
<para>There is a caveat, however, where
|
||||
<application>rsync</application> must be used after &man.pax.1;
|
||||
in order to correct the symbolic links in <filename
|
||||
class="directory">pub/FreeBSD/<replaceable>snapshots</replaceable>/ISO-IMAGES</filename>
|
||||
which &man.pax.1; will replace with a hard link, increasing the
|
||||
propagation time.</para>
|
||||
|
||||
<note>
|
||||
<para>As with the staging steps, this requires
|
||||
<literal>root</literal> level access, as this step must be
|
||||
executed as the <literal>archive</literal> user.</para>
|
||||
</note>
|
||||
|
||||
<para>As the <literal>archive</literal> user:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>cd /archive/tmp/<replaceable>snapshots</replaceable></userinput>
|
||||
&prompt.user; <userinput>pax -r -w -l . /archive/pub/FreeBSD/<replaceable>snapshots</replaceable></userinput>
|
||||
&prompt.user; <userinput>/usr/local/bin/rsync -avH /archive/tmp/<replaceable>snapshots</replaceable>/* /archive/pub/FreeBSD/<replaceable>snapshots</replaceable>/</userinput></screen>
|
||||
|
||||
<para>Replace <replaceable>snapshots</replaceable> with
|
||||
<replaceable>releases</replaceable> as appropriate.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
<?xml version="1.0" encoding="iso-8859-1"?>
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
<sect1 xml:id="releng-terms">
|
||||
<title>Release Engineering Terminology</title>
|
||||
|
||||
<para>This section describes some of the terminology used throughout
|
||||
the rest of this document.</para>
|
||||
|
||||
<sect2 xml:id="releng-terms-code-slush">
|
||||
<title>The Code Slush</title>
|
||||
|
||||
<para>Although the code slush is not a hard freeze on the tree,
|
||||
the &team.re; requests that bugs in the existing code base take
|
||||
priority over new features.</para>
|
||||
|
||||
<para>The code slush does not enforce commit approvals to the
|
||||
branch.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-terms-code-freeze">
|
||||
<title>The Code Freeze</title>
|
||||
|
||||
<para>The code freeze marks the point in time where all commits to
|
||||
the branch require explicit approval from the &team.re;.</para>
|
||||
|
||||
<para>The &os; <application>Subversion</application> 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.</para>
|
||||
|
||||
<para>To enforce commit approvals by the &team.re;, the Release
|
||||
Engineer updates
|
||||
<filename>base/svnadmin/conf/approvers</filename>, and commits
|
||||
the change back to the repository. Once this is done, any
|
||||
change to the branch must include an <quote>Approved by:</quote>
|
||||
line in the commit message.</para>
|
||||
|
||||
<para>The <quote>Approved by:</quote> line must match the second
|
||||
column in <filename>base/svnadmin/conf/approvers</filename>,
|
||||
otherwise the commit will be rejected by the repository
|
||||
hooks.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="releng-terms-kbi-freeze">
|
||||
<title>The <acronym>KBI</acronym>/<acronym>KPI</acronym>
|
||||
Freeze</title>
|
||||
|
||||
<para><acronym>KBI</acronym>/<acronym>KPI</acronym> stability
|
||||
implies that the caller of a function across two different
|
||||
releases of software that implement the function results in the
|
||||
same end state. The caller, whether it is a process, thread, or
|
||||
function, expects the function to operate in a certain way,
|
||||
otherwise the <acronym>KBI</acronym>/<acronym>KPI</acronym>
|
||||
stability on the branch is broken.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
@ -36,14 +36,15 @@
|
|||
|
||||
<abstract>
|
||||
<para>
|
||||
<warning>
|
||||
<para>2013/02/26: This document is partially outdated and does not
|
||||
accurately describe the current release procedures of the
|
||||
&os; Release Engineering team. The &os; Release
|
||||
Engineering team is currently reviewing this document and
|
||||
will publish updated content soon.
|
||||
</para>
|
||||
</warning>
|
||||
<note>
|
||||
<para>This document is outdated and does not accurately
|
||||
describe the current release procedures of the &os;
|
||||
Release Engineering team. It is retained for historical
|
||||
purposes. The current procedures used by the &os; Release
|
||||
Engineering team are available in the <link
|
||||
xlink:href="&url.articles.freebsd-releng;/article.html">&os;
|
||||
Release Engineering</link> article.</para>
|
||||
</note>
|
||||
</para>
|
||||
<para>This paper describes the approach used by the &os;
|
||||
release engineering team to make production quality releases
|
||||
|
|
|
|||
|
|
@ -65,6 +65,8 @@
|
|||
<!ENTITY url.articles.fonts.en "&url.doc.langbase.en;/articles/fonts">
|
||||
<!ENTITY url.articles.freebsd-questions "&url.doc.langbase;/articles/freebsd-questions">
|
||||
<!ENTITY url.articles.freebsd-questions.en "&url.doc.langbase.en;/articles/freebsd-questions">
|
||||
<!ENTITY url.articles.freebsd-releng "&url.doc.langbase;/articles/freebsd-releng">
|
||||
<!ENTITY url.articles.freebsd-releng.en "&url.doc.langbase.en;/articles/freebsd-releng">
|
||||
<!ENTITY url.articles.geom-class "&url.doc.langbase;/articles/geom-class">
|
||||
<!ENTITY url.articles.geom-class.en "&url.doc.langbase.en;/articles/geom-class">
|
||||
<!ENTITY url.articles.gjournal-desktop "&url.doc.langbase;/articles/gjournal-desktop">
|
||||
|
|
|
|||
Loading…
Reference in a new issue