Programme de Branden Robinson
Introduction et biographie
Bonjour chers développeurs Debian,
Le but de ce message est de souligner les raisons pour lesquelles je me présente à l'élection du responsable du projet Debian et de présenter une idée des choses particulières que je souhaiterais accomplir pendant mon mandat si je suis élu.
D'abord la brève introduction biographique habituelle. Je m'appelle Branden Robinson, je suis développeur Debian depuis environ janvier 1998. Mon principal travail pour Debian a été comme responsable des paquets d'XFree86, ce que je fais depuis mars 1998. Depuis août dernier, je suis aussi le trésorier de Software in the Public Interest, Inc., l'organisation mère légale de Debian et je gère les comptes du projet Debian. J'ai 27 ans, je travaille comme développeur pour le logiciel libre, je suis marié et sans enfant.
Certaines parties de ce programme pourront sembler familières à ceux d'entre vous qui ont lu mon programme de l'année dernière. Cela parce que certaines questions auxquelles je m'intéressais n'ont pas été abordées de façon qui me satisfasse totalement.
Je noterais également qu'il y a, dans ce documents, quelques actions particulières auxquelles je suis fortement attachées. Le but de ce document est d'identifier les principes qui me guident et mes priorités, pas de tracer un plan que je suivrai avec plein de détails. Comme je pense que diagnostiquer des problèmes sans proposer de solutions a moins d'utilité, je suggérerai des solutions envisageables. J'attends avec impatience que les personnes intéressées avancent et participent aux processus de résolution de ces erreurs. Pour moi, mener un projet signifie écouter et prendre des décisions après s'être informé. Si vous pensez que certaines de mes propositions souffrent d'un manque d'information, je vous invite instamment à me le signaler et à me tenir au courant.
À la différence de certains, je crois fermement que la base constitutionnelle et démocratique de Debian fonctionne correctement. Je ne crois pas qu'elle retarde notre croissance ou notre viabilité en tant que projet logiciel. Au contraire, je pense qu'en partageant l'ensemble de la puissance entre les développeurs plutôt qu'en la rassemblant sur le responsable du projet, la constitution de Debian assure la prospérité à long terme de notre projet. Elle protège l'identité et les buts de notre projet de n'être associés qu'à un seul individu. Dans le projet Debian, vous ne devriez jamais vous inquiéter de ce qui arriverait si un développeur disparaissait, ou — plus simplement — quittait le projet (que ce soit formellement ou simplement en disparaissant sans laisser de traces).
Cela dit, le rôle du responsable du projet est toujours un rôle important. Le responsable du projet Debian doit avoir une connaissance des défis que le projet doit affronter qui est trop grande pour qu'un seul développeur la surmonte, et il doit essayer d'affecter des ressources pour triompher de ces défis. En même temps, le responsable du projet doit conserver Debian dans un environnement qui encourage l'expérimentation, la résolution originale de problèmes et il doit renforcer et récompenser l'esprit volontaire qui constitue les fondations de notre projet. Debian est une organisation que chacun peut tout simplement quitter s'il ne s'y trouve pas heureux, le responsable du projet doit donc faire plus que simplement gérer des consensus. Le projet Debian n'a pas de membres captifs ; une mauvaise gestion peut amener à perdre des gens, de la vitalité et de la pertinence.
Problèmes principaux
Voici une liste des points qui seront en haut de ma liste des priorités.
I. LES DÉLÉGUÉS DU RESPONSABLE DU PROJET DEBIAN
Le problème central — et prépondérant — qui me vient à l'esprit à propos du rôle du responsable du projet Debian est le processus de délégation de la constitution. Je pense que c'est (potentiellement) un excellent mécanisme qui a toujours été sous-utilisé.
Avant tout, je pense que nous avons besoin de plus de délégués du responsable du projet. Pour la plupart, les développeurs Debian ont très peu de latitude pour faire preuve de leur jugement personnel. C'est, bien souvent, la bonne manière de faire les choses. Comme nous sommes si nombreux, et comme nous avons invariablement une telle diversité d'opinions sur la manière dont une chose particulière (technique ou autre) devrait être faite, cela permet de conserver l'harmonie de Debian. En d'autres termes, nous pouvons nous disputer, mais il existe un périmètre assez clair à l'intérieur duquel un développeur peut agir en étant reconnu par le reste du projet. Ce périmètre est assez bien confiné aux détails de la maintenance des paquets.
Cela dit, les problèmes plus larges d'administration et de coordination sont souvent négligés ; parfois parce que personne ne peut s'en occuper, ou parce que personne n'a de mandat clair pour agir.
C'est là, je pense, que le responsable du projet Debian doit agir ; en effet, je considère que cela est sans doute le devoir principal du responsable du projet Debian. Et, de plus, ne pas agir directement et personnellement sur les problèmes quotidiens, mais déléguer sa responsabilité sur ces problèmes. Il y a bien longtemps que le responsable du projet ne peut plus remplir toutes les tâches administratives lui-même ; au lieu de cela, le responsable du projet Debian doit identifier des personnes de bonne volonté, spécialisées et ayant les connaissances nécessaires dans le projet pour gérer ces tâches.
Je suis sûr que nous n'avons actuellement pas assez de délégués car de nombreuses choses qui auraient besoin d'être faites ne le sont pas, et qui ne peuvent pas être laissées à la discrétion d'un unique développeur.
J'aimerais qu'il y ait une plus grande formalisation du statut de délégué. En première approximation, je crois qu'il devrait y avoir une page sur le site de Debian qui non seulement les énumérerait, mais décrirait aussi leurs responsabilités et indiquerait la date à laquelle ils ont débuté. Les délégués devraient être mandatés pour une année, ou jusqu'au début du mandat du responsable du projet Debian suivant. J'aimerais pouvoir penser que dans de nombreux cas un délégué puisse poursuivre son mandat d'une année malgré la transition du responsable du projet Debian, mais je crois aussi que les délégués doivent tirer leur légitimité du responsable du projet Debian en place car seul cela a un sens. Il ne me semble pas logique qu'un responsable du projet Debian puisse nommer un délégué qui resterait jusqu'à ce qu'il démissionne de lui-même. Tout cela n'est pas formalisé dans la constitution. Ce devrait soit être formalisé dans un document officiel, soit devenir une pratique courante.
De plus, je pense que chaque délégué devrait être tenu à un certain niveau de responsabilité. Les délégués doivent remplir le rôle qui leur a été assigné ou se désister. La constitution indique clairement qu'un délégué peut être démis de ses fonctions par le responsable du projet Debian pour toute raison sauf pour des raisons personnelles. Elle ne dit pas que le responsable du projet Debian ne peut pas renvoyer un délégué qui ne prend aucun décision. Bien sûr, si les développeurs ne sont pas d'accord, ils peuvent utiliser une résolution générale, comme le permet la constitution, pour l'empêcher (voire révoquer le responsable du projet Debian lui-même). En tant que responsable du projet Debian, j'avertirai publiquement les délégués que leur inactivité est source de problèmes avant de leur retirer leur statut.
Enfin, je crois que les postes des délégués actuels, secrétaire du projet, responsable de publication, responsable de la gestion des comptes Debian et administrateurs système Debian, devraient être totalement formalisés par ce processus. Je crois également qu'il devrait être rendu explicite que les délégués ont le pouvoir de sous-déléguer ou de nommer leur remplaçant pour gérer toute tâche qui leur a été déléguée s'ils sont personnellement submergés ou occupés par ailleurs.
Je crois que tous les délégués existant et que la majorité des développeurs Debian ont de très bonnes intentions, mais qu'ils ont parfois du mal à reconnaître qu'ils ne disposent plus de suffisamment de temps pour se consacrer à la tâche pour laquelle ils s'étaient portés volontaires. Mettre en place des chartes et des mécanismes pour corriger cette carence (de façon à minimiser les tensions et les conflits entre les développeurs) est ma principale priorité en tant que responsable du projet Debian.
II. CONSERVER LA BASE DES DÉVELOPPEURS ACTIVE
Tout habitué du canal IRC #debian-devel depuis quelques années
sait que je me suis souvent plaint de la nécessité de vérifier l'appartenance à
Debian ; c'est-à-dire que nous avons besoin d'identifier les développeurs
qui sont inscrits mais qui ne contribuent plus réellement. Cela est important
car le centre de notre travail (nos paquets) peut se retrouver dans les mains
de personnes qui n'ont plus de temps pour leurs responsabilités au sein de
Debian et donc avec des parties de notre distribution qui ne sont pas
efficacement maintenues. Cela est pire que de ne pas avoir empaqueté certains
logiciels importants (pensez au cas théorique où nous n'aurions pas de paquet
« bind ») car en annonçant la présence d'un paquet, nous
indiquons implicitement à nos utilisateurs que nous le tenons à jour. Cela
signifie le synchroniser avec la version originelle, corriger ses bogues, se
coordonner avec les autres développeurs pour s'assurer qu'il correspond bien au
reste de la structure des paquets de façon claire et élégante, et communiquer
avec les utilisateurs de ce paquet. Lorsqu'un paquet n'est plus maintenu, rien
de cela n'arrive. Comme nous l'avons vu dans le passé, lorsque des paquets
critiques ne sont plus maintenus, notre processus de publication s'enlise.
Sans oublier le fait que les développeurs inactifs biaisent notre procédure
standard de résolution prévue par la constitution en augmentant
artificiellement la valeur du Q, rendant ainsi plus difficile
l'obtention du quorum et les actions à mener. Cela a pour effet de faussement
amplifier l'influence des personnes qui préfèrent le statu quo. Ne pas
même être au courant des questions en cours de discussion est différent de
préférer qu'une résolution générale ne soit pas votée. Veuillez vous reporter à
notre constitution pour
de plus amples détails concernant ce problème.
Je suis sensible à toutes sortes de raisons qui font qu'un responsable de paquet peut ne pas pouvoir contribuer à la hauteur demandée par le paquet et celle des attentes acceptables des utilisateurs. Cependant, nous devons malgré tout pouvoir identifier les paquets laissés à l'abandon et les développeurs trop paresseux pour prendre les décisions appropriées afin de reconnaître ce statut.
Je propose que nous expérimentions, et appliquions par la suite, des outils automatiques pour suivre l'activité des paquets et des développeurs, et pour agir en fonction. Les développeurs oisifs ne devraient pas obtenir la distinction de « développeur émérite », devraient perdre leur statut de développeur selon la constitution et leurs paquets devraient être placés dans le système des paquets en souffrance et paquets souhaités. Il existe déjà des outils pour gérer l'identification des responsables de paquets oisifs, mais je suis moins sûr de l'efficacité de leur résultat.
Enfin, je pense que cette implantation permettra de mieux faire accepter les mises à jour indépendantes. Déjà actuellement, nous avons de nombreux paquets dans nos archives qui ont besoin d'avoir des responsables, mais qui en fait n'en ont pas. Les responsables peuvent être actifs mais négliger un paquet particulier, ou simplement ne plus participer au projet Debian. Si nous avions des moyens de reconnaître cela, je pense que les bases de notre procédure de mise à jour indépendante pourraient ne pas être modifiées.
III. REPRÉSENTATION DE DEBIAN LORS DE CÉRÉMONIES
Par « cérémonies » j'entends tout rassemblement (c'est-à-dire, mais pas seulement, des événements du « monde réel » comme des manifestations commerciales) auquel il serait bien que Debian soit officiellement présent.
Il s'agit d'un domaine dans lequel nous avons fait quelques progrès depuis l'année dernière ; cependant, le problème s'est à nouveau posé lors du LinuxWorld de New York et de l'Annual Linux Showcase.
Aussi, à moins qu'il n'y ait une forte opposition, l'une des premières choses que j'aimerais faire si je suis élu responsable du projet Debian serait de déléguer, en fonction des régions, des coordinateurs Debian pour les événements. Ces personnes seraient responsables du suivi des manifestations commerciales, des principaux événements des groupes d'utilisateurs Linux, etc. auxquels Debian devrait être présent. Pour chaque événement, ils géreraient les contacts avec l'entité coordinatrice directement ou les délégueraient à une personne (qui y assisterait de préférence).
Un des rôles que les coordinateurs pour les événements pourrait remplir serait de gérer les plaintes concernant les contrôles des exposants. USENIX était assez strict et plutôt exorbitant dans sa façon de traiter les stands d'organisations à but non lucratif lors de l'Annual Linux Showcase l'année dernière. Bien que nous ayons tenu notre stand de façon exemplaire, les efforts des responsables et des parrains de l'exposition pour restreindre l'accès aux groupes non lucratifs (en particulier par des méthodes insidieuses comme l'interdiction d'équipement « externes » et en faisant payer 130 dollars pour une simple table) a très fortement étouffé la capacité de Debian à se rendre visible aux nouveaux utilisateurs. Les dons d'argent sur les stands ne doivent pas non plus être ignorés comparés aux revenus de Debian. Debian est entièrement financé par les dons ; si les manifestations ne nous permettent pas de nous montrer, elles nous étranglent financièrement.
En tant que responsable du projet Debian, je souhaite participer à des conférences et des manifestations, faire des présentations et des exposés et, de manière générale représenter le projet. J'ai l'habitude de parler en public et j'aime cela quelque soit la taille de l'auditoire.
IV. RELATIONS DE DEBIAN AVEC SPI
C'est un autre problème où des progrès substantiels ont été accomplis depuis l'année dernière. Cependant, ces progrès sont, à mon avis, insuffisants. SPI est bien mieux définie que l'année dernière, mais il y a toujours beaucoup à faire.
En tant que responsable du projet Debian, j'ai l'intention de recruter des volontaires pour le compte de SPI et d'essayer de faire grossir cette organisation.
En tant que trésorier de SPI je suis conscient qu'il existe un risque de conflit d'intérêt si je suis aussi élu responsable du projet Debian. Je ferai ce qui sera nécessaire pour m'assurer qu'une telle vision soit infondée et réfutable. Je pense que la nomination d'un vice-trésorier qui recevrait également tous les courriels envoyés au trésorier de SPI et à qui j'enverrais une copie de toute ma correspondance en tant que trésorier de SPI (comme je le fais actuellement pour tout le bureau de SPI) permettrait d'y arriver.
Je suis prêt à démissionner d'une de ces deux charges si, de consensus général, il m'est totalement impossible de fonctionner avec ces deux rôles sans mettre en danger l'une ou l'autre des organisations. Cela dit, je suis sûr que ce problème peut être résolu par la transparence et la visibilité. J'ai l'intention de démissionner du poste de trésorier de SPI dès que les procédures en place permettront aux futurs trésoriers de faire leur travail efficacement, plutôt que d'hériter des difficultés de précédents trésoriers qui auraient négligé leur travail.
V. RÉACTIVATION DU COMITÉ TECHNIQUE DE DEBIAN
Le comité technique semble s'être enlisé. Les problèmes qui lui ont été soumis n'ont pas trouvé de solutions (voici un exemple, en voici un autre).
Il s'agit d'un problème sérieux car la constitution de Debian donne beaucoup d'autorité au comité technique. Ce corps doit être actif et doit fonctionner. En tant que responsable du projet Debian, j'exercerai toute la puissance possible pour m'assurer que le comité technique est capable d'exécuter ses tâches de façon à la fois opportune et cohérente avec notre constitution.
VI. PÉRIODICITÉ DES PUBLICATIONS
Il s'agit d'une question quasiment inévitable. Que pouvons-nous faire pour que les versions de Debian GNU/Linux soient publiées plus fréquemment ? Des centaines de kilo-octets d'analyses et de réflexions de ronds de cuir ont été postées sur la question dans nos diverses listes de diffusion. Je serai franc, je ne sais pas si j'ai une solution définitive. Modifier notre charte sur les éditions partielles de la distribution stable pour y inclure plus que de simples corrections de sécurité et des corrections de paquets complètement cassés semble être une partie d'une solution plus large. En tant que responsable du projet Debian, j'aimerais inviter les responsables de publication passés et actuel, et les autres parties intéressées, à aider à structurer une nouvelle approche de la gestion des publications.
Je ne couperai pas (et je ne veux pas couper) l'herbe sous le pied du responsable de publication actuel. Oui, cela fait un certain temps que Woody est gelée. Cela dit, il serait, à mon avis, inconscient de bloquer le processus maintenant, quelque soit le nombre de personnes qui en sont frustrées. Anthony Towns, le responsable de publication actuel, a besoin de notre soutien. Je suis très intéressé d'entendre les propositions sur ce que nous pouvons faire après Woody pour rendre le processus de publication moins sensible aux frictions, mais pour le moment la meilleure des choses que nous pouvons faire est de tester des installations de Woody, des mises à jour à partir de Potato et de rechercher et corriger les bogues critiques pour la publication d'une nouvelle version. Si nous n'avions pas réalisé de substantiels progrès j'aurais peut-être proposé autre chose, mais nous en avons fait. Quiconque ne le pense pas devrait revoir les faits.
Problèmes moins importants
Je considère que les questions suivantes sont secondaires par rapport aux précédentes. Quoi qu'il en soit, ce sont mes idées et je saisis l'opportunité de les énumérer.
VII. NOMINATION D'UNE ÉQUIPE DEBIAN SUR LES QUESTIONS LÉGALES
De la même façon que Debian dispose d'un comité technique, je souhaiterais voir un corps formé de personnes qui réfléchisse sur les questions légales et qui aurait le pouvoir de rendre des décisions officielles au regard de l'interprétation et de l'application des principes du logiciel libre selon Debian. De même qu'avec le comité technique bien sûr, leurs décisions pourraient être outrepassées par une résolution générale des développeurs. Le but est d'obtenir une structure formelle pour gérer des problèmes qui ne nécessitent pas de résolution générale en eux-mêmes. Les résolutions générales sont un processus très lourd et lorsque des décision de cette nature doivent être prises, il est bon d'avoir un mécanisme pour le faire.
VIII. RÉVISION DES RÈGLES D'UTILISATION DES MACHINES DEBIAN
Lorsque j'ai lu pour la première fois les règles d'utilisation des machines Debian, j'ai pensé qu'elles correspondaient peu à Debian. On m'a dit que de nombreux termes avaient été pris tels quels d'une charte d'utilisation d'un fournisseur de services internet. En tant que responsable du projet Debian, je souhaiterais charger une équipe, dont au moins un représentant des administrateurs système Debian, de la rédaction de nouvelles règles qui reflètent mieux la nature de créateur de contenu des développeurs Debian, et non de simples consommateurs de bande passante et d'autres ressources. Je crois qu'il est possible de contenter les fournisseurs de bande passante et de matériel de notre projet sans considérer nos développeurs comme des vandales. À mon avis, les règles actuelles les considèrent trop ainsi et elles sont trop floues à certains endroits.
IX. PLACE DU PROJET DEBIAN SUR UNE SCÈNE POLITIQUE PLUS LARGE
Debian est un projet hétérogène ; en tant que tel il rassemble un large spectre d'opinions politiques et philosophiques parmi ses membres.
Cependant, dans quelques cas, en particulier en regard de la loi sur la propriété intellectuelle, on peut s'attendre à un consensus général parmi les développeurs Debian. La notoriété de Debian croît, à la fois dans la communauté Linux (car nous survivons et nous prospérons même si d'autres distributions perdent de l'importance ou disparaissent totalement), et en dehors, car les phénomènes Linux, GNU et le logiciel libre (ou à source ouvert) apparaissent de plus en plus fréquemment sur les médias internationaux.
Je pense qu'il serait dommage que Debian ne fasse pas un effort pour prêter un coup de main, qu'il soit grand ou petit, à des questions politiques particulières pour lesquelles il est important de le faire. Par exemple, j'imagine que les développeurs Debian seraient assez unis pour l'abrogation du contrôle des exportations sur le chiffrement aux États-Unis, et pour soutenir et renforcer les récentes initiatives européennes pour l'adoption du logiciel libre au niveau des États comme signe de politique publique.
En tant que responsable du projet Debian, je souhaiterais avancer pour que la voix de Debian soit entendue dans les couloirs des gouvernements lorsque c'est approprié, afin que nos idéaux (et nos moyens pour les atteindre) ne voient pas leur existence compromise par des gouvernements qui leur seraient hostiles (ou, plus sûrement, des gouvernements qui auraient vendu des parties de leur législation à des entreprises bien placées dans les modèles passés de la propriété intellectuelle et de sa distribution).
X. SUPPRESSION DES LOGICIELS NON LIBRES POUR LES FONCTIONS DU PROJET OFFICIEL
Une rapide relecture de notre contrat social nous rappelle que nos priorités sont nos utilisateurs et le
logiciel libre. À mon avis, nous ne remplissons pas très bien cela en
conservant le programme non conforme aux principes du logiciel libre selon
Debian qmail sur les machines qui hébergent nos listes de
diffusion.
Nos listes de diffusion sont le centre vital de notre projet, et je pense qu'il est dommage que nous puissions ne pas utiliser des agents de transport du courriel excellents (et libre au sens des principes du logiciel libre selon Debian) simplement par omission.
Pendant mon mandat de responsable du projet Debian, j'aimerais faire tout ce qui est possible pour mener une transition des infrastructures officielles du projet hors de l'utilisation de logiciels non libres au sens des principes du logiciel libre selon Debian. Voici une question que j'entends de temps en temps dans le monde des affaires : « Est-ce que nous mangeons la nourriture de notre chien » (signifiant, bien sûr, est-ce que nous avons suffisamment confiance en nous pour prétendre que nos outils sont suffisants pour le reste du monde ?) je pense que la réponse est : oui, nous pouvons, mais parfois non. Pas parce que nous doutons de la qualité des logiciels libres auxquels nous dédions notre travail, mais parce qu'à un moment dans le passé, la meilleures façon que nous avions de répondre aux besoins de nos utilisateurs fut de placer notre confiance dans des outils non libres. Pour nos serveurs de listes de diffusion, je crois que ce temps est révolu. Faire la transition de nos serveurs de listes n'est pas une mince affaire et le faire sans perturber notre processus de développement est un travail considérable. En tant que responsable du projet Debian, je souhaiterais recruter des volontaires pour gérer cette tâche et préparer un calendrier pour effectuer cette transition.
En tant que développeur Debian, je suis fier du travail que nous accomplissons,
et je ne vois aucune raison de ne pas acclamer les vertus du logiciel libre (y
compris ses qualités) non seulement sur notre toit, mais aussi dans nos
en-têtes Received:.
Conclusion
Je vous remercie de votre attention et j'espère que ce message n'a pas été trop long. Je vous remercie des commentaires sur mon programme et je vous encourage fortement à voter lors des prochaines élections.
Réfutation (14 mars 2002)
Suite à l'invitation du secrétaire du projet, je saisis cette occasion pour
faire quelques déclarations après avoir lu les programmes de mes opposants et
avoir suivi divers sujets de discussion sur la liste de diffusion
debian-vote.
Ni Raphaël ni Bdale n'ont été malavisés de se présenter à l'élection au poste de responsable du projet Debian. Tous deux ont clairement identifié les défis qu'affronte notre projet, et tous deux ont beaucoup de mérite. Je pense honnêtement que nous avons un choix difficile cette année, ce qui n'a pas toujours été le cas par le passé. Je peux facilement imaginer qu'un développeur Debian soit tiraillé entre les trois candidats ; je pense que nous avons tous quelque chose à offrir, et je doute qu'aucun d'entre nous ne fasse vraiment de mal au projet s'il est élu.
Cependant, ne pas faire de mal n'est pas la même chose que d'être le meilleur des candidats potentiels. Le meilleur des candidats fera avancer Debian sans sacrifier l'identité du projet et sans aliéner les développeurs ou la communauté. Le meilleur des candidats ne sera pas nécessairement le plus populaire ou le plus accompli techniquement, mais le candidat qui a la meilleure connaissance de ce qui est nécessaire pour mener efficacement le projet Debian. Il s'agit d'une distinction importante. J'ai de l'admiration pour l'étendue des idées de Raphaël du point de vue technique, et j'ai du respect pour la vision de Bdale ainsi que ses réussites innombrables.
Bien que je pense que Raphaël est un bon candidat, je pense que sa faiblesse
est de ne pas être aussi bien intégré que moi dans le tissus social de Debian.
Je communique quotidiennement avec le responsable actuel du projet et beaucoup
des délégués actuels. Je suis connu des personnes avec lesquelles je devrai
traiter tous les jours. j'ai aussi pris part à de nombreuses facettes techniques
et sociales du projet Debian. Je suis membre du bureau directeur de SPI ;
je suis très bien connu sur le canal IRC #debian-devel où se
tiennent la plupart des discussions et se prennent les décisions (à la fois à
court et long terme). J'ai assisté à quatre conférences, j'ai tenu le stand
Debian à chaque fois, j'ai rencontré beaucoup des développeurs importants et
familiers, j'ai travaillé avec plusieurs, et j'ai même partagé mes chambres
d'hôtel avec d'autres développeurs Debian, et nous avons tous partagé une
expérience intense. :-)
Du point de vue technique, j'ai participé intensément aux discussions des
processus internes de Debian, je me suis attaqué aux questions épineuses comme
la débâcle des bibliothèques SDL et d'extensions statiques d'X, j'ai négocié des
modifications de licences avec des auteurs originels, et je participe
régulièrement sur debian-legal, où nos principes pour le logiciel
libre et même notre contrat social rencontrent de nouveaux défis régulièrement.
J'ai une bonne idée de ce que nous sommes et d'où nous allons. En bref, je pense
que je suis plus impliqué et plus familier avec notre projet et les personnes
qui le font que ne l'est Raphaël.
J'ai eu le privilège de rencontrer Bdale l'automne dernier au Colorado. À ce moment, il m'a expliqué que Debian avait plus besoin de « révolution » que d'« évolution ». C'est un point qu'il réitère dans son programme, où il dit : « Malheureusement, je pense que cela fait longtemps que Debian n'a pas eu de vision clairement définie. Il est temps de corriger cela. »
Je ne peux pas être d'accord avec cette sensation. Je pense qu'une révolution n'est nécessaire que lorsque les choses sont tellement cassées que la violence (qu'elle soit littérale ou métaphorique) devient nécessaire pour effectuer des changements. Je ne pense pas que Debian en soit arrivé à ce point. Je pense que, plus que de projeter une vision sur le projet, le responsable a besoin de réfléchir à ce qu'est le projet. Et, en ce qui concerne les aspects particuliers de la vision qui laisse penser à Bdale que Debian a besoin d'une action corrective, je pense que nous nous débrouillons assez bien dans l'ensemble :
Prenez la qualité par exemple. Bdale semble reconnaître que des outils
comme debhelper, lintian et des ressources comme les
statistiques et les graphiques des
démons de construction montrent que Debian ne fait pas de promesses en
l'air sur l'amélioration de la qualité du code de notre distribution. Je pense
que la tendance récente du graphique des bogues critiques pour la publication de la prochaine version
illustre aussi ce point. Voila, je pense que les bases de Debian sont bonnes et
que nous n'avons besoin que d'une évolution, pas d'une révolution.
On pourrait en dire autant de la plupart des autres points soulevés par Bdale.
J'ai du mal à rapprocher son discours audacieux de la plupart des questions
qu'il a identifiées comme étant problématiques. Je conviens que toutes les
questions qu'il a citées sont importantes ; je ne vois cependant pas où
Debian ne s'améliore pas déjà, ou bien où tout le monde ne sait pas que nous
devons nous améliorer et où chaque candidat n'a pas déjà fait de promesse
(comme la périodicité des publications). Il a mentionné l'ergonomie ; j'ai
essayé de rendre l'utilisation de XFree86 plus simple depuis que je m'occupe de
ce paquet, et j'ai reçu ne nombreuses éloges pour mes efforts. Peu de personnes
ont autant modifié leurs paquets et affecté le système. L'importance de
debconf, qui est une innovation relativement récente, peut
difficilement être exagérée. Ses sorties modulaires (LDAP, fichier texte) et
ses frontaux (readline, dialog, Gnome) nous fournissent exactement la puissance
que nous pourrions souhaiter pour rendre Debian aussi convivial que n'importe
quel autre système d'exploitation, si ce n'est plus. Ces fonctionnalités
passionnantes attirent l'intérêt des gens et de la main d'œuvre, petit à
petit, l'ergonomie de Debian s'améliore.
Je ne crois pas que Debian ait stagné. Seul quelqu'un qui imagine que la publication de Potato soit là tout ce que Debian ait fait pourrait peut-être le penser. Comme je l'ai déclaré dans mon programme ci-dessus, j'imagine Debian avant tout comme un groupe de personnes, un tout doué, intelligent et imaginatif, et sans référence à une personne particulière.
En tant que responsable du projet, je ne souhaite pas subordonner la vision des
autres à la mienne. Certains peuvent considéré cela comme une faiblesse ;
je le considère comme une force. Je crois que le responsable du projet Debian
ne devrait agir que lorsque les qualités de meneur sont requises ; le
reste du temps, il devrait s'assurer de ne pas gêner en restant au milieu du
passage ! J'ai une totale confiance dans le projet Debian pour trouver son
chemin vers l'avenir. Quatre responsables différents du projet ces cinq
dernières années n'ont rien fait pour ébranler cette confiance. Nous nous
sommes montré à nous-mêmes que nous pouvions assez bien prospérer malgré les
changements de responsable et sans un responsable ayant le fort désir de
modifier la vision de Debian. Il est possible que Bruce Perens pense de même,
mais il a quitté le projet et je pense qu'il est évident que nous sommes
toujours là. :-)
Notre lenteur à sortir de nouvelles versions est certainement un problème, mais chaque développeur en est terriblement conscient. Nous sommes déjà tous motivés pour corriger ce problème, quoi qu'il advienne. Je ne pense pas que nous devions en être obsédés au point de nous cacher d'autres choses importantes pour le projet, comme de fournir aux développeurs et aux délégués du responsable du projet la liberté de faire ce qu'ils font de mieux.
C'est pour cela que je pense être le meilleur candidat pour ce poste. Dans l'ensemble, je pense que nous sommes dans le vrai. Lorsque ce n'est pas le cas, nous avons montré que nous avons à la fois l'intelligence d'identifier les problèmes, et la volonté d'agir ; parfois, il ne nous manque que le mécanisme pour exécuter le travail. C'est la raison pour laquelle déléguer est ma première priorité — dans l'ensemble, j'ai confiance en mes collègues développeurs pour faire la Bonne Chose. J'espère avoir également gagné votre confiance.