diff --git a/en/gifs/Makefile b/en/gifs/Makefile index 1ed2b29940..6e137d768a 100644 --- a/en/gifs/Makefile +++ b/en/gifs/Makefile @@ -1,57 +1,58 @@ -# $FreeBSD: www/en/gifs/Makefile,v 1.36 2000/12/31 17:03:51 wosch Exp $ +# $FreeBSD: www/en/gifs/Makefile,v 1.37 2001/06/20 17:05:23 obrien Exp $ .if exists(../Makefile.conf) .include "../Makefile.conf" .endif .if exists(../Makefile.inc) .include "../Makefile.inc" .endif DATA= apache.gif apachepower.gif daemon.gif dir.gif doc.gif DATA+= home.gif littlelogo.gif new.gif power-button.gif DATA+= powerlogo.gif ugu_icon.gif wclogo.gif topbar.gif DATA+= flash0.gif flash1.gif soft0.gif soft1.gif support0.gif support1.gif DATA+= docs0.gif docs1.gif vendors0.gif vendors1.gif search0.gif search1.gif DATA+= index0.gif index1.gif get0.gif get1.gif faq0.gif faq1.gif DATA+= handboo0.gif handboo1.gif dae_up2.gif dae_up3.gif bar.gif DATA+= freebsd_1.gif powerani.gif pbfbsd2.gif 205-jp.jpg DATA+= 205-jpb.jpg bsdisc.jpg bsdiscb.jpg comp_b.jpg complete.jpg DATA+= cover.jpg coverb.jpg fullcourse3.jpg DATA+= fullcourse3b.jpg getstarb.jpg getstart.jpg DATA+= jp.jpg jpb.jpg kr.jpg krb.jpg las5.jpg las5b.jpg las512.jpg DATA+= las512b.jpg las523.jpg las523b.jpg wc-docs.jpg wc-docsb.jpg DATA+= pc98-jp.jpg pc98-jpb.jpg pht.jpg phtb.jpg running.jpg DATA+= runningb.jpg starkit.jpg starkitb.jpg tw.jpg twb.jpg DATA+= unixuser.jpg unixuserb.jpg wc-10.jpg wc-10b.jpg wc-11.jpg wc-11b.jpg DATA+= wc-200.jpg wc-200b.jpg wc-205.jpg wc-205b.jpg wc-21.jpg wc-215.jpg DATA+= wc-215b.jpg wc-216.jpg wc-216b.jpg wc-216jp.jpg wc-216jpb.jpg DATA+= wc-217.jpg wc-217b.jpg wc-21b.jpg wc-221.jpg wc-221b.jpg DATA+= wc-222.jpg wc-222b.jpg wc-22snap.jpg wc-22snapb.jpg DATA+= wc-44lite2.jpg wc-44lite2b.jpg wc-blun.jpg wc-blunb.jpg DATA+= wc-30snab.jpg wc-30sna.jpg newsletb.jpg newslett.jpg DATA+= newslet2b.jpg newslet2.jpg DATA+= banner1.gif banner2.gif banner3.gif banner4.gif DATA+= lynx.gif DATA+= smart-reseller-small.jpg smart-reseller.jpg DATA+= bsdm.jpg DATA+= bsdmb.jpg DATA+= fhp_mini.jpg DATA+= mall_title_tiny.gif DATA+= mall_title_medium.gif DATA+= plueschtier-tiny.jpg DATA+= instman.jpg instmanb.jpg sam.jpg samb.jpg urm.jpg urmb.jpg DATA+= releases.jpg bug.jpg doc.jpg news.jpg power.jpg DATA+= gourchin3.gif DATA+= darbylogo.gif DATA+= bsdmagazine.jpg DATA+= aboutf.jpg aboutfb.jpg DATA+= bukudepan.jpg DATA+= wc-bsdtool.gif DATA+= wc-bsdalph-4.2.gif DATA+= wc-freebsd-4.2.gif wc-freebsd-4.2b.gif DATA+= bsdcomp-4.2.gif DATA+= lob-freebsd-4.2.gif DATA+= daemon_hammer.jpg DATA+= daemon_hammer-tn15.jpg daemon_hammer-tn20.jpg daemon_hammer-tn25.jpg +DATA+= branches.png .include "${WEB_PREFIX}/share/mk/web.site.mk" diff --git a/en/gifs/branches.png b/en/gifs/branches.png new file mode 100644 index 0000000000..926bf830ce Binary files /dev/null and b/en/gifs/branches.png differ diff --git a/en/internal/Makefile b/en/internal/Makefile index f9e70448b3..09dcdba7ed 100644 --- a/en/internal/Makefile +++ b/en/internal/Makefile @@ -1,37 +1,38 @@ -# $FreeBSD: www/en/internal/Makefile,v 1.25 2001/04/27 09:15:00 wosch Exp $ +# $FreeBSD: www/en/internal/Makefile,v 1.26 2001/11/16 19:50:58 jhb Exp $ .if exists(../Makefile.conf) .include "../Makefile.conf" .endif .if exists(../Makefile.inc) .include "../Makefile.inc" .endif DOCS= photos.sgml DOCS+= internal.sgml DOCS+= about.sgml DOCS+= machines.sgml DOCS+= mirror.sgml DOCS+= statistic.sgml DOCS+= developer.sgml DOCS+= bylaws.sgml +DOCS+= releng.sgml INDEXLINK= internal.html # build the list of personal homepages of FreeBSD developers only # on the main FreeBSD machines hostname!= hostname .if ${hostname} == "hub.freebsd.org" || ${hostname} == "freefall.freebsd.org" DOCS+= homepage.sgml .PHONY: homepage.inc homepage.inc: homepage.pl ${PERL} ${.CURDIR}/homepage.pl > ${.TARGET} homepage.html: homepage.inc CLEANFILES+= homepage.inc .endif DATA+= README.mirror ssh-keys.asc .include "${WEB_PREFIX}/share/mk/web.site.mk" diff --git a/en/internal/internal.sgml b/en/internal/internal.sgml index c85fa07d7e..ef1aeaeb70 100644 --- a/en/internal/internal.sgml +++ b/en/internal/internal.sgml @@ -1,60 +1,63 @@ - + %includes; ]> &header;

The FreeBSD.org Network

This page documents, for those with accounts on the FreeBSD.org network, just what machine resources are currently available and the sorts of jobs they are being provided for.

Resources for FreeBSD Committers

This page documents resources for FreeBSD committers.

About the FreeBSD WWW Server

The Machine, the software, mirroring the FreeBSD Web Pages, Usage statistics.

FreeBSD Project Staff

The FreeBSD Project is managed and operated by the following groups of people: FreeBSD Core Team, FreeBSD Developers; who is responsible for what.

Photos from Social Events

Personal Homepages

A list of private home pages hosted on people.FreeBSD.org.

FreeBSD Projects

In addition to the mainstream development path of FreeBSD, a number of developer groups are working on the cutting edge to expand FreeBSD's range of applications in new directions.

+

FreeBSD Release Engineering Process

+

This page documents the release engineering process for official +FreeBSD releases.

Contacting FreeBSD

FreeBSD Copyright

The FreeBSD Copyrights.

Search the FreeBSD Site

FreeBSD Search Services.

FreeBSD Statistics

Web statistic, FTP traffic, Release usage.

&footer; diff --git a/en/internal/releng.sgml b/en/internal/releng.sgml new file mode 100644 index 0000000000..5bb97c33d1 --- /dev/null +++ b/en/internal/releng.sgml @@ -0,0 +1,341 @@ + + + + + %includes; +]> + + +&header; + +

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.

+ +

Release Process

+ +

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.

+ +
Release Branch + Diagram
+ +

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.

+ +

Code Review

+ +

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.

+ +

Final Release Checklist

+ +

When several release candidates have been made available for + widespread testing and all major issues have been resolved, the + final release ``polishing'' can begin.

+ +

Creating the Release Branch

+ +

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.

+ +

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 FreeBSD :

+ + + +

Creating the Release Tags

+ +

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.

+ +

Release Building

+ +

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''.

+ +

``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.

+ + + +

Contributed Software (``ports'')

+ +

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.

+ +

The Ports Cluster

+ +

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.

+ +

The Package Split

+ +

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.

+ +

Release ISOs

+ +

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.

+ +

Disc #1

+ +

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.

+ +

Disc #2

+ +

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.

+ +

Discs #3 and 4

+ +

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.

+ +

Further Reading

+ + + + &footer; + + +