Preparing Gentoo 2005.1
As some of you may know, Gentoo-Linux 2005.1 is planned for the first week of August this year (probably around Linux World Expo San Francisco). The release engineering team is already working on the first prerelease for the upcoming release. A prerelease consists of everything that a real release would consist of: one set of stages, a minimal installation-CD and a package CD. For x86, I will offer these things compiled for "-mcpu=i386".

The most important thing that needs testing is probably the installation CD. Theoretically, it has to run on every machine it was originally designed for (meaning all IBM-PCs and compatibles), practically it has to run on as many machines as possible. One problem we are facing with every release is testing on rare hardware. Especially DELL-Computers are well-known to cause problems. Testing an installation-CD not only requires testing the boot-process of the CD, it also requires testing if the kernel loaded from the CD is able to handle all the tasks neccessary for a Gentoo-installation: Wireless networking, LVM, RAID etc.

The second most important thing is also the most difficult thing to test: the GRP-Set (i.e. the additional precompiled packages available on CD). Not everybody has 5G free to test a complete Linux installation with X.org and KDE. The circle of testers is mostly limited to the release manager himself and probably one or two additional testers from the respective arch-team.

The three stages are relatively easy to test. They contain packages that get installed by Gentoo Users all day so we have the best feedback for them. Errors regarding the stages are quite rare. And if they appear, they are normally fixed immediately.

Every part of prerelease and release is tested by the appropriate release-manager before it is made available to the public. If he is sure that this part is working as expected, he has the Infrastructure-team move this part out to the download-mirrors (into the experimental-branch). If the release-manager experiences anything he is not 100% sure about, it is made available to all members of the release-engineering team for review. After that, it is normally being decided if the part in question should be redone or if it can be moved out to the mirrors.

Once everything is tested and no new bugs are encountered, the documentation-team gets feedback to apply the handbook to fit the new release. The handbook is then changed according to the requests made by the release-engineering team, packed as a set of files so that it can be added to the installation-CDs.

There is a production deadline before the release, on which every release-manager has to have his final release finished and uploaded. This deadline is normally set three to four weeks before the release is planned. These last weeks are needed for final QA and preparing the raw media for the release: Filelists have to be created, the media has to be signed etc.