BACK TO BASICS Package maintenance, the developer's work
Maintaining a package entails, first, “packaging” a program. Specifically, this means to define the means of installation so that, once installed, this program will operate and comply with all of the rules the Debian project sets for itself. The result of this operation is saved in a .deb file. Effective installation of the program will then require nothing more than extraction of this compressed archive and execution of some pre-installation or post-installation scripts contained therein.
After this initial phase, the maintenance cycle truly begins: preparation of updates to follow the latest version of the Debian Policy, fixing bugs reported by users, inclusion of a new “upstream” version of the program, which naturally continues to develop simultaneously (e.g. at the time of the initial packaging, the program was at version 1.2.3. After some months of development, the original authors release a new stable version, numbered version 1.4.0. At this point, the Debian maintainer should update the package, so that users can benefit from its latest stable version).
The Policy, an essential element of the Debian Project, establishes the norms ensuring both the quality of the packages and perfect interoperability of the distribution. Thanks to this Policy, Debian remains consistent despite its gigantic size. This Policy is not fixed in stone, but continuously evolves thanks to proposals formulated on the <debian-policy@lists.debian.org> mailing list. Amendments that are approved by all are accepted and applied to the text by a small group of maintainers who have no editorial responsibility (they only include the modifications agreed upon by the Debian developers that are members of the above-mentioned list). You can read current amendment proposals on the bug tracking system:
→ http://bugs.debian.org/debian-policy
COMMUNITY Policy editorial process
Anyone can propose an amendment to the Debian Policy just by submitting a bug report with a severity level of “wishlist” against the debian-policy package. The process that then starts is documented in /usr/share/doc/debian-policy/Process.htmclass="underline" If it is acknowledged that the problem revealed must be resolved by creating a new rule in the Debian Policy, discussion thereof then begins on the <debian-policy@lists.debian.org> mailing list until a consensus is reached and a proposal issued. Someone then drafts the desired amendment and submits it for approval (in the form of a patch to review). As soon as two other developers approve the fact that the proposed amendment reflects the consensus reached in the previous discussion (they “second” it), the proposal can be included in the official document by one of the debian-policy package maintainers. If the process fails at one of these steps, the maintainers close the bug, classifying the proposal as rejected.
DEBIAN POLICY The documentation
Documentation for each package is stored in /usr/share/doc/package/. This directory often contains a README.Debian file describing the Debian specific adjustments made by the package maintainer. It is, thus, wise to read this file prior to any configuration, in order to benefit from their experience. We also find a changelog.Debian.gz file describing the changes made from one version to the next by the Debian maintainer. This is not to be confused with the changelog.gz file (or equivalent), which describes the changes made by the upstream developers. The copyright file includes information about the authors and the license covering the software. Finally, we may also find a file named NEWS.Debian.gz, which allows the Debian developer to communicate important information regarding updates (if apt-listchanges is used, the messages are automatically shown by apt). All other files are specific to the software in question. We especially like to point out the examples sub-directory, which frequently contains examples of configuration files.
The Policy covers very well the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making.
This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. This leader's role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.
Specifically, the leader has real authority; his vote resolves tie votes; he can make any decision which is not already under the authority of someone else and can delegate part of his responsibilities.
Since its inception, the project has been successively lead by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre and Stefano Zacchiroli.
The constitution also defines a “technical committee”. This committee's essential role is to decide on technical matters when the developers involved have not reached an agreement between themselves. Otherwise, this committee plays an advisory role for any developer who fails to make a decision for which they are responsible. It is important to note that they only get involved when invited to do so by one of the parties in question.
Finally, the constitution defines the position of “project secretary”, who is in charge of the organization of votes related to the various elections and general resolutions.
The “general resolution” procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. For further details see:
→ http://www.debian.org/devel/constitution.en.html
CULTURE Flamewar, discussion that catches fire
A “flamewar” is an exceedingly impassioned debate, which frequently ends up with people attacking each other once all reasonable argumentation has been exhausted on both sides. Certain themes are more frequently subject to polemics than others (for example, the choice of text editor, “do you prefer vi or emacs?”). The matters often provoke very rapid e-mail exchanges due to the sheer number of people with an opinion on the matter (everyone) and the very personal nature of such questions.
Nothing particularly useful generally comes from such discussions; stay out of such debates, and rapidly skim through their content. Full reading would be too time-consuming.
Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: it's the one who does, who gets to decide. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first functional and satisfying one... honoring the time that a competent person did put into it.
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”.