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-maiclass="underline" all information that it stores come from messages sent by the various persons involved. Any e-mail sent to <12345@bugs.debian.org> 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 <12345-done@bugs.debian.org> (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 <submit@bugs.debian.org> according to a specific format which identifies the package in question. The address <control@bugs.debian.org> 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
The severity of a bug formally assigns a degree of gravity to the problem indicated. Effectively, not all bugs have the same importance; for instance, a typing error in a man page is not comparable to a security vulnerability in server software.
Debian uses an extended severity scale to precisely indicate the severity of a bug. Each level is defined precisely in order to facilitate the selection thereof.
→ http://www.debian.org/Bugs/Developer#severities
Additionally, numerous satisfied users of the service offered by Debian like to make a contribution of their own to the project. As not everyone has appropriate levels of expertise in programming, they choose, perhaps, to assist with the translation and review of documentation. There are language-specific mailing lists for various languages. For French, for instance, it is <debian-l10n-french@lists.debian.org>.
→ http://www.debian.org/intl/french/
BACK TO BASICS What are i18n and l10n?
“i18n” and “l10n” are the abbreviations for the words “internationalization” and “localization”, respectively, preserving the initial and last letter of each word, and the number of letters in the middle.
To “internationalize” a program consists of modifying it so that it can be translated (localized). This involves partially rewriting a program initially written to work in one language in order to be able to open it to all languages.
To “localize” a program consists of translating the original messages (frequently in English) to another language. For this, it must have already been internationalized.
In summary, internationalization prepares the software for translation, which is then executed by localization.
BACK TO BASICS Patch, how to send a fix
A patch is a file describing changes to be made to one or more reference files. Specifically, it will contain a list of lines to be removed or added to the code, as well as (sometimes) lines taken from the reference text, replacing the modifications in context (they allow identification of the placement of the changes if the line numbers have been changed).
The tool used for applying the modifications given in such a file is simply called patch. The tool that creates it is called diff, and is used as follows:
$ diff -u file.old file.new >file.patch
The file.patch file contains the instructions for changing the content of file.old into file.new. We can send it to someone, who can then use it to recreate file.new from the two others, like this:
$ patch -p0 file.old <file.patch
The file, file.old, is now identical to file.new.
TOOL Report a bug with reportbug
The reportbug tool facilitates sending bug reports on a Debian package. It can check to make sure the bug in question hasn't already been filed, thus prevent redundancy in the system. It reminds the user of the definitions of the severity levels, for reporting to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps to write a complete bug report without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (local, by default, but reportbug can also use a remote server).