Product SiteDocumentation Site

1.3. Fonctionnement du projet Debian

La richesse produite par le projet Debian résulte à la fois du travail sur l'infrastructure effectué par des développeurs Debian expérimentés, du travail individuel ou collectif de développeurs sur des paquets Debian, et des retours des utilisateurs.

1.3.1. Les développeurs Debian

Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.
La maintenance des paquets est une activité relativement codifiée, largement documentée voire réglementée. Il faut en effet y respecter toutes les normes édictées par la charte Debian (connue en anglais sous le nom de Debian Policy). Fort heureusement, de nombreux outils facilitent le travail du mainteneur. Il peut ainsi se focaliser sur les particularités de son paquet et sur les tâches plus complexes, telles que la correction des bogues.
La charte, élément essentiel du projet Debian, énonce les normes assurant à la fois la qualité des paquets et la parfaite interopérabilité de l'ensemble. Grâce à elle, Debian reste cohérent malgré sa taille gigantesque. Cette charte n'est pas figée, mais évolue continuellement grâce aux propositions incessamment formulées sur la liste . Les amendements emportant l'adhésion de tous sont acceptés et appliqués au texte par un petit groupe de mainteneurs sans tâche éditoriale (ils se contentent d'inclure les modifications décidées par les développeurs Debian membres de la liste mentionnée ci-dessus). On peut consulter les actuelles propositions d'amendements via le système de suivi de bogues :
The Policy provides considerable coverage of 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. In other words, a formal governance system.
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. The Debian Project leader's (DPL) 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.
Concrètement, le leader dispose de pouvoirs réels : sa voix est déterminante en cas d'égalité dans un vote, il peut prendre toute décision qui ne relève pas déjà d'un autre et déléguer une partie de ses responsabilités.
Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, and Jonathan Carter.
La constitution définit également un « comité technique ». Son rôle essentiel est de trancher sur des points techniques lorsque les développeurs concernés ne sont pas parvenus à un accord entre eux. Par ailleurs, ce comité joue aussi un rôle de conseil vis-à-vis de chaque développeur qui n'arrive pas à prendre une décision qui lui revient. Il est important de noter qu'il n'intervient que lorsqu'une des parties concernées le lui a demandé.
Enfin, la constitution définit le poste de « secrétaire du projet », qui a notamment en charge l'organisation des votes liés aux différentes élections et résolutions générales.
The “general resolution” (GR) procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:
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: the one who does things gets to decide how to do them. 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 one that is both functional and satisfying… which will come out of the time that a competent person put into it.
C'est d'ailleurs la seule manière d'obtenir des galons : faire quelque chose d'utile et démontrer que l'on a bien travaillé. Beaucoup d'équipes « administratives » de Debian fonctionnent sur le mode de la cooptation et favoriseront des volontaires ayant déjà effectivement contribué dans le sens de leur action et prouvé leur compétence à la tâche. Le fait que le travail de ces équipes est essentiellement public les rend accessible à tout nouveau développeur intéressé pour commencer à participer, même sans privilèges particuliers. C'est pourquoi Debian est souvent qualifiée de « méritocratie ».
Ce mode de fonctionnement efficace garantit la qualité des contributeurs au sein des équipes « clés » de Debian. Tout n'est pas parfait pour autant et il arrive fréquemment que certains n'acceptent pas cette manière de procéder. La sélection des développeurs acceptés dans ces équipes peut paraître quelque peu arbitraire voire injuste. Par ailleurs, tout le monde n'a pas la même définition du service attendu de ces équipes. Pour certains, il est inacceptable de devoir attendre 8 jours l'intégration d'un nouveau paquet Debian ; d'autres patienteront 3 semaines sans peine. Aussi, des esprits chagrins se plaignent régulièrement de la « qualité du service » de certaines équipes.

1.3.2. Le rôle actif des utilisateurs

On peut se demander s'il est pertinent de citer les utilisateurs parmi les acteurs du fonctionnement de Debian, mais la réponse est un oui catégorique : ils y jouent un rôle crucial. Loin d'être « passifs », certains utilisateurs se servent quotidiennement des versions de développement et envoient régulièrement des rapports de bogues signalant des problèmes. D'autres vont encore plus loin et formulent des suggestions d'améliorations (par l'intermédiaire d'un bogue de « gravité » wishlist — littéralement « liste de vœux »), voire soumettent directement des correctifs du code source (patches, voir encadré Section 1.3.2.3, « Envoyer des correctifs »).

1.3.2.1. Signaler des bogues

L'outil majeur pour signaler des bogues dans Debian est le système de suivi de bogues Debian Bug Tracking System (Debian BTS) qui encadre le projet. Son interface web, partie émergée, permet de consulter tous les bogues répertoriés et propose d'afficher une liste (triée) de bogues sélectionnés sur de nombreux critères : paquet concerné, gravité, statut, adresse du rapporteur, adresse du mainteneur concerné, étiquette ou tag, etc. Il est également possible de consulter l'historique complet et toutes les discussions se rapportant à chacun des bogues.
Sous la surface, le système de suivi de bogues communique par courrier électronique : toutes les informations qu'il stocke proviennent de messages émis par les différents acteurs concernés. Tout courrier envoyé à sera ainsi consigné dans l'historique du bogue numéro 12345. Les personnes habilitées pourront « fermer » ce bogue en écrivant à un message exposant les motifs de cette décision (un bogue est fermé lorsque le problème signalé est corrigé ou plus valide). On signalera un nouveau bogue en transmettant à un rapport respectant un format précis, permettant d'identifier le paquet concerné. L'adresse propose enfin de manipuler toutes les « méta-informations » relatives à un bogue.
Le système offre bien d'autres fonctionnalités (notamment les tags, ou étiquettes) — nous vous invitons à les découvrir en lisant sa documentation en ligne :
Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps writing 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 (by default, a remote one run by Debian, but reportbug can also use a local server).
Cet outil cible d'abord les versions de développement, seules concernées par les corrections de bogues. Une version stable de Debian est en effet figée dans le marbre, à l'exception des mises à jour de sécurité ou très importantes (si par exemple un paquet n'est pas du tout fonctionnel). Une correction d'un bogue bénin dans un paquet Debian devra donc attendre la version stable suivante.

1.3.2.2. Traduction et documentation

Par ailleurs, de nombreux utilisateurs satisfaits du service offert par Debian souhaitent à leur tour apporter une pierre à l'édifice. Pas toujours pourvus des compétences de programmation nécessaires, ils choisissent parfois d'aider à la traduction de documents et aux relectures de celles-ci. Pour les francophones, tout ce travail est coordonné sur la liste .

1.3.2.3. Envoyer des correctifs

Les utilisateurs plus chevronnés peuvent être capables de fournir un correctif à un programme en envoyant un patch.
Un patch est un fichier décrivant des changements à apporter à un ou plusieurs fichiers de référence. Concrètement, on y trouve une liste de lignes à supprimer ou à insérer, ainsi (parfois) que des lignes reprises du texte de référence et replaçant les modifications dans leur contexte (elles permettront d'en identifier l'emplacement si les numéros de lignes ont changé).
On utilise indifféremment les termes « correctif » et « patch » car la plupart des corrections de bogues sont envoyées sous forme de patch. L'utilitaire appliquant les modifications données par un tel fichier s'appelle simplement patch. L'outil qui le crée s'appelle diff (autre synonyme de « correctif ») et s'utilise comme suit :
$ diff -u file.old file.new >file.patch
Le fichier file.patch contient les instructions permettant de transformer le contenu de file.old en celui de file.new. On pourra le transmettre à un correspondant pour qu'il recrée file.new à partir des deux autres comme ci-dessous :
$ patch -p0 file.old <file.patch
Le fichier file.old est maintenant identique à file.new.
In practice, most software is currently maintained in Git repositories and contributors are thus more likely to use git to retrieve the source code and propose changes. git diff will generate a file in the same format as what diff -u would do and git apply can do the same as patch.
Bien que la sortie de git diff soit un fichier qui peut être partagé avec d'autres développeurs, il existe généralement de meilleures façons de soumettre des modifications. Si les développeurs préfèrent recevoir les correctifs par courrier électronique, ils veulent généralement que les correctifs soient générés avec git format-patch afin qu'ils puissent être directement intégrés dans le dépôt avec git am. Cela préserve les méta-informations des commits et permet de partager plusieurs commits à la fois.
Ce flux de travail basé sur le courrier électronique est toujours populaire mais il tend à être remplacé par l'utilisation de merge requests (ou pull requests) chaque fois que le logiciel est hébergé sur une plateforme comme GitHub ou GitLab — et Debian utilise GitLab sur son serveur salsa.debian.org. Sur ces systèmes, une fois que vous avez créé un compte, vous pouvez fourcher le dépôt, créant une copie du dépôt dans votre propre compte, et vous pouvez alors cloner ce dépôt et y apporter vos propres modifications. À partir de là, l'interface web vous suggèrera de proposera une demande de fusion, en informant les développeurs de vos modifications, ce qui leur permettra de les examiner et de les accepter en un seul clic.

1.3.2.4. Les autres façons de contribuer

Tous ces mécanismes de contribution sont efficaces grâce au comportement des utilisateurs. Loin d'être isolés, ils forment une vraie communauté, au sein de laquelle de nombreux échanges ont lieu. Citons notamment l'activité impressionnante de la liste de discussion des utilisateurs francophones (le Chapitre 7, Résolution de problèmes et sources d'informations vous apportera plus d'informations sur cette liste).
Non contents de s'entraider sur des problèmes techniques qui les concernent directement, ceux-ci traitent aussi de la meilleure manière d'aider Debian et de faire progresser le projet — discussions provoquant souvent des suggestions d'amélioration.
Debian ne finançant aucune campagne publicitaire d'autopromotion, ses utilisateurs jouent un rôle essentiel dans sa diffusion et en assurent la réputation par le bouche-à-oreille.
Cette méthode fonctionne plutôt bien puisqu'on retrouve des inconditionnels de Debian à tous les niveaux de la communauté du logiciel libre : dans les install parties (ateliers d'installation, encadrés par des habitués, pour les nouveaux venus à Linux) organisées par les groupes locaux d'utilisateurs de Linux GULL, sur les stands associatifs des grands salons d'informatique traitant de Linux, etc.
Signalons que des volontaires réalisent affiches, tracts, autocollants et autres supports utiles pour la promotion du projet, qu'ils mettent à disposition de tous et que Debian fournit librement sur son site web et sur son wiki :

1.3.3. Teams, Blends, and Sub-Projects

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.

1.3.3.1. Existing Debian Sub-Projects and Blends

To each their own Debian! A sub-project is a group of volunteers interested in adapting Debian to specific needs. Beyond the selection of a sub-group of programs intended for a particular domain (education, medicine, multimedia creation, etc.), sub-projects are also involved in improving existing packages, packaging missing software, adapting the installer, creating specific documentation, and more. While a "blend" might not be exactly the same, it works quite similar and also tries to provide a solution for groups of people intending to use Debian for a particular domain. One could say that "Debian Pure Blends" is the successor of sub-projects.
Here is a small selection of current released Debian Pure Blends:
  • Debian Junior, by Ben Armstrong, offering an appealing and easy to use Debian system for children;
  • Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic and educational world;
  • Debian Med, d'Andreas Tille, se consacre au milieu médical ;
  • Debian Multimedia, which deals with audio and multimedia work;
  • Debian GIS, which takes care of Geographical Information Systems applications and users;
  • Debian Astro, for both professionals and hobby astronomers;
  • Debian Science, working on providing researchers and scientists a better experience using Debian;
  • Freedombox, made to develop, design and promote personal servers running free software for private, personal communications;
  • Debian Games, providing games in Debian from arcade and adventure to simulation and strategy;
  • DebiChem, destinée à la Chimie, fournit des suites et des programmes de chimie.
The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian Pure Blends. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.

1.3.3.2. Équipes administratives

La plupart des équipes administratives sont relativement fermées et ne recrutent que par cooptation. Le meilleur moyen d'y entrer est alors d'en aider intelligemment les membres actuels en montrant que l'on a compris leurs objectifs et leur mode de fonctionnement.
Les ftpmasters sont les responsables de l'archive de paquets Debian. Ils maintiennent le programme qui reçoit les paquets envoyés par les développeurs et les installe automatiquement, après quelques vérifications, sur le serveur de référence (ftp-master.debian.org).
Ils doivent aussi vérifier la licence des nouveaux paquets, pour savoir si Debian peut les distribuer, avant de les intégrer au corpus de paquets existants. Lorsqu'un développeur souhaite supprimer un paquet, c'est à eux qu'il s'adresse via le système de suivi de bogues et le « pseudo-paquet » ftp.debian.org.
L'équipe Debian System Administrators (DSA, ), comme on peut s'y attendre, est responsable de l'administration système des nombreux serveurs exploités par le projet. Elle veille au fonctionnement optimal de l'ensemble des services de base (DNS, Web, courrier électronique, shell, etc.), installe les logiciels demandés par les développeurs Debian et prend toutes les précautions en matière de sécurité.
Les listmasters administrent le serveur de courrier électronique gérant les listes de diffusion. Ils créent les nouvelles listes, gèrent les bounces (notices de non livraison) et maintiennent des filtres contre le spam (pourriel, ou publicités non sollicitées).
Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case for the bug tracking system (BTS), the package tracker, salsa.debian.org (GitLab server, see sidebar OUTIL GitLab, hébergement de dépôt Git et bien plus), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Équipes de développement, équipes transversales

Contrairement aux équipes administratives, les équipes de développement sont très largement ouvertes, même aux contributeurs extérieurs. Même si Debian n'a pas vocation à créer des logiciels, le projet a besoin de quelques programmes spécifiques pour atteindre ses objectifs. Évidemment développés sous une licence libre, ces outils font appel aux méthodes éprouvées par ailleurs dans le monde du logiciel libre.
Debian a développé peu de logiciels en propre, mais certains ont acquis un rôle capital et leur notoriété dépasse désormais le cadre du projet. Citons notamment dpkg, programme de manipulation des paquets Debian (c'est d'ailleurs une abréviation de Debian PacKaGe), et apt, outil d'installation automatique de tout paquet Debian et de ses dépendances, garantissant la cohérence du système après la mise à jour (c'est l'acronyme d'Advanced Package Tool). Leurs équipes sont pourtant très réduites, car un très bon niveau en programmation est nécessaire à la compréhension globale du fonctionnement de ce type de programme.
L'équipe la plus importante est probablement celle du programme d'installation de Debian, debian-installer, qui a accompli un travail titanesque depuis sa conception en 2001. Il lui a fallu recourir à de nombreux contributeurs car il est difficile d'écrire un seul logiciel capable d'installer Debian sur une douzaine d'architectures différentes. Chacune a son propre mécanisme de démarrage et son propre chargeur d'amorçage (bootloader). Tout ce travail est coordonné sur la liste de diffusion , sous la houlette de Cyril Brulebois.
L'équipe du programme debian-cd, plus réduite, a un objet bien plus modeste. Signalons que de nombreux « petits » contributeurs se chargent de leur architecture, le développeur principal ne pouvant pas en connaître toutes les subtilités, ni la manière exacte de faire démarrer l'installateur depuis le CD-Rom.
De nombreuses équipes ont des tâches transversales à l'activité de mise en paquet : essaie par exemple d'assurer la qualité à tous les niveaux de Debian. Quant à , elle fait évoluer la charte Debian en fonction des propositions des uns et des autres. Les équipes responsables de chaque architecture () y compilent tous les paquets, qu'elles adaptent à leur architecture le cas échéant.
D'autres équipes encadrent les paquets les plus importants pour en assurer la maintenance sans faire peser une trop lourde responsabilité sur une seule paire d'épaules ; c'est le cas de la bibliothèque C avec , du compilateur C avec ou encore de X.org avec (groupe également connu sous le nom de X Strike Force).