Programme de chef du projet Debian de Steve McIntyre

Introduction

Je suis développeur Debian depuis octobre 1996. J'ai rejoint le projet à l'origine pour maintenir la version Debian de mikmod. J'étais alors le développeur amont et je souhaitais que la version Debian marche bien aussi. À cette époque la procédure de nouveau mainteneur était plus simple qu'aujourd'hui : j'ai installé Debian, puis, deux jours après, j'envoyais un courriel à Bruce Perens avec une clef PGP et lui demandais une accréditation pour Debian. Il m'a répondu immédiatement avec tous les détails pour ouvrir le compte — j'étais admis !

À partir de ce moment-là, j'ai travaillé sur un grand éventail de paquets, certains lourds et d'autres moins. C'est au sein de l'équipe debian-cd que j'ai réalisé le travail probablement le plus notable pour Debian : j'y ai développé le logiciel debian-cd lui-même, puis j'ai utilisé le même logiciel pour créer les CD officiels (maintenant les DVD) qui accompagnent chaque version de Debian. J'ai été impliqué dans la création de CD de toutes les versions majeures et intermédiaires depuis Hamm.

Objectifs

L'essentiel de ce que je voudrais voir changer ou s'améliorer dans Debian sont des problèmes bien identifiés et qui nous affectent depuis longtemps. Je peux les ranger dans deux catégories : les problèmes de relation et le professionnalisme, même si ces deux notions se recouvrent largement dans certains cas.

Problèmes de relations

La communication à l'intérieur du projet

C'est un cauchemar permanent ; aussi loin que je m'en souvienne, les candidats au poste de chef du projet ont toujours promis de travailler à l'amélioration de la communication au sein du projet. Il y a plusieurs domaines où la communication a été problématique dans le passé. Quelquefois, les efforts du chef du projet Debian ont pu aider à arranger les choses, mais le plus souvent, il n'y a pas eu d'amélioration visible.

Des nouvelles simples et régulières des différentes équipes sur leur état, au sein du projet, peuvent ici jouer un grand rôle. Également, des comptes-rendus réguliers du chef du projet sont nécessaires pour être sûr que la communauté Debian est bien consciente de ce qui est dit et fait en son nom. Même si une partie des comptes-rendus ne fait que dire « désolé, j'ai été pris par ma vraie vie et je n'ai pas pu faire grand-chose », simple confirmation que ces emplois ne sont pas inoccupés, c'est mieux que rien. Je souhaite encourager ces mises au point, et si je suis élu, je m'engage à diffuser régulièrement des informations du chef du projet Debian.

Listes de diffusion et canal IRC

De récents événements suggèrent que nous avons beaucoup à apprendre d'Ubuntu et de son code de conduite. Une parole libre est un idéal auquel nombre d'entre nous dans Debian sommes attachés, mais le langage négatif et violent qui apparaît souvent, tout au long des listes de diffusion et des canaux IRC, n'est pas productif. À cause de cela, beaucoup de gens dans le projet et en dehors sont devenus réticents à contribuer à nos discussions techniques. Cela nous fait du mal directement et indirectement : la perception publique du projet peut souffrir quand nos contacts extérieurs sont inamicaux.

Nous avons besoin de nous mettre d'accord sur un code de conduite de Debian et ensuite de le respecter. Nous avons déjà l'ébauche d'un tel document, et j'aimerais contribuer à le développer et à encourager les autres développeurs à l'adopter.

Formation et nouveaux membres (NM)

Actuellement, le processus d'admission des NM comporte des tests détaillés pour tester les capacités techniques du candidat et, bien sûr, c'est une chose utile à faire. Malheureusement, il n'y a pas de sélection sur les qualités relationnelles ; mais nous avons besoin de travailler ensemble comme une communauté !

On demande souvent aux NM de montrer leurs capacités en construisant un nouveau paquet ou en s'occupant d'un paquet orphelin. Cela peut être un bon moyen pour tester les capacités d'empaquetage, mais cela peut mener les NM à travailler sur des paquets qui ne les intéressent pas vraiment – plus tard, il y a de forte chance qu'ils deviennent des paquets abandonnés.

Je voudrais suggérer que la formation des NM puisse ou doive se dérouler au sein d'équipes. Nous avons beaucoup de paquets où les responsables peuvent se faire aider dans leur travail et un grand nombre de NM qui cherchent des tâches à accomplir. Je crois que c'est un champ important où nous pouvons nous améliorer. Nous avons besoin de responsables de paquet sympathiques pour faire ce travail – ils seront responsables du travail accompli et on attendra d'eux un rapport sur les candidats membres correspondants. Je me suis déjà porté volontaire pour mes propres paquets pour cette activité, et j'aimerai que d'autres développeurs Debian fassent de même.

Transparence dans le projet

Nous promettons d'être aussi transparents que possible, mais souvent nous n'y réussissons pas. Parfois, c'est nécessaire (par exemple, quand on discute de mises à jour de sécurité sous embargo), mais la plupart du temps ce n'est pas le cas. Parfois des discussions demeurent privées alors qu'elles ne devraient pas l'être et ce n'est pas bon pour nous. Quelque fois un travail technique est réalisé à l'intérieur de nos différentes équipes et quand ce travail est présenté à un public plus large, il court des accusations de « cabale ».

Malheureusement, il n'y a pas de remède miracle pour améliorer la situation. Je crois qu'un des principaux verrous est l'attitude agressive qui se manifeste souvent dans nos forum de développement, et c'est cela qui doit être réduit en premier. Une fois que nous aurons une atmosphère de discussion plus saine, naturellement, il y aura plus de discussions libres.

Professionnalisme

Critères techniques

Dans notre grand dépôt de logiciels, il y a un très grand nombre de paquets, maintenus par un très grand nombre de responsables. Dans Debian, la grande majorité du travail est très bien fait, mais malheureusement pas tout. Beaucoup a été dit sur le fait que beaucoup de nos développeurs sont bénévoles qu'on ne peut pas forcer à faire ce qu'ils ne veulent pas faire. Cela peut excuser la lenteur du travail de certains sur leurs paquets, mais cela ne doit pas excuser la négligence qui se manifeste de temps en temps lorsque, par exemple, des paquets ne peuvent être construits sur des systèmes propres.

Nous disposons d'un nombre croissant d'outils que les responsables peuvent utiliser pour vérifier la qualité de leurs paquets (linda, lintian et maintenant piuparts). Nous avons construit des outils qui peuvent réduire le risque de briser des dépendances et autres problèmes de construction (sbuild, pbuilder, etc.). Et pourtant, nous avons encore régulièrement des paquets cassés ou de faible qualité versés dans le dépôt.

À mon avis, il y a là deux problèmes. Certains responsables de paquet ne sont pas conscients de l'évolution qui est survenue dans nos outils et nos procédures. Et certains parmi nous ne ressentent pas le besoin d'utiliser ces nouveaux outils et nouvelles méthodes. Ces deux problèmes peuvent être corrigés : plus de documentation sur les méthodes de bonne pratique d'empaquetage et de test pourrait aider, à la fois en décrivant ce qui est disponible et pourquoi c'est bien.

Travailler efficacement ; demander de l'aide

Dans le prolongement du point précédent : un autre volet des tâches du développeur Debian est de travailler efficacement, à la fois sur ses propres paquets et sur le projet considéré comme un ensemble. Cela comprend des choses simples comme de gérer les bogues de ses paquets en temps opportun, mais aussi des choses plus importantes comme penser aux conséquences des modifications sur le calendrier des publications. Travailler efficacement ce n'est pas seulement important pour sa propre satisfaction ; cela a aussi un impact majeur sur le temps qu'il nous faut pour publier les versions et sur le ressenti des utilisateurs de Debian.

À mon avis, un élément clé pour un travail efficace est l'honnêteté. On peut tous manquer de temps pour remplir les tâches que nous avons promis d'accomplir. Après tout, la vraie vie a la fâcheuse habitude d'empiéter sur ce que nous appelons notre temps « libre ». Tant qu'on ne laisse pas les choses prendre trop de retard, on peut faire face et continuer à contribuer. Mais à un certain moment, il faut être honnête avec soi-même et accepter l'idée qu'on ne peut pas continuer à faire le travail sur lequel on s'était engagé. C'est une chose difficile à faire, mais dans une communauté conviviale où tout le monde travaille avec les mêmes objectifs, il ne devrait pas y avoir de honte à demander de l'aide.

De manière plus générale, des procédures existent pour que les développeurs Debian quittent temporairement le projet si la vie réelle les submerge, puis le rejoignent quand leur siutation évolue. Encore une fois, il n'y pas de honte à le faire – nous devrions juste nous réjouir de reconnaître toutes les contributions que les gens ont données au logiciel libre quand ils le pouvaient. Mais, pourtant, beaucoup de gens ne suivent pas cette voie, mais plutôt sont juste « portés disparus ». Cela peut prendre du temps avant que l'on retrouve des responsables Debian qui se sont simplement retirés du projet. J'ai entendu quelques suggestions sur la manière de s'en rendre compte, plus vite et plus facilement, et je souhaite m'en occuper.

Pourquoi voter pour moi ?

Un vaste choix de candidats s'offre à nous cette année, ce qui complique le choix des développeurs. Je crois que je peux faire du bon travail comme chef du projet Debian grâce aux qualités suivantes :

Résumé

J'ai abordé quelques problèmes ici qui, j'espère, ne sont pas inconnus pour la majorité d'entre nous. Je dois aussi reconnaître le fait que le chef du projet n'a pas le pouvoir d'imposer simplement les changements qu'il ou elle juge bons. Le mieux que le chef du projet Debian puisse faire est de nous encourager à nous améliorer, parfois par la discussion et le débat et parfois en montrant l'exemple. Je ne prétends pas être parfait, mais je crois que je peux nous aider à atteindre certains des objectifs sur le plan professionnel et des relations sociales que j'ai listés ici. Ma priorité sera de résoudre d'abord certains des problèmes de relation sociale, parce que ce sont les plus urgents et qu'à mon avis ce sont ceux qui peuvent sans doute causer le plus de tort au projet à long terme.

Merci d'avoir pris le temps de lire mon programme.

Réfutation

Avant tout, je dirai que je crois que cette année nous avons une sélection de bons candidats. La plupart des problèmes que j'ai mis en avant dans mon programme ont aussi été relevés par plusieurs des autres candidats, et un certain nombre des solutions sont partagées. Cela rend encore plus difficile la rédaction de cette réfutation, à moins de dire des choses comme « Jeroen sent mauvais » (*grand sourire*) !

Néanmoins, je vais faire un effort. J'aimerais être chef du projet Debian (bien sûr, sinon, je ne me serais pas présenté !) mais je serais aussi assez heureux de voir toute personne compétente élue. Voici, en plus de détails, mon opinion sur les autres candidats et leur programme :

Andreas Schuldei

Andreas a démontré qu'il était capable de coordonner parfaitement de grands projets – regardez la série de Debconf à laquelle il a œuvré ces dernières années. En ce qui concerne son programme, je pense qu'il vise surtout à rendre Debian plus efficace en privilégiant la mise en place de petites équipes pour remplir les tâches. Dans de nombreux cas, je pense que cela marche bien. Mais ce n'est pas immédiatement évident que ce soit toujours le cas ; spécifiquement, l'équipe du chef du projet de l'an dernier a pu remplir ses missions, mais pas grand-chose n'a été visible pour le reste du projet.

Anthony Towns

Nous connaissons tous bien AJ qui a été gestionnaire de publication, ftpmaster et un gourou du débogage dans sa longue et féconde histoire de développeur Debian. Il a accumulé une expérience qui démontre son implication dans le projet. Cette année, ses objectifs de vitalité, de recrutement et de direction me semblent plutôt justes. Je lui souhaite le succès ; l'année dernière a montré qu'il avait continué à travailler pour ses objectifs bien qu'il n'ait pas été élu et j'admire cela.

Ari Pollak

Je pense qu'Ari se sous-estime lorsqu'il se décrit comme un candidat « à moitié fantaisiste ». J'étais vraiment mort de rire la première fois que j'ai lu son programme, ce qui a provoqué quelques froncements de sourcils au travail... :-)

Bill Allombert

Bill a rejoint la compétition pour le poste de chef du projet Debian. Ses objectifs rejoignent ceux d'autres à un certain degré. Je n'ai pas beaucoup d'expérience de travail avec Bill, mais son travail sur les paquets menu et popcon laisse penser que Bill est quelqu'un de capable. Je m'inquiète qu'il n'ait pas beaucoup d'expérience de travail dans ou avec les équipes au cœur du projet.

Jeroen van Wolffelaar

Jeroen ne participe pas à Debian depuis très longtemps, mais il bénéficie déjà d'une grande influence. Si je ne m'abuse, il a initié la Team Scud, l'équipe de chef de projet Debian qui a soutenu deux candidats l'an dernier et à nouveau deux candidats cette année. Jeroen a aussi œuvré comme membre de l'équipe de ftpmaster, et il m'a personnellement beaucoup aidé en fournissant des ressources à l'équipe CD. J'ai encore quelques réserves mineures à propos de l'équipe de chef du projet Debian, à la fois sur l'idée même et sur sa mise en œuvre, mais, malgré cela, j'aurai plaisir à soutenir Jeroen en tant que chef du projet Debian. Il est compétent et c'est agréable de travailler avec lui, en outre nos objectifs se recoupent en grande partie.

Jonathan (Ted) Walther

Je ne m'excuserai pas de ne pas compter M. Walther parmi les candidats sérieux à l'élection de chef du projet Debian. Nous avons d'année en année une tradition de candidats fantaisistes, mais je ne vois aucun humour dans son programme. Lors des élections de l'an dernier, je l'ai décrit comme un excentrique, et je ne vois rien qui justifie que je change d'avis sur lui.