Programme de chef du projet Debian

Lucas Nussbaum

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

Français, 31 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 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 de 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 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 comme une cause de retard des publications. La même infrastructure est 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 notre 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 bugs.cgi et le tableau de bord du responsable Debian) et bien d'autres utilisent UDD comme sources de données (plus de renseignements en exposé 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 accessible aux futurs mainteneurs. Je l'ai utilisé 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: Je participe 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).

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 à l'amélioration de la collaboration et la communication (avec les nouveaux contributeurs et les distributions dérivées).

État de Debian, vision et objectifs

État du projet

Le projet Debian est en très bon état interne. Bien sûr, des améliorations sont toujours possibles, et les coins sombres existent, mais toutes nos équipes principales sont raisonnablement fonctionnelles, notre infrastructure est en bon état général, et aucune grosse crise Debian n'est prévisible. Stefano Zacchiroli a joué un rôle important pour arriver dans cet état, et nous devrions tous lui en être particulièrement reconnaissant.

Cependant, j'ai souvent l'impression que le projet perd de l'élan, de l'énergie positive, et ralentit. Cela se passe comme si nous vivions sur les acquis du passé. Beaucoup de choses très sympathiques se passent dans l'écosystème Debian, mais souvent à l'extérieur du projet Debian. C'est bien d'être une base solide pour de nombreuses distributions dérivées innovantes, mais devons-nous nous contenter du rôle de supermarché de paquets ?

À quoi Debian devrait ressembler dans cinq ans ?

Debian devrait viser au renforcement de sa position au centre de l'écosystème du logiciel libre. Elle devrait être le principal intermédiaire actif entre les projets amonts et les utilisateurs finaux. Bien sûr, fournir une bonne base aux dérivées est important, parce que les utilisateurs des dérivées sont des utilisateurs de Debian, même si certains d'entre eux ne le reconnaissent pas. Nous devrions viser aussi au renforcement de la visibilité et de l'impact de Debian elle-même, parce que les valeurs extrêmement importantes pour lesquelles nous nous battons en tant que projet sont souvent négligées par nos dérivées.

Oui, cela signifie travailler à faire revenir certains des trucs sympathiques faits par les dérivées dans Debian et créer plus de produits Debian. Par exemple, nous avons fourni une version rolling plutôt bonne depuis près de treize ans avec testing, mais nous avons totalement échoué à le présenter comme quelque chose de pris en charge et d'utilisable par les utilisateurs finaux. Maintenant qu'Ubuntu envisage de basculer vers un cycle de vie de deux ans avec en plus une version rolling, ils pourraient obtenir toute la bonne presse à notre place. Ne pourrions-nous pas travailler à répondre aux différents besoins et cas d'utilisation avec différents produits (version rolling, peut-être des images autonomes), sans compromettre la qualité de nos versions stables ? Je pense même qu'avoir plus d'utilisateurs de testing augmenterait la qualité de nos versions stables en ayant plus d'yeux pour trouver des bogues (rappel : le taux de bogues signalés diminue).

Comment y parvenir ?

Promouvoir l'innovation au sein de Debian

Nous devrions mieux accueillir l'innovation et les expérimentations au sein du projet. Souvent, nous les tolérons à peine, et la bureaucratie les rend difficiles et lentes à mener.

Même si ce n'est pas le rôle du chef de projet de décider des directions du projet, si je suis élu, j'encouragerai (les discussions sur) les idées innovantes, examinerai comment les ressources du projet peuvent être utilisées pour les soutenir, et communiquerai sur les expérimentations. Bien sûr, ces expérimentations devront contenir des mesures de succès et les avertissements nécessaires (pas de garantie à long terme du maintien de l'expérimentation, pas de suivi en sécurité, etc.)

Améliorer l'accessibilité de Debian et baisser la barrière pour contribuer

Alors que de plus et plus de gens utilisent des logiciels libres (qui sont des contributeurs potentiels), de plus et plus de projets sont en compétition avec nous pour attirer les contributeurs. De nombreux efforts ont été réalisés dans ce domaine, mais il reste encore beaucoup de choses à améliorer.

Nous devrions améliorer notre documentation pour les développeurs (j'ai moi-même contribué à cela en écrivant une introduction à l'empaquetage Debian et en tant qu'éditeur de la référence du développeur Debian). Certaines équipes n'ont toujours pas de documentation adéquate de leur mode de fonctionnement et outils dans les sous-pages de wiki.d.o/Teams. Comment pouvons-nous attendre que les développeurs restent si la documentation n'est pas satisfaisante. De la consolidation est aussi possible ici : par exemple, nous n'avons pas vraiment de documentation de référence du mode de fonctionnement de l'empaquetage avec Git (j'ai commencé une initiative à ce propos lors de DebConf11, mais elle est surtout restée en sommeil depuis). C'est très mauvais : d'un point de vue de contributeur, cela fait comme si chaque équipe Debian était un projet séparé.
Nous devrions simplifier nos pratiques de développement en (1) annonçant mieux les pratiques recommandées et en les (2) implémentant plus rapidement dans la plupart des paquets (cela prend souvent des années avant qu'une bonne nouvelle pratique soit adopté majoritairement). Par exemple, nous devrions annoncer qu'à moins de savoir ce que vous faites (oui, il y a de bonnes raisons de faire les choses autrement) : vous devriez utiliser dh, vous devriez maintenir vos paquets au sein d'une équipe ou, en absence d'équipe adéquate, utiliser un dépôt Git du projet collab-maint (et penser à rechercher des comainteneurs). Nous devrions aussi essayer de basculer les paquets existants vers ce modèle, et documenter proprement ce processus, mais je me répète.
Nous devrions améliorer notre infrastructure de parrainage (rappel : la moitié des mainteneurs de paquets ne sont ni développeurs Debian, ni mainteneurs Debian) : debexpo et mentors.d.n sont géniaux, mais pourraient avoir plus de fonctionnalités, comme plus de tests automatisés d'assurance qualité (construction, piuparts). Par ailleurs, je vois deux façons de combattre la situation de manque de main d'œuvre pour l'examen des paquets : (1) enfin mettre en place des dépôts de paquets personnels, pour que l'attente d'examen devienne un peu moins pénible et (2) demander aux non développeurs Debian d'examiner les paquets à la façon d'un site web social (c'est aussi une façon très sympathique d'apprendre).
Nous devrions continuer à pousser pour la maintenance collaborative en équipe. Nous devrions aussi réfléchir à réduire la propriété de paquet. Alors qu'avoir des mainteneurs qui se sentent responsables de leurs paquets (et sont souvent de véritables experts de ces paquets) est une force importante de Debian, les mainteneurs devraient penser en termes de paquets dont je m'occupe actuellement dans Debian plutôt qu'en paquets que je possède dans Debian. La pratique actuelle de mises à jour indépendante (NMU) (une modification que j'avais pilotée en 2008) est une bonne base, mais nous pourrions profiter d'une petite évolution culturelle en accueillant mieux les contributions d'autres contributeurs. Par exemple, nous pourrions généraliser le modèle de sécurité de collab-maint (c'est-à-dire tous les développeurs Debian ont accès en écriture) pour plus de dépôts de paquets.
Cependant, la maintenance en équipe cache parfois les cas où plus aucun mainteneur n'est actif dans une équipe. Nous devrions aussi nous améliorer à identifier ces cas, et adapter notre infrastructure et nos procédures en fonction.

Améliorer la communication avec les projets amont

Les mainteneurs n'ont souvent pas de contact du tout avec les développeurs amont. Nous devrions favoriser les relations fonctionnelles avec les projets amont, en les faisant participer à la maintenance de paquet s'ils le veulent et en leur transmettant les renseignements sur les bogues affectant Debian ou les correctifs du paquet Debian (améliorant http://patch-tracker.d.o/).

Ce qui précède devrait vous donner une bonne idée de mes positions. Bien sûr, je n'aurai sans doute pas le temps de m'en occuper moi-même (et devenir chef du projet rend cela encore plus improbable), mais vous savez au moins ce que je considère important et ce que j'encouragerai.

Rôle du chef de projet et modèle de gouvernance

Sur la gouvernance

J'ai l'intention de continuer l'initiative d'assistants du chef de projet. De nombreux autres développeurs Debian (y compris d'anciens chefs de projet) ont d'excellentes idées pour le projet, mais peu peuvent dédier suffisamment de temps pour être le chef du projet. J'aimerais construire un environnement leur permettant de partager la charge de travail du chef de projet et avancer avec leurs idées.

La direction globale que j'aimerais viser ici est une équipe ouverte de développeurs Debian pilotant le projet, menée par le chef du projet. À long terme, cela pourrait permettre de diminuer la charge spécifique du chef de projet, qui deviendrait alors un simple responsable de ce groupe. Bien sûr, ça ne doit pas tourner à la cabale et ne doit pas affecter les processus de prise de décision à base de consensus. Aussi, par souci de clarté, je n'ai pas l'intention d'aller dans la direction d'une équipe du chef de projet institutionnalisée pendant mon mandat : je pense que nous avons besoin de plus de temps pour comprendre comment une équipe du chef de projet, institutionnalisée ou pas, peut apporter quelque chose au projet et pour évaluer les inconvénients d'une équipe du chef de projet institutionnalisée.

Sur la médiation

Une partie importante du rôle de chef du projet est d'être un médiateur et de contribuer à résoudre les problèmes complexes qui surviennent nécessairement de temps en temps dans n'importe quel projet à base de bénévolat.

Une chose que j'aimerais faire avancer dans ce contexte est un observatoire du projet : rassembler un ensemble de mesures à propos du projet afin de détecter les problèmes a priori et se rapprocher des gens avant que le problème ne dégénère en grosse crise. Bien sûr, tout ne peut pas être détecté en utilisant ce genre de mesures et j'ai aussi l'intention d'utiliser les réunions d'assistants du chef de projet comme un moyen pour construire une vision plus étendue du projet et de l'évolution de ses problèmes.

J'ai parfois eu l'impression par le passé que le chef du projet n'était pas nécessairement la meilleure personne pour piloter une médiation (parce qu'il n'avait pas de (bonnes) relations personnelles avec les développeurs Debian concernés ou parce qu'il n'avait ce genre de relations que d'un côté). Les réunions d'assistants du chef de projet seront de bonnes opportunités pour trouver des médiateurs plus adéquats si nécessaire.

Sur l'organisation

L'organisation construite par Stefano Zacchiroli pendant ses trois mandats s'est montrée particulièrement efficace. Si je suis élu, j'opterai pour la même organisation, y compris les courriers mensuels sur d-d-a et le journal d'activité quotidien privé. Les réunions d'assistants du chef de projet seront organisées régulièrement (au moins toutes les deux semaines).

Réfutation

Alors, nous sommes trois candidats (ce que je trouve un peu décevant – j'avais apprécié les précédentes campagnes avec de nombreux candidats puisqu'elles ont tendance à produire plus d'idées pour le projet), avec trois programmes plutôt différents.

Moray Allan

Le programme de Moray fournit une description très détaillée de sa façon de se comporter s'il devenait chef du projet – et même de la façon dont le chef du projet devrait se comporter. Je suis d'accord avec l'essentiel et m'inspirerai de ces recommandations si je suis élu.

Ce qui manque à mon avis le plus au programme de Moray est une vision pour le projet et ses objectifs à l'échelle du projet. Il fournit une perspective historique et sa vision de l'état actuel, mais où voudrait-il emmener le projet pendant son mandat ? C'est un symptôme de notre désaccord plus profond sur le rôle de chef du projet. Le programme de Moray et ses réponses sur debian-vote@ donnent l'impression qu'il perçoit le chef du projet comme un rôle de responsable, comme un administrateur. Cependant, je pense que le projet s'attend maintenant à ce que le chef du projet fasse plus en termes de coordination, de pilotage du projet et de gestion de son programme, comme Stefano Zacchiroli a été très actif et brillant dans ces domaines. Moray écrit Je vois la coordination routinière par le chef de projet comme l'indication d'un problème plus large qui devrait être réglé.

Si je suis élu, je considèrerai que s'assurer de la coordination du projet fait partie des tâches du chef de projet. Je tirerai profit de l'initiative d'assistants du chef de projet (que j'ai proposé de renommer en force de pilotage de Debian) pour créer un groupe ouvert de personnes intéressées pour faire avancer le projet. Bien sûr, c'est à propos d'ouverture des débats, de proposition de nouvelles idées, de synthèse des débats pour s'assurer d'une large prise de conscience et participation, pas à propos de modification du mode de prise de décisions dans le projet.

Gergely Nagy (algernon)

Seul candidat avec un surnom, ce qui en dit long sur le manque d'inspiration des deux autres candidats… :)

Je suis d'accord avec l'essentiel du programme de Gergely, par exemple sur l'état du projet, sur la valeur de la communication directe et des événements locaux, et sur le besoin de recruter de nouveaux contributeurs.

J'aurais aimé voir dans son programme plus d'exemples de réalisations précédentes dans Debian qui montrent ses positions habituelles, ainsi que ses capacités à piloter des projets. Gergely a vraiment beaucoup d'idées et d'enthousiasme pour les faire avancer, mais il n'a pas l'air d'avoir eu beaucoup d'expérience dans ce domaine : la plupart des exemples mentionnés dans son programme n'ont pas eu lieu dans Debian. C'est vrai qu'acquérir ce genre d'expérience dans Debian est difficile. Si je suis élu, je m'assurerai que l'initiative d'assistants du chef de projet contribue à apporter une solution à ce problème, en fournissant un environnement facilitant les retours et conseils sur la façon de faire avancer les idées, et j'espère pouvoir travailler avec Gergely dans ce contexte.