This page documents the process used by the release engineering - team to produce official FreeBSD releases. Comments, suggestions, - and additional material are welcome. This is, as always, a work in - progress.
-New releases of FreeBSD are released from the -STABLE branch at - approximately four month intervals. The FreeBSD release process - begins to ramp up 45 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.
+This document has moved.
-To service our most conservative users, individual release - branches were introduced with FreeBSD 4.3. These release branches - are created shortly before a final release is made, and after the - release goes out only the most critical security fixes are merged - onto the release branch. In addition to source updates via CVS, - binary patchkits are available to keep systems on the - RELENG_4_3 and RELENG_4_4 branches updated.
- -Thirty days before the anticipated release, the source repository - enters a ``code slush''. During this time, all commits to the - -STABLE branch must be approved by the release engineer (re@FreeBSD.org). The kinds of - changes that are allowed during this 15 day period include :
- -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 up to the final release, the release engineering team is - in constant communication with the security-officer team, the - documentation maintainers, and the ports managers, to make sure - that all of the different components required for a successful - release are available.
- -When several release candidates have been made available for - widespread testing and all major issues have been resolved, the - final release ``polishing'' can begin.
- -As described in the introduction, the RELENG_X_Y release - branch is a relatively new addition to our release engineering - methodology. The first step in creating this branch is to ensure - that you are working with the newest version of the - RELENG_X sources that you want to branch - from.
- - /usr/src# cvs up -rRELENG_4 -P -d - -The next step is to create a branch point tag. A ``tag'' is CVS - vernacular for a label that identifies the source at a specific - point in time. By tagging the tree, we ensure that future release - builders will always be able to use the same source we used to - create the official FreeBSD Project releases. The branch point - tag makes it easier to produce diffs against the start of the - branch :
- - /usr/src# cvs rtag -rRELENG_4 RELENG_4_4_BP src - -And then a new branch tag is created with :
- - /usr/src# cvs rtag -b -rRELENG_4_4_BP RELENG_4_4 src - -Note: The RELENG_* tags are restricted for use by the - CVS-meisters and release engineers.
- - -Before the final release can be tagged, built, and released, the - following files need to be modified to reflect the correct version - of FreeBSD :
- -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):
- -When the final release is ready, the following command will create the - RELENG_4_4_0_RELEASE tag.
- - /usr/src# cvs rtag -rRELENG_4_4 RELENG_4_4_0_RELEASE src - -The Documentation and Ports managers are responsible for tagging - the respective trees with the RELEASE_4_4_0 tag.
- -Occasionally, a last minute fix may be required after - the final tags have been created. In practice this isn't a - problem, since CVS allows tags to be manipulated with cvs tag - -d tagname filename. It is very important - that any last minute changes be tagged appropriately as part of - the release. FreeBSD releases must always be reproduceable. - Local hacks in the release engineer's environment are not - acceptable.
- -FreeBSD releases can be built by anyone with a fast machine and - access to a source repository. (That should be everyone, - since we offer anonymous CVS! See The Handbook for - details.). The only special requirement is that the - vn (On -CURRENT, this device has been replaced by the - new md memory disk driver.) device must be - available. If the device is not loaded into your kernel, then the - kernel module should be automatically loaded when - vnconfig is executed during the boot media creation - phase. All of the tools necessary to build a release are - available from the CVS repository in src/release. These - tools aim to provide a consistent way to build FreeBSD releases. - A complete release can actually be built with only a single - command, including the creation of ISO images suitable for burning - to CDROM, installation floppies, and an FTP install directory. - This command is aptly named ``make release''.
- -To successfully build a release, you must first populate - /usr/obj by running ``make world'' or simply ``make - buildworld''. The release target requires several variables be - set properly to build a release :
- -There are many other variables available to customize the release - build. Most of these variables are documented at the top of - src/release/Makefile. The exact command used to build - the official FreeBSD 4.4 (x86) release was :
- - make release CHROOTDIR=/local3/release BUILDNAME=4.4-RELEASE CVSROOT=/host/cvs/usr/home/ncvs RELEASETAG=RELENG_4_4_0_RELEASE - -The release Makefile can be broken down into several distinct - steps.
- -The FreeBSD Ports - collection is a collection of over 6,000 third-party software - packages available for FreeBSD. The ports team (portmgr@FreeBSD.org) - responsible for maintaining a consistent ports tree that can be - used to create the binary packages that accompany a given FreeBSD - release.
- -In order to provide a consistent set of third-party packages for - FreeBSD releases, every port is built in a separate chroot - environment, starting with an empty /usr/local and - /usr/X11R6. The requisite dependencies are installed as - packages before the build proceeds. This enforces - consistency in the package build process. By starting the - package build in a pristine environment, we can assure that the - package metadata (such as required dependencies) is accurate, and - so we will never generate packages that might work on some systems - and not on others depending on what software was previously - installed.
- -The ``Ports Cluster'' for the x86 architecture currently consists - of a master node (Dual Pentium III 733Mhz) and 8 slave nodes - (Pentium III 800Mhz) to do the actual package builds. With this - configuration, a complete package build takes over 24 hours. - These machines are co-located with the other FreeBSD Project - equipment at Yahoo's corner of Exodus in Santa Clara, CA.
- -The ``Ports Cluster'' for the Alpha architecture consists of 7 - PWS 500A machines donated by Compaq and also co-located with - Yahoo's facilities.
- -For FreeBSD 4.4 over 4.1 gigabytes of packages were created. - This causes a problem for CDROM distributions because we would - like to ship as many packages as possible without making the user - insert another disc to satisfy dependencies. The solution is to - create ``clusters'' of like packages with similar dependencies - onto specific discs. The package split is performed by the portmgr team in coordination - with the wishes of the general user community with respect to - which packages get to appear on the first CD.
- -Starting with FreeBSD 4.4, the FreeBSD Project decided to release - all four ISO images that were previously sold on the BSDi/Wind - River Systems ``official'' CDROM distributions. Each of the four - discs must contain a README.TXT file that explains the - contents of the disc, a CDROM.INF file that provides - meta-data for the disc so that sysinstall can validate and use the - contents, and a filename.txt file that provides a - manifest for the disc. This manifest can be created with a simple - command :
- - /stage/cdrom# find . -type f | sed -e 's/\^.\///' | sort > filename.txt - -The specific requirements of each CD is outlined below.
- -The first disc is almost completely created by ``make release''. - The only changes that should be made to the disc1 - directory are the addition of a 'tools' directory, XFree86, and as - many popular third party software packages as will fit on the - disc. The 'tools' directory contains software that allow users to - create installation floppies from other operating systems. This - disc should be made bootable so that users of modern PCs do not - need to create installation floppy disks.
- -If an alternate version of XFree86 is to be provided, then - sysinstall must be updated to reflect the new location and - installation instructions. The relevant code is contained in - src/release/sysinstall on -STABLE or - src/usr.sbin/sysinstall on -CURRENT. Specifically, the - files dist.c, menus.c, and config.c - will need to be updated.
- -The second disc is also largely created by ``make release''. - This disc contains a ``live filesystem'' that can be used from - sysinstall to troubleshoot a FreeBSD installation. This disc - should be bootable and should also contain a compressed copy of - the CVS repository in the CVSROOT directory and - commercial software demos in the commerce directory.
- -The remaining two discs contains additional software packages for - FreeBSD. The packages should be clustered so that a package and - all of its dependencies are included on the same disc.
- -The FreeBSD Release Engineering document has been expanded and is +now available as part of the FreeBSD Documentation set. You will find +it here.
&footer; diff --git a/en/internal/releng45.sgml b/en/internal/releng45.sgml index 47295bc742..263ef55241 100644 --- a/en/internal/releng45.sgml +++ b/en/internal/releng45.sgml @@ -1,7 +1,7 @@ - + %includes; ]> @@ -9,258 +9,15 @@ &header; -The release engineering team (re@FreeBSD.org) for FreeBSD 4.5 - consists of Murray Stokely, Steve Price, Robert Watson, and John - Baldwin. +
This document has moved.
-The x86 build team consists of Murray Stokely and John Baldwin.
+The FreeBSD 4.5 Release Engineering schedule is available here.
-The Alpha build team consists of David O'Brien, Wilko Bulte, John - Baldwin, and Murray Stokely.
- -The third-party packages are handled by Steve Price and the Ports - managers (portmgr@FreeBSD.org).
- -General discussions about the release engineering process or - quality assurance issues should be sent to the public freebsd-qa mailing list. - MFC requests should be sent to re@FreeBSD.org.
- -For an overview of the entire release engineering process, please - see this document.
- -| Action | Expected | Actual | Description | -
| Reminder announcement | 01 Dec 2001 | 03 Dec 2001 | -Release Engineers send announcement email to - developers@FreeBSD.org with a rough schedule for the FreeBSD 4.5 - release. | -
| 4.5-PRERELEASE | -20 Dec 2001 | -20 Dec 2001 | -newvers.sh, param.h, and release.ent updated. | -
| FTP site updated | -20 Dec 2001 | -20 Dec 2001 | -pkg_add -r works for 4.5-PRERELEASE machines. | -
| Code freeze begins | -20 Dec 2001 | -20 Dec 2001 | - -After this date, all commits to the RELENG_4 branch - must be approved by re@FreeBSD.org. Certain highly - active documentation committers are exempt from this rule for - routine man page / release note updates. Heads-up emails - should be sent to the developers@, stable@, and qa@ lists. | -
| Commercial software demos updated. | -05 Jan 2002 | --- | -The second disc contains commercial software demos, these - demos should be updated to contain the latest versions. | -
| 4.5-RC | -09 Jan 2002 | -09 Jan 2002 | -newvers.sh and release.ent updated. | -
| Announce the Ports Freeze | -09 Jan 2002 | -09 Jan 2002 | -Someone from portmgr should email - freebsd-ports@ and CC: developers@ to set a date - for the tagging of the ports tree. Will set this date at January - 22nd. | -
| Heads up to hubs | -09 Jan 2002 | -09 Jan 2002 | -A message should be sent to - freebsd-hubs@FreeBSD.org before the release is uploaded. The - site administrators have frequently requested advance notice for - new ISOs. | -
| First release candidate | -09 Jan 2002 | -09 Jan 2002 | -The first release candidate for the x86 and Alpha architecture is - released. ISO images should be uploaded to - ftp-master.freebsd.org and - releng4.freebsd.org. A network install directory should - be uploaded to ftp-master.freebsd.org. The - packages and XF86336 directories may be - symlinked to save space, as long as you're sure to use - relative symlinks. - |
| Heads up to -stable | -09 Jan 2002 | -09 Jan 2002 | -A message should be sent to qa@FreeBSD.org and - stable@FreeBSD.org after the release is uploaded. | -
| Second release candidate | -?? Jan 2002 | -18 Jan 2002 | -Note: the release date of this candidate depends on the user - experience with RC1. | -
| Third release candidate | -23 Jan 2002 | -24 Jan 2002 | -4.5 RC3 for the x86 and Alpha architectures will be made - available from ftp.FreeBSD.org and the mirrors. | -
| Ports tree frozen. | -22 Jan 2002 | -22 Jan 2002 | -CVSROOT/avail locks out everyone but the person who - does the tagging. It will take approximately 2 hours to tag the - entire ports tree with the RELEASE_4_5_0 tag. After - this time, the ports/ tree will be re-opened for commits, but - commits made after tagging will not go in 4.5-RELEASE. | -
| Final package build starts - | 22 Jan 2002 | -22 Jan 2002 | -The ports cluster and bento - build final packages. | -
| Package split | -23 Jan 2002 | --- | -The packages must be split so that packages with similar - dependencies appear on each of the four discs, with the most - popular packages appearing on the first disc. | -
| doc tree tagged. | -24 Jan 2002 | -24 Jan 2002 | -RELEASE_4_5_0 tag for docs. | -
| RELENG_4_5 branch | -25 Jan 2002 | -26 Jan 2002 | -The release branch is created. | -
| Note to freebsd-stable@ | -25 Jan 2002 | -26 Jan 2002 | -A note should be sent to the freebsd-stable to let - over-anxious users know that the tags have been created but the - release still isn't ready. Tags may be slid before the - announcement goes out. Point users to freebsd-qa@ for - details. | -
| Version numbers bumped. | -25 Jan 2002 | --- | -The files listed here - are updated to reflect the fact that this is FreeBSD 4.5. | -
| src tree tagged. | -27 Jan 2002 | --- | -RELEASE_4_5_0_RELEASE tag for src. | -
| Update man.cgi on the website. | -25 Jan 2002 | --- | -Make sure the 4.5 manual pages are being displayed by default - for the man->web gateway. | -
| Archive the errata for FreeBSD 4.4. | -25 Jan 2002 | -28 Jan 2002 | -The new RELNOTESng errata file should be setup, and the old - errata file archived. | -
| Final builds. | -28 Jan 2002 | --- | -Final builds for x86 and Alpha in a pristine environment. | -
| Warn hubs@FreeBSD.org | -28 Jan 2002 | --- | -Heads up email to hubs@FreeBSD.org to give admins - time to prepare for the load spike to come. | -
| Upload to ftp-master. | -28 Jan 2002 | --- | -release and packages uploaded to ftp-master.FreeBSD.org | -
| Announcement | -28 Jan 2002 | --- | -Announcement sent out after a majority of the mirrors have - received the bits. | -
It's been pointed out that this table is rather boring. Bruce Mah - gave a slightly more interesting rendition of the 12 - days of Code-Freeze.
+The FreeBSD 4.6 Release Engineering schedule (in progress) is +available here.
&footer;