The most important team is probably that for the Debian installation program, debian-installer, which has accomplished a work of momentous proportions since its conception in 2001. Numerous contributors were needed, since it is difficult to write a single program able to install Debian on a dozen different architectures. Each one has its own mechanism for booting and its own bootloader. All of this work is coordinated on the <debian-boot@lists.debian.org> mailing list, under the direction of Otavio Salvador and Joey Hess.
→ http://www.debian.org/devel/debian-installer/
→ http://kitenet.net/~joey/blog/entry/d-i_retrospective/
The debian-cd program team, very small, has an even more modest objective. Many “small” contributors are responsible for their architecture, since the main developer can not know all the subtleties, nor the exact way to start the installer from the CD-ROM.
Many teams must collaborate with others in the activity of packaging: <debian-qa@lists.debian.org> tries, for example, to ensure quality at all levels of the Debian project. The <debian-policy@lists.debian.org> list develops Debian Policy according to proposals from all over the place. The teams in charge of each architecture (<debian-architecture@lists.debian.org>) compile all packages, adapting them to their particular architecture, if needed.
Other teams manage the most important packages in order to ensure maintenance without placing too heavy a load on a single pair of shoulders; this is the case with the C library and <debian-glibc@lists.debian.org>, the C compiler on the <debian-gcc@lists.debian.org> list, or Xorg on the <debian-x@lists.debian.org> (this group is also known as the X Strike Force, coordinated by Cyril Brulebois).
1.4. The Role of Distributions
A GNU/Linux distribution has two main objectives: install a free operating system on a computer (either with or without an existing system or systems), and provide a range of software covering all of the users' needs.
1.4.1. The Installer: debian-installer
The debian-installer, designed to be extremely modular in order to be as generic as possible, answers the first. It covers a broad range of installation situations and in general, greatly facilitates the creation of a derivative installer to correspond to a particular case.
This modularity, which makes it also very complex, may annoy the developers discovering this tool. Whether used in graphical or text mode, the user's experience is still similar. Great efforts have been made to reduce the number of fields to fill; this explains the inclusion of automatic hardware detection software.
It is interesting to note that distributions derived from Debian differ greatly on this aspect, and provide a more limited installer (often confined to the i386 architecture), but more user-friendly for the uninitiated. On the other hand, they usually refrain from straying too far from package contents in order to benefit as much as possible from the vast range of software offered without causing compatibility problems.
1.4.2. The Software Library
Quantitatively, Debian is undeniably the leader in this respect, with over 14,500 source packages. Qualitatively, Debian’s policy and long testing period prior to releasing a new stable version, justify its reputation for cohesion and stability. As far as availability, everything is available on-line through numerous mirrors, updated every six hours.
Many retailers sell CD-ROMs on the Internet at a very low price (often at cost), the “images” for which are freely available for download. There is only one drawback: the low frequency of releases of new stable versions (their development sometimes takes more than two years), which delays the inclusion of new software.
Most new free software programs quickly find their way into the development version which allows them to be installed. If this requires too many updates due to their dependencies, the program can also be recompiled for the stable version of Debian (see Chapter 15, Creating a Debian Package for more information on this topic).
1.5. Lifecycle of a Release
The project will simultaneously have three or four different versions of each program, named Experimental, Unstable, Testing, and Stable. Each one corresponds to a different phase in development. For a good understanding, let us take a look at a program's journey, from its initial packaging to inclusion in a stable version of Debian.
VOCABULARY Release
The term “release”, in the Debian project, indicates a particular version of a distribution (e.g., “unstable release” means “the unstable version”). It also indicates the public announcement of the launch of any new version (stable).
1.5.1. The Experimental Status
First let us take a look at the particular case of the Experimental distribution: this is a group of Debian packages corresponding to the software currently in development, and not necessarily completed, explaining its name. Not everything passes through this step; some developers add packages here in order to get feedback from more experienced (or braver) users.
Otherwise, this distribution frequently houses important modifications to base packages, whose integration into Unstable with serious bugs would have critical repercussions. It is, thus, a completely isolated distribution, its packages never migrate to another version (except by direct, express intervention of the maintainer or the ftpmasters).
1.5.2. The Unstable Status
Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is risky, but chosen by users who are more concerned with staying close to the cutting edge, with more up to date packages, than they are worried about serious bugs. They discover the program and then test it.
If they encounter bugs, they report them to the package's maintainer. The maintainer then regularly prepares corrected versions, which they upload to the server.
Every newly updated package is updated on all Debian mirrors around the world within less than six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. Most frequently, the maintainer has only one traditional PC and has compiled his package on i386 architecture (or amd64); the autobuilders take over and automatically compile versions for all the other architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.
Figure 1.2. Compilation of a package by the autobuilders
QUICK LOOK buildd, the Debian package recompiler
buildd is the abbreviation of “build daemon”. This program automatically recompiles new versions of Debian packages on the architectures on which it is hosted (cross-compiling not always being sufficient) .
Thus, to produce binaries for the sparc architecture, the project has sparc machines available (specifically, Sun brand). The program buildd runs on them continuously to create package binaries for sparc from source packages sent by Debian developers.