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

Les développeurs Debian ont des responsabilités diverses : membres attitrés du projet, ils infléchissent grandement les directions qu'il prend. Un développeur Debian est généralement responsable d'au moins un paquet, mais selon son temps disponible et ses envies, il a le loisir de s'engager dans de nombreuses équipes et projets, développant ainsi ses responsabilités.
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 :
La charte encadre très bien tout ce qui a trait au côté technique de la mise en paquet. La taille du projet soulève aussi des problèmes organisationnels ; ils sont traités par la constitution Debian, qui fixe une structure et des moyens de décision. En d'autres termes, une structure formelle de gouvernance.
Cette constitution définit un certain nombre d'acteurs, de postes, les responsabilités et les pouvoirs de chacun. On retiendra que les développeurs Debian ont toujours le pouvoir ultime de décision par un vote de résolution générale — avec nécessité d'obtenir une majorité qualifiée de trois quarts pour les changements les plus importants (comme ceux portant sur les textes fondateurs). Cependant, les développeurs élisent annuellement un « leader » pour les représenter dans les congrès et assurer la coordination interne entre les différentes équipes ; cette élection est toujours une période d'intenses discussions. Le rôle du Debian Project leader (DPL) n'est pas formellement défini par un document et il est d'usage que chaque candidat à ce poste donne sa propre définition de la fonction. En pratique, le leader a un rôle représentatif auprès des médias, un rôle de coordination entre les équipes « internes » et un rôle de visionnaire pour donner une ligne directrice au projet, dans laquelle les développeurs peuvent s'identifier : les points de vue du DPL sont implicitement approuvés par la majorité des membres du projet.
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.
Depuis sa fondation, le projet a été successivement dirigé par 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, etJonathan Carte.
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.
La procédure de « résolution générale » (GR) est entièrement détaillée dans la constitution, de la période de discussion initiale au décompte final des voix. L'aspect le plus intéressant de ce processus est que, lorsqu'il s'agit d'un vote réel, les développeurs doivent classer les différentes options de vote entre eux et le gagnant est sélectionné avec une méthode Condorcet (plus précisément, la méthode Schulze). Pour plus de détails, voir :
Même si cette constitution instaure un semblant de démocratie, la réalité quotidienne est très différente : Debian suit naturellement les lois du logiciel libre et sa politique du fait accompli. On peut longtemps débattre des mérites respectifs des différentes manières d'aborder un problème, la solution retenue sera la première qui soit à la fois fonctionnelle et satisfaisante... elle sera également le fruit des efforts consentis par une personne compétente.
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 :
Les utilisateurs peuvent aussi utiliser la ligne de commande pour signaler des bogues avec l'outil reportbug. Il peut vérifier au préalable que le bogue concerné n'a pas déjà été référencé, ce qui évite la création de doublons. Il rappelle la définition de la gravité pour qu'elle soit aussi juste que possible (le développeur pourra toujours affiner par la suite le jugement de l'utilisateur). Il permet d'écrire un rapport de bogue complet, sans en connaître la syntaxe précise, en l'écrivant puis en proposant de le modifier. Ce rapport sera ensuite transmis via un serveur de courrier électronique (local par défaut, mais reportbug peut aussi utiliser un serveur distant).
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.
En pratique, la plupart des logiciels sont actuellement maintenus dans des dépôts Git et les contributeurs sont donc plus susceptibles d'utiliser git pour récupérer le code source et proposer des modifications. git diff va générer un fichier au même format que ce que ferait diff -u et git apply peut faire la même chose que 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. Équipes, "Blends" et sous-projets

Debian a d'emblée été organisé autour du concept de paquet source, chacun disposant de son mainteneur voire de son groupe de mainteneurs. De nombreuses équipes de travail sont peu à peu apparues, assurant l'administration de l'infrastructure, la gestion des tâches transversales à tous les paquets (assurance qualité, charte Debian, programme d'installation, etc.), les dernières équipes s'articulant autour de sous-projets et de "Blends".

1.3.3.1. Sous-projets Debian existants et "Blends"

À chaque public sa distribution Debian ! Un sous-projet est un regroupement de volontaires intéressés par l'adaptation de Debian à des besoins spécifiques. Au-delà de la sélection d'un sous-ensemble de logiciels dédiés à un usage particulier (éducation, médecine, création multimédia...), les sous-projets essaient souvent d'améliorer les paquets existants, de mettre en paquet les logiciels manquants, d'adapter l'installateur, de créer une documentation spécifique, etc. Bien que un "blend" pourrait ne pas être exactement pareil, ils fonctionne presque de la même manière et essaient également de fournir une solution pour les groupes de personnes ayant l'intention d'utiliser Debian pour un domaine particulier. On pourrait dire que les "Debian Pure Blends" sont les successeurs des sous-projets.
Voici une petite sélection des "Blends" actuellement publiés :
  • Debian Junior, de Ben Armstrong, vise à proposer aux enfants un système Debian facile et attrayant ;
  • Debian Edu, de Petter Reinholdtsen, se focalise sur la création d'une distribution spécialisée pour le monde universitaire et éducatif ;
  • Debian Med, d'Andreas Tille, se consacre au milieu médical ;
  • Debian Multimedia, qui s'occupe des créations audios et multimédias ;
  • Debian GIS, qui s'occupe des applications SIG (systèmes d'information géographiques) et de leurs utilisateurs ;
  • Debian Astro, aussi bien pour les astronomes professionnels que pour les amateurs ;
  • Debian Science, permet de fournir aux chercheurs et aux scientifiques une meilleure expérience en utilisant Debian ;
  • Freedombox, fait pour développer, concevoir et promouvoir les serveurs personnels utilisant des logiciels libres pour les communications privées et personnelles ;
  • Debian Games, fournissant des jeux dans Debian de l'arcade et l'aventure à la simulation et la stratégie ;
  • DebiChem, destinée à la Chimie, fournit des suites et des programmes de chimie.
Gageons que le nombre des projets va continuer à croître avec le temps et une meilleure perception des avantages des "Debian Pure Blends". En s'appuyant pleinement sur l'infrastructure existante de Debian, ils peuvent en effet se concentrer sur un travail à réelle valeur ajoutée et n'ont pas besoin de se soucier de « resynchroniser » avec Debian puisqu'ils évoluent dès le début au sein du projet.

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).
Chaque service spécifique dispose de sa propre équipe d'administration, constituée généralement par les volontaires qui l'ont mise en place (et, souvent, programmé eux-mêmes les outils correspondants). C'est le cas du système de suivi de bogues (BTS), du système de suivi de paquets (Package Tracking System — PTS), d'salsa.debian.org (serveur GitLab, voir encadré OUTIL GitLab, hébergement de dépôt Git et bien plus), des services disponibles sur 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).