os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

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

Browse source 
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
This commit is contained in:
Konstantin Belousov 2013-05-24 20:18:28 +00:00
parent 0b9f69a778
commit 1f5b67a18a
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=41742
1 changed files with 74 additions and 43 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

117
en_US.ISO8859-1/articles/releng/article.xml
View file

@ -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
a <quote>select</quote> group of nearly 300 people are given write
access to the Subversion repository. These
access to the main repository was opened up to everyone on the Internet.
Therefore only a <quote>select</quote> group of nearly 300 people are
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
the project.</para>
of developers provide some level of direction over the project.</para>
<para>The rapid pace of <systemitem
class="osname">&os;</systemitem> development leaves little time
for polishing the development system into a production quality
release. To solve this dilemma, development continues on two
parallel tracks. The main development branch is the
<emphasis>HEAD</emphasis> or <emphasis>trunk</emphasis> of our Subversion
tree, known as <quote>&os;-CURRENT</quote> or
<para>The rapid pace of <systemitem class="osname">&os;</systemitem>
development makes the main development branch unsuitable for the
everyday use by the general public. In particular, stabilizing
efforts are required for polishing the development system into a
production quality release. To solve this conflict, development
continues on several parallel tracks. The main development branch
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
maintained by the &os; Project.
&os;-CURRENT is the <quote>bleeding-edge</quote> of
All branches live in a master Subversion repository maintained by the
&os; Project. &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
From CURRENT</quote> and it describes the process of merging a
tested change from our -CURRENT development branch to our -STABLE
branch.</para>
sweeps</quote>.</para>
<para><acronym>MFC</acronym> stands for <quote>Merge From
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
repository enters a <quote>code slush</quote>. During this
<para>Sixty days before the anticipated release, the source
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
period include:</para>
&a.re;, the approval process is technically enforced by the
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
<emphasis>release candidate</emphasis> is released for
widespread testing and the code enters a <quote>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. During the code freeze, at least one release
candidate is released per week, until the final release is
ready. During the days leading to the final release, 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
<para>Shortly after the code freeze is started, a
<emphasis>BETA1</emphasis> image is built and released for
widespread testing. During the code freeze, at least one beta
image or release candidate is released every two weeks until the
final release is ready. During the days preceeding the final
release, 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>
tags are restricted to
<ulink url="&url.base;/administration.html#t-subversion">Subversion administrators</ulink>
and the <ulink url="&url.base;/administration.html#t-re">Release Engineering Team</ulink>.
<para>Creating the <literal>releng</literal> branch and
<literal>release</literal> tags is done by the <ulink
url="&url.base;/administration.html#t-re">Release
Engineering Team</ulink>.
</para>
</note>