Do the proof-editing of the first two sections of the releng article.

Bring the description of the release process closer to the actual
procedures followed by the re.

Requested by:	rodrigc
Reviewed by:	gjb, rodrigc
Sponsored by:	The FreeBSD Foundation

en_US.ISO8859-1/articles/releng/article.xml

@@ -47,7 +47,7 @@
     <abstract>
       <para>
         <warning>
-          <para>2013/02/26: This document is outdated and does not
+          <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
@@ -85,39 +85,38 @@
     formal source code management provides.  This has been a huge help
     in attracting more talented developers to &os;.  However, I
     think everyone would agree that chaos would soon manifest if write
-    access was opened up to everyone on the Internet.  Therefore only
+    access to the main repository was opened up to everyone on the Internet.
-    a <quote>select</quote> group of nearly 300 people are given write
+    Therefore only a <quote>select</quote> group of nearly 300 people are
-    access to the Subversion repository.  These
+    given write access to the Subversion repository.  These
     <ulink url="&url.articles.contributors;/article.html#staff-committers">committers</ulink>
     <footnote>
       <simpara>
         <ulink url="&url.articles.contributors;/article.html#staff-committers">FreeBSD committers</ulink>
       </simpara>
     </footnote>
-    are responsible for the bulk of &os; development.  An elected
+    are usually the people who do the bulk of &os; development.  An elected
     <ulink url="&url.base;/administration.html#t-core">Core Team</ulink>
     <footnote>
       <simpara>
         <ulink url="&url.base;/administration.html#t-core">&os; Core Team</ulink>
       </simpara>
     </footnote>
-    of very senior developers provides some level of direction over
+    of developers provide some level of direction over the project.</para>
-    the project.</para>
 
-  <para>The rapid pace of <systemitem
+  <para>The rapid pace of <systemitem class="osname">&os;</systemitem>
-    class="osname">&os;</systemitem> development leaves little time
+    development makes the main development branch unsuitable for the
-    for polishing the development system into a production quality
+    everyday use by the general public.  In particular, stabilizing
-    release.  To solve this dilemma, development continues on two
+    efforts are required for polishing the development system into a
-    parallel tracks.  The main development branch is the
+    production quality release.  To solve this conflict, development
-    <emphasis>HEAD</emphasis> or <emphasis>trunk</emphasis> of our Subversion
+    continues on several parallel tracks.  The main development branch
-    tree, known as <quote>&os;-CURRENT</quote> or
+    is the <emphasis>HEAD</emphasis> or <emphasis>trunk</emphasis> of
+    our Subversion tree, known as <quote>&os;-CURRENT</quote> or
     <quote>-CURRENT</quote> for short.</para>
 
-  <para>A more stable branch is maintained, known as
+  <para>A set of more stable branches are maintained, known as
     <quote>&os;-STABLE</quote> or <quote>-STABLE</quote> for short.
-    Both branches live in a master Subversion repository on a machine
+    All branches live in a master Subversion repository maintained by the
-    maintained by the &os; Project.
+    &os; Project.  &os;-CURRENT is the <quote>bleeding-edge</quote> of
-    &os;-CURRENT is the <quote>bleeding-edge</quote> of
     &os; development where all new changes first enter the system.
     &os;-STABLE is the development branch from which major releases
     are made.  Changes go into this branch at a different pace, and
@@ -125,6 +124,17 @@
     &os;-CURRENT and have been thoroughly tested by our user
     community.</para>
 
+  <para>The term <emphasis>stable</emphasis> in the name of the branch
+    refers to the presumed Application Binary Interface stability,
+    which is promised by the project.  This means that a user
+    application compiled on an older version of the system from the
+    same branch works on a newer system from the same branch.  The
+    ABI stability has improved greatly from the compared to previous
+    releases.  In most cases, binaries from the older
+    <emphasis>STABLE</emphasis> systems run unmodified on newer systems,
+    including <emphasis>HEAD</emphasis>, assuming that the system
+    management interfaces are not used.</para>
+
   <para>In the interim period between releases, monthly snapshots are
     built automatically by the &os; Project build machines and made
     available for download from <systemitem
@@ -222,24 +232,34 @@
 
   <para>New releases of &os; are released from the -STABLE branch
     at approximately four month intervals.  The &os; release
-    process begins to ramp up 45 days before the anticipated release
+    process begins to ramp up 70-80 days before the anticipated release
     date when the release engineer sends an email to the development
     mailing lists to remind developers that they only have 15 days to
     integrate new changes before the code freeze.  During this time,
     many developers perform what have become known as <quote>MFC
-    sweeps</quote>.  <acronym>MFC</acronym> stands for <quote>Merge
+      sweeps</quote>.</para>
-    From CURRENT</quote> and it describes the process of merging a
+
-    tested change from our -CURRENT development branch to our -STABLE
+  <para><acronym>MFC</acronym> stands for <quote>Merge From
-    branch.</para>
+      CURRENT</quote> and it describes the process of merging a tested
+    change from our -CURRENT development branch to our -STABLE branch.
+    Project policy requires any change to be first applied to
+    trunk, and merged to the -STABLE branches after sufficient
+    external testing was done by -CURRENT users (developers are
+    expected to extensively test the change before committing to
+    -CURRENT, but it is impossible for a person to exercise all usages
+    of the general-purpose operating system).  Minimal MFC period is 3
+    days, which is typically used only for trivial or critical
+    bugfixes.</para>
 
   <sect2>
     <title>Code Review</title>
 
-    <para>Thirty days before the anticipated release, the source
+    <para>Sixty days before the anticipated release, the source
-      repository enters a <quote>code slush</quote>.  During this
+      repository enters a <quote>code freeze</quote>.  During this
       time, all commits to the -STABLE branch must be approved by the
-      &a.re;.  The kinds of changes that are allowed during this 15 day
+      &a.re;, the approval process is technically enforced by the
-      period include:</para>
+      pre-commit hook.  The kinds of changes that are allowed during
+      this period include:</para>
 
     <itemizedlist>
       <listitem>
@@ -259,31 +279,42 @@
         IDs.</para>
       </listitem>
 
+      <listitem>
+        <para>Driver updates from the vendors.</para>
+      </listitem>
+
       <listitem>
         <para>Any additional change that the release engineering team feels
         is justified, given the potential risk.</para>
       </listitem>
     </itemizedlist>
 
-    <para>After the first 15 days of the code slush, a
+    <para>Shortly after the code freeze is started, a
-      <emphasis>release candidate</emphasis> is released for
+      <emphasis>BETA1</emphasis> image is built and released for
-      widespread testing and the code enters a <quote>code
+      widespread testing.  During the code freeze, at least one beta
-      freeze</quote> where it becomes much harder to justify new
+      image or release candidate is released every two weeks until the
-      changes to the system unless a serious bug-fix or security issue
+      final release is ready.  During the days preceeding the final
-      is involved.  During the code freeze, at least one release
+      release, the release engineering team is in constant
-      candidate is released per week, until the final release is
+      communication with the security-officer team, the documentation
-      ready.  During the days leading to the final release, the
+      maintainers, and the port maintainers to ensure that all of the
-      release engineering team is in constant communication with the
-      security-officer team, the documentation maintainers, and the
-      port maintainers, to ensure that all of the
       different components required for a successful release are
       available.</para>
+
+    <para>After the quality of the BETA images is satisfying enough,
+      and no large and potentially risky changes are planned, the
+      release branch is created and <emphasis>Release
+      Candidate</emphasis> (RC) images are built from the release
+      branch, instead of the BETA images from the STABLE branch.
+      Also, the freeze on the STABLE branch is lifted and release
+      branch enters a <quote>hard code freeze</quote> where it becomes
+      much harder to justify new changes to the system unless a
+      serious bug-fix or security issue is involved.</para>
   </sect2>
 
   <sect2>
     <title>Final Release Checklist</title>
 
-    <para>When several release candidates have been made available for
+    <para>When several BETA images have been made available for
       widespread testing and all major issues have been resolved, the
       final release <quote>polishing</quote> can begin.</para>
 
@@ -315,10 +346,10 @@
       <screen>&prompt.root; <userinput>svn co $FSVN/releng/9.2 src</userinput></screen>
 
       <note>
-        <para>Creating <literal>releng</literal> branch and <literal>release</literal>
+        <para>Creating the <literal>releng</literal> branch and
-          tags are restricted to
+          <literal>release</literal> tags is done by the <ulink
-          <ulink url="&url.base;/administration.html#t-subversion">Subversion administrators</ulink>
+	    url="&url.base;/administration.html#t-re">Release
-          and the <ulink url="&url.base;/administration.html#t-re">Release Engineering Team</ulink>.
+          Engineering Team</ulink>.
         </para>
       </note>