From owner-svn-doc-head@FreeBSD.ORG Fri May 24 20:18:29 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 691B236C; Fri, 24 May 2013 20:18:29 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 490A3E9D; Fri, 24 May 2013 20:18:29 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.6/8.14.6) with ESMTP id r4OKIT5A072935; Fri, 24 May 2013 20:18:29 GMT (envelope-from kib@svn.freebsd.org) Received: (from kib@localhost) by svn.freebsd.org (8.14.6/8.14.5/Submit) id r4OKITVC072934; Fri, 24 May 2013 20:18:29 GMT (envelope-from kib@svn.freebsd.org) Message-Id: <201305242018.r4OKITVC072934@svn.freebsd.org> From: Konstantin Belousov Date: Fri, 24 May 2013 20:18:29 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 20:18:29 -0000 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 @@ - 2013/02/26: This document is outdated and does not + 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 select 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 select group of nearly 300 people are + given write access to the Subversion repository. These committers FreeBSD committers - are responsible for the bulk of &os; development. An elected + are usually the people who do the bulk of &os; development. An elected Core Team &os; Core Team - of very senior developers provides some level of direction over - the project. + of developers provide some level of direction over the project. - The rapid pace of &os; 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 - HEAD or trunk of our Subversion - tree, known as &os;-CURRENT or + The rapid pace of &os; + 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 HEAD or trunk of + our Subversion tree, known as &os;-CURRENT or -CURRENT for short. - A more stable branch is maintained, known as + A set of more stable branches are maintained, known as &os;-STABLE or -STABLE for short. - Both branches live in a master Subversion repository on a machine - maintained by the &os; Project. - &os;-CURRENT is the bleeding-edge of + All branches live in a master Subversion repository maintained by the + &os; Project. &os;-CURRENT is the bleeding-edge 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. + The term stable 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 + STABLE systems run unmodified on newer systems, + including HEAD, assuming that the system + management interfaces are not used. + In the interim period between releases, monthly snapshots are built automatically by the &os; Project build machines and made available for download from 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 MFC - sweeps. MFC stands for Merge - From CURRENT and it describes the process of merging a - tested change from our -CURRENT development branch to our -STABLE - branch. + sweeps. + + MFC stands for Merge From + CURRENT 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. Code Review - Thirty days before the anticipated release, the source - repository enters a code slush. During this + Sixty days before the anticipated release, the source + repository enters a code freeze. 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: + &a.re;, the approval process is technically enforced by the + pre-commit hook. The kinds of changes that are allowed during + this period include: @@ -260,30 +280,41 @@ + Driver updates from the vendors. + + + Any additional change that the release engineering team feels is justified, given the potential risk. - After the first 15 days of the code slush, a - release candidate is released for - widespread testing and the code enters a code - freeze 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 + Shortly after the code freeze is started, a + BETA1 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. + + 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 Release + Candidate (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 hard code freeze where it becomes + much harder to justify new changes to the system unless a + serious bug-fix or security issue is involved. Final Release Checklist - When several release candidates have been made available for + When several BETA images have been made available for widespread testing and all major issues have been resolved, the final release polishing can begin. @@ -315,10 +346,10 @@ &prompt.root; svn co $FSVN/releng/9.2 src - Creating releng branch and release - tags are restricted to - Subversion administrators - and the Release Engineering Team. + Creating the releng branch and + release tags is done by the Release + Engineering Team.