Programme de chef du projet Debian
Lucas Nussbaum

1 Qui suis-je, contributions précédentes à Debian

Actuel chef du projet Debian, français, 32 ans, utilisateur de logiciel libre depuis 1997, maître de conférences en informatique à l'Université de Lorraine où j'ai l'opportunité d'enseigner le logiciel libre et Debian dans le contexte d'un cursus d'administration système.

J'ai commencé à contribuer à Debian en 2005. Mes principales contributions, avant mon élection en tant que chef du projet Debian en 2013, sont les suivantes.

Ruby

Je me suis impliqué dans Debian en maintenant des paquets au sein de l'équipe pkg-ruby-extras. Je comaintiens les paquets de l'interpréteur et ai initié le travail sur notre nouvel assistant d'empaquetage, gem2deb (= dh-make-ruby + dh_ruby), qui facilite énormément l'empaquetage de logiciels Ruby et a amélioré significativement nos relations avec la communauté amont.

Collaboration avec Ubuntu

J'ai travaillé à l'amélioration des moyens de gérer les divergences entre Debian et Ubuntu, et pour faire revenir les améliorations d'Ubuntu dans Debian. J'ai beaucoup contribué à détendre les relations entre Debian et Ubuntu les premières années, aux pratiques comme l'énumération des modifications d'Ubuntu dans les entrées du journal de modifications d'Ubuntu, et ajouté des façons d'obtenir des renseignements à propos des paquets dans Ubuntu avec la boîte Ubuntu sur le système de suivi de paquets et la colonne Ubuntu dans le DDPO (plus de renseignements sur les diapositives d'une présentation au FOSDEM 2010).

Reconstructions de l'archive.

J'ai reconstruit tous les paquets de Debian de façon régulière depuis 2006. Par conséquent, j'ai soumis plus de 7000 bogues critiques FTBFS. Effectivement, ça m'a donné un peu mauvaise conscience, mais j'essaye de le voir comme une détection de problème a priori, pas seulement pour créer une cause de retard des publications ;). La même infrastructure était aussi utilisée pour tester les migrations majeures ou les modifications de chaîne de compilation impliquant GCC, Clang et Python (plus de renseignements sur les diapositives d'une présentation au FOSDEM 2007 et l'article sur la récente migration vers AWS).

Base de données ultime Debian (UDD)

Les services Debian (dak, wanna-build, BTS, DEHS, popcon, lintian, etc.) sont très hétérogènes en termes de technologies et d'interfaces. L'effet positif est que tout le monde peut très facilement développer un nouveau service et l'intégrer dans l'infrastructure existante. L'effet négatif est la grande difficulté pour combiner les données. La base de données ultime Debian résout cela en important toutes les données pertinentes de Debian (et des distributions dérivées) dans une seule base de données SQL. Plusieurs services ont été développés sur UDD (y compris la recherche de bogues et le tableau de bord du responsable Debian) et bien d'autres utilisent UDD comme source de données (plus de renseignements dans les exposés et diapositives au MSR 2010, et dans une présentation à DebConf9).

Introduction à l'empaquetage Debian

J'ai écrit une introduction à l'empaquetage Debian (paquet packaging-tutorial) pour fournir une documentation plus abordable par les futurs mainteneurs. Je l'ai utilisée parfois pour enseigner l'empaquetage Debian et elle a été traduite en allemand, français et espagnol. C'est aussi un bon moyen de promouvoir les bonnes pratiques, comme l'empaquetage avec dh (diapositive 26) ou les premiers pas pour s'impliquer dans Debian (s'impliquer dans des équipes, adopter des paquets existants, mais pas empaqueter plus de logiciels inutiles quand de meilleures alternatives existent déjà dans Debian, diapositive 42).

Autres

J’ai participé marginalement à l'équipe Debian Science. J'ai été intercesseur dans le processus de nouveaux membres. J'ai parfois aussi résumé de longs fils sur debian-devel@ (par exemple à propos de rolling et de la procédure permettant de rendre un paquet non maintenu orphelin).

(Un aperçu de mon premier mandat en tant que chef du projet Debian est donné dans la section 3.3.1 ci-dessous.)

En général, la plupart de mes contributions à Debian ont pour but de s'occuper de problèmes à l'échelle de la distribution (assurance qualité, traitement de données) et d'améliorer la collaboration et la communication (avec les nouveaux contributeurs et les distributions dérivées).

2 État de Debian, vision et objectifs

Debian et les distributions en général sont probablement à un moment important de leur histoire. Après avoir été le centre de beaucoup d'attention pendant longtemps, cette attention se déplace dans d'autres domaines du monde du logiciel libre. Bien sûr, cela ne signifie pas que Debian est mourante. Cela signifie probablement que les distributions ont quasiment résolu les problèmes sur lesquels elles travaillaient à l'origine et sont maintenant perçues comme des composants standard qui fonctionnent.

Que devrait faire le projet Debian à ce sujet ? Deux choses : nous améliorer sur ce que nous faisons déjà et travailler à relever de nouveaux défis importants du monde du logiciel libre.

2.1 Nous améliorer sur ce que nous faisons déjà

Debian est au centre de l'écosystème du logiciel libre. Elle est le principal intermédiaire entre les projets amonts qui développent plus de 20 000 logiciels libres et les utilisateurs finaux. Elle fournit intégration et robustesse au monde du logiciel libre. Ce sont, vraiment, de grandes réussites, en particulier compte tenu de la nature bénévole et communautaire de Debian. De plus, l'adoption et la popularité de Debian sont probablement à leur maximum historique : de nombreuses personnes se sentent concernées par ce que fait Debian, comme l'a montré la couverture des débats sur le système d'initialisation. Pouvons-nous faire mieux ? Probablement.

Dans le monde post-Snowden, nous devrions renforcer la fiabilité de notre archive de paquets grâce aux compilations reproductibles et aux uploads sans binaires utilisés (ne pas utiliser le paquet binaire construit sur la machine du développeur comme celui qui va dans l'archive). Nous devrions améliorer la qualité de nos paquets en utilisant davantage de tests automatisés ainsi que l'infrastructure ci.debian.net.

Nous devrions également continuer à travailler à devenir un projet plus accueillant, à la fois pour l'amont, pour nos dérivées et pour les contributeurs potentiels de tous types. Debian est souvent perçue comme une organisation difficile à appréhender, aussi bien sur les aspects organisationnel (les équipes), technique (les pratiques) et social. Il y a de très bonnes initiatives telles que le traqueur de correctifs, l'accueil pour les dérivées, le site des contributeurs Debian et le code de conduite Debian, mais il y a beaucoup plus à faire pour simplifier la collaboration avec les individus et organisations (par exemple : améliorer/simplifier les pratiques et la documentation du développement, développer les initiatives de parrainage, réactiver l'initiative debian-companies@).

2.2 Relever de nouveaux défis importants, à la manière de Debian

Notre rôle dans l'écosystème du logiciel libre devrait s'étendre au-delà d'être une distribution solide sur laquelle les autres peuvent se baser : nous devrions utiliser notre position existante et notre expertise pour contribuer à résoudre d'autres défis importants. Faire les choses à la manière de Debian améliore également la visibilité et l'impact de Debian elle-même, et donc les valeurs importantes pour lesquelles nous nous battons en tant que projet.

Tout d'abord, nous devrions tirer profit du statut actuel de Debian pour améliorer l'écosystème du logiciel libre dans son ensemble. Un bon exemple est le projet Debile (site web actuellement inaccessible, des transparents de présentation sont disponibles) qui cherche à exécuter des tests d'assurance qualité sur l'archive Debian : cela contribue à améliorer les outils d'assurance qualité, les logiciels testés (compilateurs, chaînes de compilation) et, quand les problèmes sont corrigés, Debian. Mais nous pourrions aller plus loin et imaginer fournir aux développeurs de bibliothèques amonts un moyen simple de tester des modifications potentielles sur toutes leurs dépendances inverses dans Debian.

Les dernières années ont vu une croissance importante de la taille des piles logicielles typiquement impliquées dans les logiciels d'infrastructure (pensez au cloud ou aux piles de virtualisation). Ils incluent généralement des dizaines de paquets entremêlés qui doivent tous être configurés de façon spécifique pour fonctionner ensemble. Nos solutions classiques pour gérer la configuration des paquets fonctionnent bien pour un paquet seul, mais sont moins adaptées à la configuration coordonnée de plusieurs paquets interagissant entre eux. C'est là que les outils de gestion de configuration excellent généralement, même si le nombre important d'outils pour cela montre qu'il n'existe pas encore de réponse unique à cette question. Comment les distributions peuvent-elles aider à faciliter la distribution de piles logicielles complexes ?

De nombreux usages sont en train de se déplacer des plates-formes traditionnelles (ordinateurs portables, stations de travail, serveurs) vers les tablettes et les smartphones. Il s'agit d'un monde dans lequel les systèmes d'exploitation libres, en particulier ceux basés sur Debian, se font rares. Bien sûr, un point bloquant important est la disponibilité limitée de plates-formes matérielles qui ne nécessitent pas de noyaux patchés ou de logiciels non libres. Mais il nous reste un long chemin avant de pouvoir faire fonctionner Debian sur tous nos ordinateurs, des smartphones aux serveurs.

Relever ces défis demande au projet d'être plus accueillant envers l'innovation et les expérimentations, même si elles ne sont qu'à l'état de prototypes. Souvent, nous tolérons simplement ce type d'expérimentations au lieu de les encourager, les jugeant trop tôt, ce qui rend plus difficile et plus lent que nécessaire de les mener au sein de Debian. Nous devrions également fournir une infrastructure pour soutenir ces expérimentations, comme des dépôts de développeurs non officiels (PPA).

3 Buts pour un nouveau mandat

3.1 Retour sur mon mandat actuel

Devenir chef du projet Debian est comme changer d'emploi. Vous découvrez que la réalité est légèrement différente par rapport à vos attentes et vous apprenez beaucoup de choses. Il y a vraiment deux facettes dans le rôle de chef du projet. L'une d'elles est d'être un administrateur du projet, de s'assurer que le projet reste en bonne forme et d'adoucir les problèmes qui rendent Debian frustrante. Cela implique beaucoup de petites tâches dont je vais énumérer une petite partie : j'ai aidé à faire grandir l'équipe en charge de la marque qui a lancé l'enregistrement du logo Debian comme une marque déposée. J'ai révoqué toutes les délégations anciennes et inactives pour créer une image claire des délégués actuels (avec l'aide de Moray Allan). J'ai défini des critères pour l'évaluation des potentielles organisations certifiées (avec l'aide des assistants DPL).

L'autre aspect du rôle est d'encourager et de travailler sur des projets particulièrement importants pour Debian. Par exemple, j'ai mené une étude sur les nouveaux contributeurs (pour l'empaquetage) afin de mieux identifier les nombreux obstacles qu'il faut surmonter quand on commence à contribuer à Debian. Quelques idées qui en ont découlé doivent toujours être mises en œuvre, mais un résultat important a été qu'après une discussion avec Asheesh Laroia at DebConf, j'ai développé how-can-i-help, un assistant simple pour mettre en avant les opportunités de contribution à Debian dans les paquets installés localement (présenté dans ce message de bits.d.o).

De plus, même si c'est vraiment une contribution mineure, je suis plutôt fier d'avoir proposé l'idée et un prototype d'implémentation pour les paquets importants/clés, qui ont évolué en quelque chose qui fait partie de la suppression automatisée des paquets non clés ayant des bogues critiques pour la publication, ce qui, je l'espère, aidera à réduire la durée du prochain gel.

Il y a bien plus, bien sûr, tel que décrit dans mon rapport quotidien (master:/srv/leader/news/bits-from-the-DPL.txt.*) et dans mes Nouvelles du chef du projet (04 05 06 07 08 09 10 11 12+01 01+02). De plus, pour améliorer l'idée de ce que fait et prévoie le chef du projet Debian, j'ai aussi rendu (la plupart de) ma TO-DO liste publique et l'ai incluse dans mes rapports mensuels, ce que je considère être une bonne étape vers plus de transparence.

3.2 Pourquoi je me présente à nouveau ?

Ce n'a pas été une décision facile à prendre. Comme je l'ai déjà mentionné par le passé, la charge de travail du chef du projet Debian est énorme. Je ne m'attendais pas à ce qu'elle soit légère, bien sûr, mais c'est pire que je ne l'imaginais : je sais que si je ne passe pas entre une journée et demie et deux journées complètes par semaine à travailler pour Debian, mon retard s'accumule. Je dois également admettre que je me sens plutôt en manque de hacking : j'adorerais passer plus de temps sur des choses techniques.

Mais il y a bien plus de raisons de me représenter.

La première est qu'il s'agit de Debian, bien sûr. Nous devrions tous être très fiers de ce que nous bâtissons ensemble. Je me sens très honoré de jouer un tel rôle dans une si belle communauté. Vous êtes tous géniaux, vraiment.

Une autre raison est que j'ai appris beaucoup de choses durant cette année en tant que chef du projet et qu'il ne me semblerait pas très juste de partir maintenant sans d’abord redonner un peu plus. Il y a aussi des choses qui ne se sont pas très bien passées et j'aimerais avoir une chance de faire mieux.

Enfin, il semble que les débats sur le système d'initialisation approchent de leur fin (c'est en tout cas ce que j'espère). Après ces temps très difficiles pour le projet, je pense qu'un peu de stabilité pourrait être utile, notamment parce que nous sommes en plein milieu d'un cycle.

3.3 Plans spécifiques pour un nouveau mandat

Si je suis élu pour un mandat supplémentaire, je continuerai bien sûr sur le même chemin que durant mon premier mandat (en appliquant également les leçons apprises de ce qui ne s'est pas si bien passé que ça durant ce mandat). Toutefois, il y a également deux domaines sur lesquels je prévois de me concentrer.

3.3.1 Permettre une meilleure compréhension de l'état financier de Debian

Les ressources disponibles de Debian et son budget annuel sont dans un état bien plus flou que ce que nous voudrions. Ainsi, il est très difficile de répondre à des questions telles que Pouvons-nous nous permettre de dépenser telle somme sur tel projet ?. Avec l'équipe des auditeurs et nos organisations de confiance, je prévois de travailler à l'amélioration du suivi de nos revenus et de nos dépenses pour qu'il soit possible de produire un budget annuel, au moins approché, de Debian. Il y a d'autres tâches dans ce domaine, comme l'amélioration de notre infrastructure de dons et nos processus de remboursement. L'issue prévue est qu'en travaillant maintenant sur ces problèmes, nous facilitions plus tard beaucoup de processus et de décisions liés à l'argent : utiliser les ressources financières de Debian pour sponsoriser plus de « sprints », acheter de meilleures infrastructures, résoudre des problèmes ne pouvant être résolus d'une autre façon.

3.3.2 Atteindre une gouvernance durable dans Debian

Notre modèle actuel pour la gouvernance de Debian ne passe pas très bien à très grande échelle, comme l'avait par exemple noté Stefano Zacchiroli lors de sa présentation de chef du projet à DebConf12 (transparents  22 et 23). Cela nécessite de trouver une personne pouvant consacrer beaucoup de temps à Debian pendant une année complète, ce qui réduit la liste des candidats potentiels. Le chef du projet idéal devrait également avoir un ensemble très varié de connaissances et compétences (techniques, comptables, légales, en gestion) qu'il est pratiquement impossible de trouver chez une seule personne, mais qu'il serait possible de trouver au sein d'une équipe.

De nombreuses options ont été proposées et parfois essayées au cours du temps : équipe du DPL, second, assistants du DPL, etc. L'initiative des assistants du chef du projet a fourni une aide précieuse pour quelques problèmes, mais est également décevante sur certains aspects : (1) le nombre de participants était plutôt bas (plusieurs réunions avec deux ou trois participants, ce qui m'a incité à les arrêter depuis début 2014) : (2) je ne pense pas qu'elle ait donné une meilleure vision des charges du chef du projet aux participants ; (3) son organisation l'a empêchée d'aider sur certains aspects du rôle de chef de projet — par exemple, quelques discussions internes auraient pu être utiles pour avoir un retour rapide sur les moyens de régler des problèmes spécifiques, mais c'est difficile à faire dans un canal de discussion public.

Je prévois d'essayer une variante de l'idée des assistants du chef de projet, qui pourrait être résumée comme un conseil tournant : je compte partager des informations privées du chef de projet (comme des courriels envoyés à leader@) avec un ensemble de développeurs actifs sur des tâches de la liste TO-DO du chef de projet et utiliser ce groupe comme un conseil consultatif pour aborder des problèmes et idées avant qu'ils ne soient débattus dans une audience plus large. Je crois que ce serait une solution pour : (1) partager la charge de travail du chef du projet Debian ; (2) améliorer la connaissance des activités du chef du projet des futurs candidats potentiels ; (3) obtenir des retours plus tôt et prendre de meilleures décisions ; (4) permettre de participer aux activités de chef du projet Debian à des personnes qui n'ont pas le temps suffisant pour se présenter.

Bien sûr, il y a le risque de créer une cabale et de réduire la transparence. Je m'engage totalement à éviter cela. En guise d'implémentation initiale, je justifierais chaque mois (probablement dans une note du rapport quotidien) qui fait partie de ce conseil en fonction des activités du mois précédent. En termes de confidentialité, les membres du conseil recevraient les courriels envoyés à leader@ et un alias supplémentaire (leader-private@) pourrait être créé pour les informations ne devant pas être partagées avec le conseil. Je m'engage également à maintenir le même niveau d'information à propos des activités du chef du projet (rapports quotidiens, courriels mensuels). Je voudrais également signaler que beaucoup de nos équipes ont des canaux de discussion privés (listes de diffusion ou IRC) et que la nature privée de cette expérimentation est principalement un moyen d'officialiser ce qu'il se passe déjà quand le chef du projet Debian décide d'inclure une personne pertinente dans une discussion non publique ou de consulter quelqu'un dans une discussion IRC privée. Dans un sens, les assistants du chef du projet et le conseil seraient similaires aux canaux de discussion publics/privés de nos équipes.

3.3.3 Autres

Bien sûr, il y a beaucoup d'autres choses que je voudrais voir arriver (consultez cette page pour une liste — certaines idées nécessitent plus de discussions d'abord). Je travaillerais certainement dessus si j'en avais le temps, mais après un mandat en tant que chef du projet Debian, je pense que les deux domaines décrits précédemment (mieux comprendre la situation financière de Debian, gouvernance durable) sont vraiment ce qu'il faut pour rendre le projet plus simple à gérer à l'avenir.

4 Réfutations

4.1 Neil McGovern

Le programme de Neil montre beaucoup d'expérience et de compétences dans de nombreux domaines de Debian. Cela ne couvre pas toutes les compétences nécessaires à un DPL, mais c'est probablement inévitable − j'étais dans la même situation il y a un an. Il s'agit de quelque chose que ma proposition de conseil de DPL pourrait contribuer à régler, en fournissant une expérience directe des tâches du chef du projet pour les potentiels candidats au poste.

Je suis d'accord avec la vision de Neil sur la situation actuelle du projet (Où en sommes-nous). Je suis également en accord avec lui sur le fait que nous devrions avoir pour but de rester pertinent pour la communauté et que notre logiciel devrait continuer à intégrer, comme il l'écrit. Mais, comme je l'ai dit, je pense que nous devrions relever des défis non techniques (par exemple devenir un projet plus accueillant) en plus des défis techniques et que nous devrions également relever d'autres défis que nous ne réglons pas encore (voir la section 2.2 de mon programme). Autrement dit, continuer à faire ce à quoi nous sommes bons (ce sur quoi Neil et moi sommes évidemment d'accord), mais également apporter plus de fun en travaillant sur des défis du logiciel libre importants et difficiles à relever, où notre expertise en tant que distribution peut s'avérer utile.

Les projets plus spécifiques (Comment puis-je aider) décrits dans le programme de Neil sont importants, bien que certains d'entre eux ne soient pas très précis, malheureusement − j'aurais aimé en savoir plus sur comment, s'il est élu en tant que chef du projet Debian, il a prévu de travailler sur ces projets. Par exemple, il y a consensus large sur le fait que notre infrastructure devrait être modernisée (y compris en ajoutant des PPA), mais c'est très difficile et cela nécessite certainement plus qu'un appui.