Attachment 167187 Details for Bug 207343 – The updated file

The updated file

article.xml (text/xml), 13.20 KB, created by danthemangorman on 2016-02-19 17:56:23 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: danthemangorman

Created: 2016-02-19 17:56:23 UTC

Size: 13.20 KB

patch

obsolete

><?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" [
>
>
><!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">
>]>
><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: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml 43950 2014-02-15 14:30:55Z gjb $</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 <literal>head/</literal> branch, which reflects the top of
>      the source tree.</para>
>
>    <para>After a reasonable testing period, changes can then be
>      merged to the <literal>stable/</literal> branches.  The default
>      minimum timeframe before merging to <literal>stable/</literal>
>      branches is three (3) days.</para>
>
>    <para>Although a general rule to wait a minimum of three days
>      before merging from <literal>head/</literal>, 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
>      <literal>stable/</literal> 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 <literal>stable/</literal>
>      branches, approximately every two (2) years, a release will be
>      cut directly from <literal>head/</literal>.  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-code-slush-freeze"/></term>
>
>	<listitem>
>	  <para>General information about the <quote>code
>	      slush</quote> and <quote>code freeze</quote>.</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>
>
>	<listitem>
>	  <para>Wrapping up the release cycle.</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>
>    </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><literal>head/</literal> slush:</entry>
>	    <entry>August 24</entry>
>	  </row>
>
>	  <row>
>	    <entry><literal>head/</literal> freeze:</entry>
>	    <entry>September 7</entry>
>	  </row>
>
>	  <row>
>	    <entry><literal>head/</literal> KBI freeze:</entry>
>	    <entry>September 21</entry>
>	  </row>
>
>	  <row>
>	    <entry><literal>stable/<replaceable>10</replaceable>/</literal>
>	      branch:</entry>
>	    <entry>October 10</entry>
>	  </row>
>
>	  <row>
>	    <entry>BETA1 build starts:</entry>
>	    <entry>October 12</entry>
>	  </row>
>
>	  <row>
>	    <entry>BETA2 build starts:</entry>
>	    <entry>October 18</entry>
>	  </row>
>
>	  <row>
>	    <entry><literal>releng/<replaceable>10.0</replaceable>/</literal>
>	      branch:</entry>
>	    <entry>November 1</entry>
>	  </row>
>
>	  <row>
>	    <entry>RC1 build starts:</entry>
>	    <entry>November 1</entry>
>	  </row>
>
>	  <row>
>	    <entry>RC2 build starts:</entry>
>	    <entry>November 9</entry>
>	  </row>
>
>	  <row>
>	    <entry>RELEASE build starts:</entry>
>	    <entry>November 19</entry>
>	  </row>
>	</tbody>
>      </tgroup>
>    </informaltable>
>
>    <note>
>      <para>If the release is being created from an existing
>	<literal>stable/</literal> branch, the <acronym>KBI</acronym>
>	freeze date can be excluded, since the <acronym>KBI</acronym>
>	is already considered frozen on established
>	<literal>stable/</literal> 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>
>
>  <sect1 xml:id="releng-code-slush-freeze">
>    <title>Freezing the &os; Source Tree</title>
>
>    <para>This section describes the general procedures related
>      to the <quote>code slush</quote> and <quote>code freeze</quote>
>      during the &os; release cycle.</para>
>
>    <para>This applies to both <literal>head/</literal> and
>      <literal>stable/</literal> branches.</para>
>
>    <sect2 xml:id="releng-code-slush">
>      <title>The Code Slush</title>
>
>      <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>Although the code slush is technically 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-code-freeze">
>      <title>The Code Freeze</title>
>
>      <para>Approximately one week prior to the scheduled
>	<quote>code freeze</quote>, the &team.re; sends a reminder
>	email to the &os; Developers.</para>
>
>      <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>
>  </sect1>
>
>  <sect1 xml:id="releng-head">
>    <title>Release from <literal>head/</literal></title>
>
>    <para>This section describes the general procedures of the
>      &os; release cycle from the <literal>head/</literal>
>      branch.</para>
>
>    <sect2 xml:id="releng-head-builds-alpha">
>      <title>&os; <quote><literal>ALPHA</literal></quote>
>	Builds</title>
>
>      <para>Starting with the &os;&nbsp;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 <literal>stable/</literal> 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
>	<literal>BRANCH</literal> 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-freeze-kbi">
>      <title>The <acronym>KBI</acronym>/<acronym>KPI</acronym>
>	Freeze</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-head-branching">
>      <title>Creating the
>	<literal>stable/<replaceable>N</replaceable></literal>
>	Branch</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-head-thaw">
>      <title>Code Thaw in <literal>head/</literal></title>
>
>      <para>&nbsp;</para>
>    </sect2>
>  </sect1>
>
>  <sect1 xml:id="releng-stable">
>    <title>Release from <literal>stable/</literal></title>
>
>    <para>This section describes the general procedures of the
>      &os; release cycle from an extablished
>      <literal>stable/</literal> branch.</para>
>
>    <sect2 xml:id="releng-stable-builds-beta">
>      <title>&os; <literal>-BETA</literal> Builds</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-stable-branching">
>      <title>Creating the
>	<literal>releng/<replaceable>N.M/</replaceable></literal>
>	Branch</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-stable-thaw">
>      <title>Code Thaw in the
>	<literal>stable/<replaceable>N/</replaceable></literal>
>	Branch</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-release-rc">
>      <title>&os; <literal>-RC</literal> Builds</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-release-final">
>      <title>The &os; <literal>-RELEASE</literal> Build</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>  </sect1>
>
>  <sect1 xml:id="releng-wrapup">
>    <title>Wrapping up the Release Cycle</title>
>
>    <para>This section describes general post-release tasks.</para>
>  </sect1>
>
>  <sect1 xml:id="releng-building">
>    <title>Building the Installer Images</title>
>
>    <para>This section describes how to build the installation images
>      as part of the &os; release cycle.</para>
>
>    <sect2 xml:id="releng-release-releasesh">
>      <title>The <filename>release.sh</filename> Script</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-release-releaseconf">
>      <title>The <filename>release.conf</filename>
>	Configuration</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>
>    <sect2 xml:id="releng-release-archnotes">
>      <title>Information About <filename>release.sh</filename> and
>	<filename>release.conf</filename> for Specific
>	Architectures</title>
>
>      <para>&nbsp;</para>
>    </sect2>
>  </sect1>
></article>

Actions: View

Attachments on bug 207343: 167186 | 167187