From owner-svn-doc-all@freebsd.org Tue Jun 12 18:19:13 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0ED14100F877; Tue, 12 Jun 2018 18:19:13 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B47E07303D; Tue, 12 Jun 2018 18:19:12 +0000 (UTC) (envelope-from bcr@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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 954356359; Tue, 12 Jun 2018 18:19:12 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w5CIJChc045680; Tue, 12 Jun 2018 18:19:12 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w5CIJCBB045679; Tue, 12 Jun 2018 18:19:12 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201806121819.w5CIJCBB045679@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Tue, 12 Jun 2018 18:19:12 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r51823 - head/en_US.ISO8859-1/articles/releng X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/articles/releng X-SVN-Commit-Revision: 51823 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 18:19:13 -0000 Author: bcr Date: Tue Jun 12 18:19:12 2018 New Revision: 51823 URL: https://svnweb.freebsd.org/changeset/doc/51823 Log: Revert until I figure out the build breakage. Yes, I should have tested it locally first. Pointy hat to: me 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 Tue Jun 12 18:07:07 2018 (r51822) +++ head/en_US.ISO8859-1/articles/releng/article.xml Tue Jun 12 18:19:12 2018 (r51823) @@ -2,39 +2,28 @@ -
+
+ + &os; Release Engineering - - &os; Release Engineering - + + November 2001 BSDCon Europe - - - Murray - Stokely - - - I've been involved in the development of &os; based - products since 1997 at Walnut Creek CDROM, BSDi, and now - Wind River Systems. &os; 4.4 was the first official - release of &os; that I played a significant part - in. - - -
- murray@FreeBSD.org - https://people.FreeBSD.org/~murray/ -
- - + MurrayStokely + I've been involved in the development of &os; based products + since 1997 at Walnut Creek CDROM, BSDi, and now Wind River Systems. + &os; 4.4 was the first official release of &os; that I played + a significant part in. + +
murray@FreeBSD.org + https://people.FreeBSD.org/~murray/ +
+ @@ -46,402 +35,395 @@ $FreeBSD$ - - This document is outdated and does not accurately - describe the current release procedures of the &os; Release - Engineering team. It is retained for historical purposes. - The current procedures used by the &os; Release Engineering - team are available in the &os; - Release Engineering article. + + + This document is outdated and does not accurately + describe the current release procedures of the &os; + Release Engineering team. It is retained for historical + purposes. The current procedures used by the &os; Release + Engineering team are available in the &os; + Release Engineering article. + + + This paper describes the approach used by the &os; + release engineering team to make production quality releases + of the &os; Operating System. It details the methodology + used for the official &os; releases and describes the tools + available for those interested in producing customized &os; + releases for corporate rollouts or commercial + productization. + - This paper describes the approach used by the &os; - release engineering team to make production quality releases - of the &os; Operating System. It details the methodology - used for the official &os; releases and describes the tools - available for those interested in producing customized &os; - releases for corporate rollouts or commercial - productization. - - + - - Introduction + + Introduction - The development of &os; is a very open process. &os; is - comprised of contributions from thousands of people around the - world. The &os; Project provides Subversion - Subversion, http://subversion.apache.org - access to the general public so that - others can have access to log messages, diffs (patches) - between development branches, and other productivity - enhancements that 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 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 usually the people who do the bulk of &os; development. - An elected Core - Team - - &os; - Core Team - - of developers provide some level of direction over the - project. + The development of &os; is a very open process. &os; is + comprised of contributions from thousands of people around the + world. The &os; Project provides + Subversion + + + Subversion, http://subversion.apache.org + + + access to the general public so that + others can have access to log messages, diffs (patches) between + development branches, and other productivity enhancements that + 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 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 usually the people who do the bulk of &os; development. An elected + Core Team + + + &os; Core Team + + + of developers provide some level of direction over the project. - 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. + 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 set of more stable branches are maintained, known as - &os;-STABLE or -STABLE for - short. 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 with the - general assumption that they have first gone into &os;-CURRENT - and have been thoroughly tested by our user community. + A set of more stable branches are maintained, known as + &os;-STABLE or -STABLE for short. + 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 + with the general assumption that they have first gone into + &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. + 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, weekly snapshots - are built automatically by the &os; Project build machines and - made available for download from - ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. - The widespread availability of binary release snapshots, and - the tendency of our user community to keep up with -STABLE - development with Subversion and make - buildworld - Rebuilding - "world" helps to keep - &os;-STABLE in a very reliable condition even before the - quality assurance activities ramp up pending a major - release. + In the interim period between releases, weekly snapshots are + built automatically by the &os; Project build machines and made + available for download from ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. + The widespread availability of binary release snapshots, and the + tendency of our user community to keep up with -STABLE development + with Subversion and make + buildworld + + + Rebuilding "world" + + + helps to keep + &os;-STABLE in a very reliable condition even before the + quality assurance activities ramp up pending a major + release. - In addition to installation ISO snapshots, weekly virtual - machine images are also provided for use with - VirtualBox, - qemu, or other popular emulation - software. The virtual machine images can be downloaded from - ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/. + In addition to installation ISO snapshots, weekly virtual + machine images are also provided for use with + VirtualBox, + qemu, or other popular emulation + software. The virtual machine images can be downloaded from + ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/. - The virtual machine images are approximately 150MB - &man.xz.1; compressed, and contain a 10GB sparse filesystem - when attached to a virtual machine. + The virtual machine images are approximately 150MB &man.xz.1; + compressed, and contain a 10GB sparse filesystem when attached to + a virtual machine. - Bug reports and feature requests are continuously - submitted by users throughout the release cycle. Problems - reports are entered into our - Bugzilla database through the web - interface provided at https://www.freebsd.org/support/bugreports.html. + Bug reports and feature requests are continuously submitted by + users throughout the release cycle. Problems reports are entered into our + Bugzilla database + through the web + interface provided at https://www.freebsd.org/support/bugreports.html. + + To service our most conservative users, individual release + branches were introduced with &os; 4.3. + These release branches are created shortly before a final release + is made. After the release goes out, only the most critical + security fixes and additions are merged onto the release branch. + In addition to source updates via Subversion, binary patchkits are + available to keep systems on the + releng/X.Y + branches updated. + + + What this article describes + + The following sections of this article describe: + + + + + + + The different phases of the release engineering process + leading up to the actual system build. + + + + + + + + The actual build process. + + + + + - To service our most conservative users, individual release - branches were introduced with &os; 4.3. These release - branches are created shortly before a final release is made. - After the release goes out, only the most critical security - fixes and additions are merged onto the release branch. In - addition to source updates via Subversion, binary patchkits - are available to keep systems on the - releng/X.Y - branches updated. + + How the base release may be extended by third parties. + + + + + - - What This Article Describes + + Some of the lessons learned through the release of &os; 4.4. + + - The following sections of this article describe: + + - - - + + Future directions of development. + + + + + - - The different phases of the release engineering - process leading up to the actual system build. - - - - - - - - The actual build process. - - - - - - - - How the base release may be extended by third - parties. - - - - - - - - Some of the lessons learned through the release of - &os; 4.4. - - - - - - - - Future directions of development. - - - - - - - - Release Process + + Release Process - New releases of &os; are released from the -STABLE branch - at approximately four month intervals. The &os; 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. + New releases of &os; are released from the -STABLE branch + at approximately four month intervals. The &os; 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. 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. + 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 + + Code Review - 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 - &a.re;. The approval process is technically enforced by a - pre-commit hook. The kinds of changes that are allowed - during this period include: + 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 + &a.re;. The approval process is technically enforced by a + pre-commit hook. The kinds of changes that are allowed during + this period include: - - - Bug fixes. - + + + Bug fixes. + - - Documentation updates. - + + Documentation updates. + - - Security-related fixes of any kind. - + + Security-related fixes of any kind. + - - Minor changes to device drivers, such as adding new - Device IDs. - + + Minor changes to device drivers, such as adding new Device + IDs. + - - Driver updates from the vendors. - + + Driver updates from the vendors. + - - Any additional change that the release engineering - team feels is justified, given the potential - risk. - - + + Any additional change that the release engineering team feels + is justified, given the potential risk. + + - 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 preceding - 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. + 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. - + 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 + + Final Release Checklist - When several BETA images have been made available for - widespread testing and all major issues have been resolved, - the final release polishing can begin. + When several BETA images have been made available for + widespread testing and all major issues have been resolved, the + final release polishing can begin. - - Creating the Release Branch + + Creating the Release Branch - - In all examples below, - $FSVN refers to the location - of the &os; Subversion repository, - svn+ssh://svn.FreeBSD.org/base/. - + + In all examples below, $FSVN + refers to the location of the &os; Subversion repository, + svn+ssh://svn.FreeBSD.org/base/. + - The layout of &os; branches in Subversion is described - in the Committer's - Guide. The first step in creating a branch is to - identify the revision of the - stable/X - sources that you want to branch - from. + The layout of &os; branches in Subversion is + described in the Committer's Guide. + The first step in creating a branch is to + identify the revision of the + stable/X sources + that you want to branch from. - &prompt.root; svn log -v $FSVN/stable/9 + &prompt.root; svn log -v $FSVN/stable/9 - The next step is to create the release - branch + The next step is to create the release branch + + + &prompt.root; svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2 - &prompt.root; svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2 + This branch can be checked out: + + &prompt.root; svn co $FSVN/releng/9.2 src - This branch can be checked out: - - &prompt.root; svn co $FSVN/releng/9.2 src - - Creating the releng branch and - release tags is done by the Release - Engineering Team. + Creating the releng branch and + release tags is done by the Release + Engineering Team. + - - - + + + - - &os; Development Branch - + + &os; Development Branch + - - - + + + - - &os; 3.x STABLE Branch - + + &os; 3.x STABLE Branch + - - - + + + - - &os; 4.x STABLE Branch - + + &os; 4.x STABLE Branch + - - - + + + - - &os; 5.x STABLE Branch - + + &os; 5.x STABLE Branch + - - - + + + - - &os; 6.x STABLE Branch - + + &os; 6.x STABLE Branch + - - - + + + - - &os; 7.x STABLE Branch - + + &os; 7.x STABLE Branch + - - - + + + - - &os; 8.x STABLE Branch - + + &os; 8.x STABLE Branch + - - - + + + - - &os; 9.x STABLE Branch - + + &os; 9.x STABLE Branch + @@ -449,98 +431,104 @@ Bumping up the Version Number Before the final release can be tagged, built, and - released, the following files need to be modified to reflect - the correct version of &os;: + released, the following files need to be modified to reflect + the correct version of &os;: - - doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml - + + doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml + + - - doc/en_US.ISO8859-1/books/porters-handbook/book.xml - + + doc/en_US.ISO8859-1/books/porters-handbook/book.xml + + - - doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi - + + doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi + - - ports/Tools/scripts/release/config - + + ports/Tools/scripts/release/config + - - doc/share/xml/freebsd.ent - - - src/Makefile.inc1 - + + doc/share/xml/freebsd.ent + - - src/UPDATING - + + src/Makefile.inc1 + - - src/gnu/usr.bin/groff/tmac/mdoc.local - + + src/UPDATING + - - src/release/Makefile - + + src/gnu/usr.bin/groff/tmac/mdoc.local + - - src/release/doc/en_US.ISO8859-1/share/xml/release.dsl - + + src/release/Makefile + - - src/release/doc/share/examples/Makefile.relnotesng - + + src/release/doc/en_US.ISO8859-1/share/xml/release.dsl + - - src/release/doc/share/xml/release.ent - + + src/release/doc/share/examples/Makefile.relnotesng + - - src/sys/conf/newvers.sh - + + src/release/doc/share/xml/release.ent + - - src/sys/sys/param.h - + + src/sys/conf/newvers.sh + - - src/usr.sbin/pkg_install/add/main.c - + + src/sys/sys/param.h + - - doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml - + + src/usr.sbin/pkg_install/add/main.c + + + + doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml + - The release notes and errata files also need to be - adjusted for the new release (on the release branch) and - truncated appropriately (on the stable/current branch): + The release notes and errata files also need to be adjusted for the + new release (on the release branch) and truncated appropriately + (on the stable/current branch): - - src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml - + + src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml + + - - src/release/doc/en_US.ISO8859-1/errata/article.xml - + + src/release/doc/en_US.ISO8859-1/errata/article.xml + + - Sysinstall should be updated to - note the number of available ports and the amount of disk - space required for the Ports Collection. - - &os; Ports Collection https://www.FreeBSD.org/ports - - This information is currently kept in + Sysinstall should be updated to note + the number of available ports and the amount of disk space required + for the Ports Collection. + + + &os; Ports Collection + https://www.FreeBSD.org/ports + + + This information is currently kept in src/usr.sbin/bsdinstall/dist.c. After the release has been built, a number of files should @@ -549,57 +537,62 @@ doc/ subversion tree. - - share/images/articles/releng/branches-relengX.pic - + + share/images/articles/releng/branches-relengX.pic + - + head/share/xml/release.ent - + - + en_US.ISO8859-1/htdocs/releases/* - + - + en_US.ISO8859-1/htdocs/releng/index.xml - + - + share/xml/news.xml - + Additionally, update the BSD Family Tree file: - - src/share/misc/bsd-family-tree - + + src/share/misc/bsd-family-tree + + + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***