Programme de Steve McIntyre pour l'élection au poste de responsable du projet Debian, année 2007

Introduction

Je suis développeur Debian depuis octobre 1996. Je le suis devenu, au début, pour maintenir la version Debian de mikmod ; j'étais le développeur amont à ce moment-là et je souhaitais que la version Debian fonctionne aussi correctement. En ce temps-là, le processus du nouveau responsable de paquets était bien plus simple qu'aujourd'hui : j'ai installé Debian, puis, deux jours plus tard, j'ai envoyé un courriel à Bruce Perens avec une clef PGP et je lui ai demandé un compte Debian. Il m'a répondu presque immédiatement avec les données du compte – et j'étais rentré !

Depuis lors, j'ai travaillé sur un certain nombre de paquets, certains importants, d'autre petits. Le travail le plus remarquable que j'ai probablement réalisé pour Debian est avec l'équipe des CD-ROM, à la fois en développant le logiciel debian-cd lui-même et en l'utilisant pour créer les CD officiels (et maintenant les DVD) qui accompagnent chaque publication de Debian. Je me suis impliqué dans ces CD à presque chaque version majeure et chaque mise à jour depuis Hamm.

Je me suis porté candidat à l'élection du responsable du projet Debian l'année dernière, et je suis arrivé deuxième derrière AJ. Peu après l'élection, il m'a contacté et m'a invité à accepter un nouveau rôle de délégué Debian pour « I2C », comme assistant du responsable du projet. J'ai accepté, et depuis je l'aide sur certaines fonctions du responsable du projet Debian – en traitant des lettres, en représentant Debian devant la presse et lors de divers rassemblements pour le logiciel libre et en agissant comme médiateur dans certains débats. Cela m'a donné un bon aperçu du travail du responsable du projet Debian : ce que cela entraîne et combien de temps cela prend.

Buts

La plus grand partie de ce programme vous sera familière, car il est largement basé sur ce que je disais l'année dernière à cette période-ci. La plupart des choses sur lesquelles je souhaite travailler dans Debian n'ont pas changé depuis : ce sont des problèmes bien connus, des questions qui nous touchent depuis longtemps.

Communication à l'intérieur du projet

C'est l'Arlésienne ; les candidats au poste de responsable du projet Debian promettent de travailler à améliorer la communication au sein du projet depuis aussi longtemps que je me souvienne. Il y a plusieurs endroits où la communication a posé des problèmes par le passé. Parfois les efforts du responsable du projet ont aidé à arranger les choses, mais le plus souvent il n'y avait aucune amélioration visible.

Des mises à jour courtes et régulières de l'état d'avancement des diverses équipes du projet peuvent apporter beaucoup d'amélioration. De la même manière, des comptes-rendus réguliers du responsable du projet Debian sont nécessaires pour s'assurer que la communauté Debian est consciente de ce qui se dit et de ce qui est fait en son nom. Même si certains de ces comptes-rendus ne consistent qu'en simples « Désolé, j'étais trop occupé dans la vie réelle et je n'ai pas avancé », un accusé réception montrant que les messages ne restent pas sans réponse est mieux que rien du tout. Je vise à encourager ces mises à jour, et si je suis élu j'enverrai des nouvelles régulières du responsable du projet Debian.

Apprentissage et nouveau responsable de paquets

Actuellement le processus du nouveau responsable de paquets contient des tests détaillés sur les capacités techniques des candidats, et bien sûr c'est quelque chose de bon et d'utile. Malheureusement, nous ne sélectionnons pas sur les compétences sociales ; nous avons besoin de travailler ensemble comme une communauté !

On demande souvent aux nouveaux responsables de paquets de montrer leurs compétences en construisant de nouveaux paquets ou en reprenant un paquet abandonné. C'est utile pour tester les compétences d'empaquetage, mais cela peut conduire à faire travailler les nouveaux responsables de paquets sur des logiciels pour lesquels ils n'ont pas de réel intérêt – pour aller plus loin, il y a de grandes chances que ces paquets soient à nouveau abandonnés.

J'aimerais suggérer qu'une plus grande partie de l'entraînement des nouveaux responsables de paquets devrait plus se réaliser en équipe. Nous avons un grand nombre de paquets pour lesquels les responsables pourraient accepter de l'aide, et un grand nombre de nouveaux responsables de paquets qui recherchent du travail. Je crois que c'est un domaine dans lequel nous pouvons beaucoup nous améliorer. Nous avons besoin de responsables de paquets compréhensifs pour faire ce travail – ils seraient responsables du travail réalisé, puis devraient faire un compte-rendu aux responsables de candidature concernés. Je me suis déjà porté volontaire pour cet effort avec certains de mes paquets, et je souhaiterais encourager d'autres développeurs Debian à faire de même.

Nous avons également besoin de trouver comment traiter plus efficacement les nombreux types différents de contributeurs que nous avons désormais. En plus des responsables de paquets, nous disposons de plus en plus de gens qui travaillent sur d'autres domaines importants comme les traductions. Il y a un certain temps, nous avons eu un bon débat à ce sujet et nous devons régler cette question.

Ouverture au sein du projet

Nous promettons d'être aussi ouverts que possible, mais nous échouons souvent sur ce front. C'est parfois nécessaire (par exemple lors des débats à huis clôt sur les mises à jour de sécurité), mais la plupart du temps ça ne l'est pas. Parfois des débats sont privés alors qu'ils ne devraient pas l'être, et ce n'est pas une bonne chose pour nous. Parfois du travail technique est réalisé au sein de nos diverses équipes et, lorsqu'il est présenté à une audience plus large, il reçoit des accusations d'avoir été fait en secret.

Malheureusement, il n'y a aucune potion magique pour améliorer cette situation. Je crois qu'un des principaux points de blocage est l'agressivité qui est souvent montrée sur nos forums de développement, et il faut couper court à cela d'abord. Une fois que nous disposerons d'une atmosphère de discussion plus sereine, des discussions plus ouvertes arriverons naturellement.

Standards techniques

Dans notre grand dépôt de logiciels, nous avons un très grand nombre de paquets et de responsables. La plupart du travail dans Debian est très bien fait, mais malheureusement pas totalement. Beaucoup de choses ont été dites dans le passé sur nos développeurs qui sont des volontaires et qu'on ne peut pas forcer à travailler sur ce qu'ils ne veulent pas faire. Cela peut excuser les gens qui travaillent peu sur leurs paquets, mais cela n'excuse pas une partie du manque de soin qui arrive de temps en temps, par exemple les paquets qui ne se construisent pas sur un système propre.

Nous avons un nombre grandissant d'outils que les responsables de paquets peuvent utiliser pour vérifier la qualité de leurs paquets (linda, lintian et désormais piuparts). Nous avons construits des outils qui peuvent réduire les risques de dépendances cassées et d'autres problèmes lors de la construction (sbuild, pbuilder, etc.). Cependant nous avons toujours des paquets cassés ou de faible qualité qui sont téléchargés régulièrement.

Je peux voir deux problèmes ici. Certains de nos responsables de paquets ne sont pas au courant des mises à jours qui ont été faites sur nos outils et nos procédures. Certains d'entre nous ne ressentent pas la nécessité d'utiliser ces nouveaux outils et méthodes. Chacun de ces problèmes devrait pouvoir être résolu : il faudrait plus de documentation sur les meilleures pratique d'empaquetage et les méthodes de test, à la fois en décrivant ce qui est disponible et quel en est l'intérêt.

Travailler efficacement ; demander de l'aide

En poursuivant sur le point précédent : une autre partie du travail de développeur Debian est de travailler efficacement, à la fois sur ses propres paquets et au sein du projet dans son ensemble. Cela comprend des choses simples comme la gestion des bogues de ses paquets de manière ponctuelle, mais aussi des choses plus complexes, comme la prise en compte de l'impact de modifications sur le calendrier des publications. Travailler efficacement n'est pas important seulement pour sa propre satisfaction ; cela a aussi un impact majeur sur le temps qu'il nous faut pour publier les versions et le ressenti des utilisateurs de Debian.

À mon avis, la clef du travail efficace est l'honnêteté. Nous pouvons tous manquer de temps pour faire le travail que nous avions promis. Après tout, la vie réelle a la fâcheuse habitude de s'introduire dans notre temps « perdu ». Tant que nous ne laissons pas les choses prendre trop de délai, nous pouvons tenir le coup et continuer à contribuer. Mais à un moment, nous avons besoin d'être plus honnêtes avec nous-mêmes et admettre vraiment que nous ne pouvons plus continuer à faire le travail promis. C'est difficile à faire, mais dans une communauté conviviale où nous travaillons tous ensemble pour un but commun, il ne devrait y avoir aucune 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 accapare, puis le joignent à nouveau lors leur situation change. Encore une fois, il n'y a aucune honte à faire cela – nous devrions nous réjouir de reconnaître toutes les contributions des gens qui ont contribué au logiciel libre lorsqu'ils le pouvaient. Mais, il y a toujours beaucoup de gens qui ne prennent pas ce chemin et au lieu de cela disparaissent simplement. Retrouver les développeurs Debian qui ont simplement laissé tomber le projet peut prendre un certain temps.

Pourquoi voter pour moi ?

Nous avons un grand nombre de candidats cette année, ce qui peut rendre le choix difficile pour nos développeurs. Je crois que je peux réaliser du bon travail en tant que responsable du projet Debian grâce aux qualités suivantes :

Résumé

J'ai abordé ici certains problèmes qui ne sont heureusement pas surprenants pour la plus grande partie de notre communauté. Je dois reconnaître également le fait que le responsable du projet Debian n'a pas le pouvoir d'imposer facilement les changements comme il les voit. Le mieux qu'il puisse faire est de nous encourager à nous améliorer, parfois par des discussions et des débats et parfois en donnant l'exemple. Je ne prétends pas être parfait, mais je crois que je peux nous aider à atteindre certains des buts que j'ai listés ici.

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

Réfutation

Tout d'abord, je voudrais dire que cette année (encore) je crois que nous avons une sélection de bons candidats. C'est l'un des aspects de l'élection du responsable du projet Debian que j'aime le moins, car je ne crois pas avoir d'opinion négative sur les autres candidats. Néanmoins, je dois faire un effort. J'aimerais être responsable du projet Debian (évidemment, sinon je n'aurais pas été candidat !) mais je serai aussi heureux de voir toute personne compétente élue. Beaucoup d'idées se recoupent à ce que je peux voir. Voici ce que je pense des autres candidats et de leurs programmes :

Wouter Verhelst

Wouter est un développeur Debian connu et expérimenté que je considère comme un ami. Nous nous sommes rencontrés de nombreuses fois, en particulier lors de conférences Debian et de FOSDEM. Il dit vouloir améliorer le noyau social de Debian, je suis d'accord avec cela et je lui souhaite beaucoup de chance sur ce point.

Aigars Mahinovs

Aigars est un candidat peu connu, sans point précis lié à Debian qui me vienne à l'esprit. Je dois reconnaître que son idée sur les publications, un tronc de distribution et le processus des anciens responsables ne me disent rien. Sur la réforme des fichiers de configuration, je pense qu'il a des idées intéressantes, mais je ne vois pas cela comme relevant du travail du responsable du projet Debian du tout. Pour que ce soit noté, je suis totalement d'accord avec lui au sujet des marques déposées. Toute l'idée qui est derrière les marques déposées est un gâchis !

Gustavo Franco

Gustavo a listé dans son programme une quantité colossale de buts, couvrant le moindre domaine de Debian que je connaisse : les publications, les équipes principales, le système de gestion des bogues, le processus du nouveau responsable, de nouveaux processus et bien plus encore. Je lui souhaite bonne chance pour tout ce qu'il pourra réaliser dans cette grande liste ; je pense qu'il en aura besoin.

Sven Luther

Je ne vois aucun programme.

Sam Hocevar

J'ai été impressionné l'année dernière par les tentatives de Sam pour faire de humour sur les problèmes de Debian, aussi je ne m'attends pas à grand chose de plus cette fois. Cependant, son programme contient beaucoup d'idées positives sur la manière d'améliorer les choses et j'espère qu'il pourra en délivrer quelques unes.

Raphaël Hertzog

Raphaël contribue à Debian depuis un certain temps, il est sans doute connu surtout pour avoir beaucoup travaillé à Alioth. Nous avons travaillé ensemble dans le passé, et les buts qu'il suggère semblent très raisonnables. Il appuie principalement pour un bureau du responsable du projet Debian, une idée qui ne me convient pas à 100 %. Malgré cela, je lui ai proposé de faire partie de ce bureau au cas où il serait élu – après tout, le travail de responsable du projet Debian devra être fait et je serai heureux de pouvoir l'aider.

Anthony Towns

AJ et moi avons pas mal travaillé ensemble l'année dernière comme responsable du projet Debian et 2IC. Ça a été très productif, et je le remercie de m'avoir donnée l'opportunité de l'aider. Il parle cette année de technologie, de communauté et de faire avancer les choses, des sujets importants. Je sais qu'AJ peut beaucoup apporter comme responsable du projet Debian et je lui souhaite encore beaucoup de chance dans la compétition cette année.

Simon Richter

Je ne suis pas sûr de bien comprendre les idées de Simon. Il liste des problèmes dans son programme, mais je ne vois aucune proposition pour les résoudre.