Date: Fri, 24 May 2013 20:18:29 +0000 (UTC) From: Konstantin Belousov <kib@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r41742 - head/en_US.ISO8859-1/articles/releng Message-ID: <201305242018.r4OKITVC072934@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: kib (src committer) Date: Fri May 24 20:18:28 2013 New Revision: 41742 URL: http://svnweb.freebsd.org/changeset/doc/41742 Log: 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 Modified: head/en_US.ISO8859-1/articles/releng/article.xml Modified: head/en_US.ISO8859-1/articles/releng/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/releng/article.xml Fri May 24 15:12:47 2013 (r41741) +++ head/en_US.ISO8859-1/articles/releng/article.xml Fri May 24 20:18:28 2013 (r41742) @@ -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> @@ -260,30 +280,41 @@ </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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305242018.r4OKITVC072934>