This software is used on all the computers serving autobuilders for Debian. By extension, the term buildd frequently is used to refer to these machines, which are generally reserved solely for this purpose.
1.5.3. Migration to Testing
A bit later, the package will have matured; compiled on all the architectures, it will not have undergone recent modifications. It is then a candidate for inclusion in the Testing distribution — a group of Unstable packages chosen according to some quantifiable criteria. Every day a program automatically selects the packages to include in Testing, according to elements guaranteeing a certain level of quality:
lack of critical bugs, or, at least fewer than the version currently included in Testing;
at least 10 days spent in Unstable, which is sufficient time to find and report any serious problems;
successful compilation on all officially supported architectures;
dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question.
This system is clearly not infallible; critical bugs are regularly found in packages included in Testing. Still, it is generally effective, and Testing poses far fewer problems than Unstable, being for many, a good compromise between stability and novelty.
NOTE Limitations of Testing
Very interesting in principle, Testing poses some practical problems: the tangle of cross-dependencies between packages is such that a package can never move there completely on its own. With packages all depending upon each other, it is necessary to move a large number simultaneously, which is impossible when some are uploading updates regularly. On the other hand, the script identifying the families of related packages works hard to create them (this would be an NP-complete problem, for which, fortunately, we know some good heuristics). This is why we can manually interact with and guide this script by suggesting groups of packages, or imposing the inclusion of certain packages in a group, even if this temporarily breaks some dependencies. This functionality is accessible to the Release Managers and their assistants.
Recall that an NP-complete problem is of an exponential algorithmic complexity according to the size of the data, here being the length of the code (the number of figures) and the elements involved. The only way to resolve it is frequently to examine all possible configurations, which could require enormous means. A heuristic is an approximate, but satisfying, solution.
COMMUNITY The Release Manager
Release Manager is an important title, associated with heavy responsibilities. The bearer of this title must, in effect, manage the release of a new, stable version of Debian, and define the process for development of Testing until it meets the quality criteria for Stable. They also define a tentative schedule (not always followed).
We also have Stable Release Managers, often abbreviated SRM, who manage and select updates for the current stable version of Debian. They systematically include security patches and examine all other proposals for inclusion, on a case by case basis, sent by Debian developers eager to update their package in the stable version.
1.5.4. The Promotion from Testing to Stable
Let us suppose that our package is now included in Testing. While it has room for improvement, the manager thereof must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: If it has not changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.
Since this moment never truly arrives, in practice, Debian must compromise: remove packages whose maintainer has failed to correct bugs on time, or agree to release a distribution with some bugs in the thousands of programs. The Release Manager will have previously announced a freeze period, during which each update to Testing must be approved. The goal here is to prevent any new version (and its new bugs), and to only approve updates fixing bugs.
Figure 1.3. A package's path through the various Debian versions
VOCABULARY Freeze: the home straight
During the freeze period, development of the Testing distribution is blocked; no more automatic updates are allowed. Only the Release Managers are then authorized to change packages, according to their own criteria. The purpose is to prevent the appearance of new bugs by introducing new versions; only thoroughly examined updates are authorized when they correct significant bugs.
After the release of a new stable version, the Stable Release Manager manages all further development (called “revisions”, ex: 5.0.1, 5.0.2, 5.0.3 for version 5.0). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).
End of the journey: Our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all, for the stability of their servers, mock the latest version of GNOME; They can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up to date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own Debian!
Figure 1.4. Chronological path of a program packaged by Debian
CULTURE GNOME and KDE, graphical desktop environments
GNOME (GNU Network Object Model Environment) and KDE (K Desktop Environment) are the two most popular graphical desktop environments in the free software world. A desktop environment is a set of programs grouped together to allow easy management of the most common operations through a graphical interface. They generally include a file manager, office suite, web browser, e-mail program, multimedia accessories, etc. The most visible difference resides in the choice of the graphical library used: GNOME has chosen GTK+ (free software licensed under the LGPL), and KDE has selected Qt (from the company, Trolltech, who released it under the GPL license).
→ http://www.gnome.org/
→ http://www.kde.org/
Chapter 2. Presenting the Case Study
You are the system administrator of a growing small business. In collaboration with your directors, you come to redefine the information systems master plan for the coming year, and you choose to progressively migrate to Debian for reasons as much practical as economic. Let's see into more detail what's ahead of you...