From owner-svn-doc-user@freebsd.org Thu Feb 9 16:53:41 2017 Return-Path: Delivered-To: svn-doc-user@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6BD2CD6671 for ; Thu, 9 Feb 2017 16:53:41 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C05B782; Thu, 9 Feb 2017 16:53:41 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v19GreBK057840; Thu, 9 Feb 2017 16:53:40 GMT (envelope-from gjb@FreeBSD.org) Received: (from gjb@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v19Grexa057836; Thu, 9 Feb 2017 16:53:40 GMT (envelope-from gjb@FreeBSD.org) Message-Id: <201702091653.v19Grexa057836@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gjb set sender to gjb@FreeBSD.org using -f From: Glen Barber Date: Thu, 9 Feb 2017 16:53:40 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-user@freebsd.org Subject: svn commit: r49954 - user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng X-SVN-Group: doc-user MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-user@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for doc experimental trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:53:41 -0000 Author: gjb Date: Thu Feb 9 16:53:39 2017 New Revision: 49954 URL: https://svnweb.freebsd.org/changeset/doc/49954 Log: Split out complex sections into different files for editing ease. Some parts of these sections will overlap a bit, so separating them into different files will make inclusion of certain parts much easier. Sponsored by: The FreeBSD Foundation Added: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml (contents, props changed) user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (contents, props changed) user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-terminology.xml (contents, props changed) Modified: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml Modified: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml ============================================================================== --- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml Thu Feb 9 12:07:58 2017 (r49953) +++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/article.xml Thu Feb 9 16:53:39 2017 (r49954) @@ -13,6 +13,11 @@ stable/11/"> releng/"> releng/11.0/"> + + + + + ]>
- - Freezing the &os; Source Tree - - This section describes the general procedures related - to the code slush and code freeze - during the &os; release cycle. - - This applies to both &branch.head; and &branch.stable; - branches. - - - The Code Slush - - Approximately one month prior to the scheduled - code slush, the &team.re; sends a reminder - email to the &os; Developers. - - 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. - - The code slush does not enforce commit approvals to the - branch. - - - - The Code Freeze - - Approximately one week prior to the scheduled - code freeze, the &team.re; sends a reminder - email to the &os; Developers. - - The code freeze marks the point in time where all commits - to the branch require explicit approval from the - &team.re;. - - The &os; Subversion 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. - - To enforce commit approvals by the &team.re;, the Release - Engineer updates - base/svnadmin/conf/approvers, and commits - the change back to the repository. Once this is done, any - change to the branch must include an Approved - by: line in the commit message. - - The Approved by: line must match the second - column in base/svnadmin/conf/approvers, - otherwise the commit will be rejected by the repository - hooks. - - - - - Release from &branch.head; - - This section describes the general procedures of the &os; - release cycle from the &branch.head; branch. - - - &os; <quote><literal>ALPHA</literal></quote> - Builds - - Starting with the &os; 10.0-RELEASE cycle, the notion - of ALPHA builds was - introduced. Unlike the BETA and - RC builds, ALPHA - builds are not included in the &os; Release schedule. - - The idea behind ALPHA builds is to - provide regular &os;-provided builds before the creation of - the &branch.stable; branch. - - &os; ALPHA snapshots should be built - approximately once a week. - - For the first ALPHA build, the - BRANCH value in - sys/conf/newvers.sh needs to be changed - from CURRENT to ALPHA1. - For subsequent ALPHA builds, increment - each ALPHAN - value by one. - - See for information on - building the ALPHA images. - - - - The <acronym>KBI</acronym>/<acronym>KPI</acronym> - Freeze - -   - - - - Creating the &branch.stablex; Branch - - When creating the &branch.stable; branch, several changes - are required in both the new &branch.stable; branch and the - &branch.head; branch. - - - - - - File to Edit - What to Change - - - - - -   -   - - - - - ?> - - - - Code Thaw in &branch.head; - -   - - - - - Release from &branch.stable; - - This section describes the general procedures of the &os; - release cycle from an extablished &branch.stable; branch. - - - &os; <literal>BETA</literal> Builds - -   - - - - Creating the &branch.relengx; Branch - -   - - - - Code Thaw in the &branch.stablex; Branch - -   - - - - &os; <literal>RC</literal> Builds - -   - - - - The &os; <literal>RELEASE</literal> Build - -   - - + &release.terminology; + &release.major.version; + &release.minor.version; Wrapping up the Release Cycle Added: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml Thu Feb 9 16:53:39 2017 (r49954) @@ -0,0 +1,83 @@ + + + + Release from &branch.head; + + + This section describes the general procedures of the &os; + release cycle from the &branch.head; branch. + + + &os; <quote><literal>ALPHA</literal></quote> + Builds + + Starting with the &os; 10.0-RELEASE cycle, the notion + of ALPHA builds was + introduced. Unlike the BETA and + RC builds, ALPHA + builds are not included in the &os; Release schedule. + + The idea behind ALPHA builds is to + provide regular &os;-provided builds before the creation of + the &branch.stable; branch. + + &os; ALPHA snapshots should be built + approximately once a week. + + For the first ALPHA build, the + BRANCH value in + sys/conf/newvers.sh needs to be changed + from CURRENT to ALPHA1. + For subsequent ALPHA builds, increment + each ALPHAN + value by one. + + See for information on + building the ALPHA images. + + + + The <acronym>KBI</acronym>/<acronym>KPI</acronym> + Freeze + +   + + + + Creating the &branch.stablex; Branch + + When creating the &branch.stable; branch, several changes + are required in both the new &branch.stable; branch and the + &branch.head; branch. + + + + + + File to Edit + What to Change + + + + + +   +   + + + + + ?> + + + + Code Thaw in &branch.head; + +   + + Added: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml Thu Feb 9 16:53:39 2017 (r49954) @@ -0,0 +1,36 @@ + + + + Release from &branch.stable; + + This section describes the general procedures of the &os; + release cycle from an extablished &branch.stable; branch. + + + &os; <literal>BETA</literal> Builds + +   + + + + Creating the &branch.relengx; Branch + +   + + + + Code Thaw in the &branch.stablex; Branch + +   + + + + &os; <literal>RC</literal> Builds + +   + + Added: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-terminology.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-terminology.xml Thu Feb 9 16:53:39 2017 (r49954) @@ -0,0 +1,60 @@ + + + + Freezing the &os; Source Tree + + This section describes the general procedures related to the + code slush and code freeze during + the &os; release cycle. + + This applies to both &branch.head; and &branch.stable; + branches. + + + The Code Slush + + Approximately one month prior to the scheduled code + slush, the &team.re; sends a reminder email to the + &os; Developers. + + 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. + + The code slush does not enforce commit approvals to the + branch. + + + + The Code Freeze + + Approximately one week prior to the scheduled code + freeze, the &team.re; sends a reminder email to the + &os; Developers. + + The code freeze marks the point in time where all commits to + the branch require explicit approval from the &team.re;. + + The &os; Subversion 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. + + To enforce commit approvals by the &team.re;, the Release + Engineer updates + base/svnadmin/conf/approvers, and commits + the change back to the repository. Once this is done, any + change to the branch must include an Approved by: + line in the commit message. + + The Approved by: line must match the second + column in base/svnadmin/conf/approvers, + otherwise the commit will be rejected by the repository + hooks. + +