The Debian Administrator's Handbook

This is the only way to earns one's stripes: do something useful and show that one has worked well. Many Debian “administrative” teams operate by appointment, preferring volunteers who have already effectively contributed and proved their competence. This method is practical, because the most of the work these teams do is public, therefore, accessible to any interested developer. This is why Debian is often described as a “meritocracy”.

CULTURE Meritocracy, the reign of knowledge

Meritocracy is a form of government in which authority is exercised by those with the greatest merit. For Debian, merit is a measure of competence, which is, itself, assessed by observation of past actions by one or more others within the project (Stefano Zacchiroli, the current project leader, speaks of “do-ocracy”, meaning “power to those who get things done”). Their simple existence proves a certain level of competence; their achievements generally being free software, with available source code, which can easily be reviewed by peers to assess their quality.

This effective operational method guarantees the quality of contributors in the “key” Debian teams. This method is by no means perfect and occasionally there are those who do not accept this way of operating. The selection of developers accepted in the teams may appear a bit arbitrary, or even unfair. Furthermore, not everybody has the same definition of the service expected from these teams. For some, it is unacceptable to have to wait eight days for inclusion of a new Debian package, while others will wait patiently for three weeks without a problem. As such, there are regular complaints from the disgruntled about the “quality of service” from some teams.

COMMUNITY Integration of new maintainers

The team in charge of admitting new developers is the most regularly criticized. One must acknowledge that, throughout the years, the Debian project has become more and more demanding of the developers that it will accept. Some people may see some injustice in that, but we must confess that, what were only little challenges at the beginning have become much greater in a community of over 1,000 people, when it comes to ensuring the quality and integrity of everything that Debian produces for its users.

Furthermore, the acceptance procedure is concluded by review of the candidacy by a small team, the Debian Account Managers. These managers are, thus, particularly exposed to criticism, since they have final say in the inclusion or rejection of a volunteer within the Debian developers community. In practice, sometimes they must delay the acceptance of a person until they have learned more about the operations of the project. One can, of course, contribute to Debian before being accepted as an official developer, by being sponsored by current developers.

1.3.2. The Active Role of Users

Is it relevant to mention the users among those who work within the Debian project? Yes: They play a critical role in the project. Far from being “passive”, some of our users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit improvements ideas, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see sidebar BACK TO BASICS Patch, how to send a fix).

TOOL Bug tracking system

The Debian Bug Tracking System (Debian BTS) envelopes the project. The public part of the web interface allows users to view all bugs reported, with the option to display a sorted list of bugs selected according to various criteria, such as: affected package, severity, status, address of the reporter, address of the maintainer in charge of it, tag, etc. It is also possible to browse the complete historical listing of all discussions regarding each of the bugs.

Below the surface, the Debian BTS communicates via e-mail: all information that it stores come from messages sent by the various persons involved. Any e-mail sent to <[email protected]> will, thus, be assigned to the history for bug no. 12345. Authorized persons may “close” a bug by writing a message describing the reasons for the decision to close to <[email protected]> (a bug is closed when the indicated problem is resolved or no longer relevant). A new bug is reported by sending an e-mail to according to a specific format which identifies the package in question. The address allows editing of all the “meta-information” related to a bug.

Debian BTS has other functional features, as well, such as the use of tags for labeling bugs. For more information, see

→ http://www.debian.org/Bugs/

VOCABULARY Severity of a bug