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 50080)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml	(revision 50081)
@@ -1,341 +1,351 @@
 <?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>">
 
 <!-- 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;&nbsp;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-wrapup"/></term>
+	<term><xref linkend="releng-building"/></term>
 
 	<listitem>
-	  <para>Wrapping up the release cycle.</para>
+	  <para>Information related to the specific procedures to
+	    build installation medium.</para>
 	</listitem>
       </varlistentry>
 
       <varlistentry>
-	<term><xref linkend="releng-building"/></term>
+	<term><xref linkend="releng-mirrors"/></term>
 
 	<listitem>
-	  <para>Information related to the specific procedures to
-	    build installation medium.</para>
+	  <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 &quot;[*]&quot; are &quot;as
 	needed&quot;.</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>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 <literal>RC</literal> 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>
   </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>
   </sect1>
 
 </article>
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 50080)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml	(revision 50081)
@@ -1,75 +1,104 @@
 <?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;&nbsp;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;&nbsp;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.  See &man.release.7; and
+	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>&dollar;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/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>
     </sect3>
   </sect2>
 
   <sect2 xml:id="releng-build-snapshot">
     <title>Building &os; Development Snapshots</title>
 
     <para>&nbsp;</para>
   </sect2>
 
   <sect2 xml:id="releng-build-release">
     <title>Building &os; Releases</title>
 
     <para>&nbsp;</para>
   </sect2>
 </sect1>
Index: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-mirrors.xml
===================================================================
--- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-mirrors.xml	(nonexistent)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-mirrors.xml	(revision 50081)
@@ -0,0 +1,39 @@
+<?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>
+      </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>
+      </listitem>
+    </itemizedlist>
+  </sect2>
+
+  <sect2 xml:id="releng-mirrors-publishing">
+    <title>Publishing &os; Installation Media</title>
+
+    <para>&nbsp;</para>
+  </sect2>
+</sect1>

Property changes on: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-mirrors.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