un beau morceau... --
#use wml::debian::template title="Programme de Branden Robinson" BARETITLE="true" #use wml::debian::translation-check translation="1.5" maintainer="Nicolas Bertolissio" <h2>Introduction et biographie</h2> <p> Bonjour chers développeurs Debian, </p> <p> 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. </p> <p> 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. </p> <P> Certaines parties de ce programme pourrons 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ée de façon qui me satisfasse totalement. </p> <p> Je noterais également qu'il y a quelques actions particulières dans ce documents 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. </p> <p> À 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). </p> <p> 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. </p> <h2>Problèmes principaux</h2> <p> Voici une liste des points qui seront en haut de ma liste des priorités. </p> <h3>I. LES DÉLÉGUÉS DU RESPONSABLE DU PROJET DEBIAN</h3> <p> 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 excellant mécanisme qui a toujours été sous-utilisé. </p> <p> 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 telles 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. </p> <p> 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. </p> <p> C'est là, je pense, que le responsable du projet Debian doit agir ; en effet, je considère que cela est sans doute <em>le</em> 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. </p> <p> 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. <p> 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. </p> <p> 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 par une décision particulière. 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. </p> <p> Enfin, je crois que les délégués actuels, secrétaire du projet, responsable du 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. </p> <p> 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. </p> <h3>II. CONSERVER LA BASE DES DÉVELOPPEURS ACTIVE</h3> <p> Tout habitué du canal IRC <code>#debian-devel</code> 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 <em>présence</em> 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. </p> <p> 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 <code>Q</code>, 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 <i>statu quo</i>. Ne pas même être au courant des questions en cours de discussion n'est pas la même chose que de préférer qu'une résolution générale ne soit pas votée. Veuillez vous reporter à notre <a href="http://www.debian.org/devel/constitution";>\ constitution</a> pour de plus amples détails sur ce problème. </p> <p> 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 paresseux pour prendre les décisions appropriées afin de reconnaître ce statut. </p> <p> 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 <a href="http://bugs.debian.org/wnpp";>paquets en souffrance et paquets souhaités</a>. Il existe déjà des outils pour gérer l'identification de responsables de paquets oisifs, mais je suis moins sûr de l'efficacité de leur résultat. </p> <p> 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 besoins 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. </p> <h3>III. REPRÉSENTATION DE DEBIAN LORS DE CÉRÉMONIES</h3> <p> 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. </p> <p> 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'<i>Annual Linux Showcase</i>. </p> <p> 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). </p> <p> 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'<i>Annual Linux Showcase</i> 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'argents sur les stands ne doivent pas non plus être ignoré 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. </p> <p> 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. </p> <h3>IV. RELATIONS DE DEBIAN AVEC SPI</h3> <p> 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. </p> <p> 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. </p> <p> 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. </p> <p> Je suis prêt à démission 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 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. </p> <h3>V. RÉACTIVATION DU COMITÉ TECHNIQUE DE DEBIAN</h3> <p> Je comité technique semble s'être enlisé. Les problèmes qui lui ont été soumis n'ont pas trouvé de solutions (voici <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107150&repeatmerged=yes";>\ un exemple</a>, en voici <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517&repeatmerged=yes";>\ un autre</a>). </p> <p> 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 le 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. </p> <h3>VI. PÉRIODICITÉ DES PUBLICATIONS</h3> <p> 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 kilooctets 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. </p> <p> Je ne couperai pas (et que 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és de substantiels progrès j'aurais peut-être proposé autre chose, mais nous en avons fait. Quiconque ne le pense pas devrait revoir les <a href="http://master.debian.org/~wakkerma/bugs/";>\ faits</a>. </p> <h2>Problèmes moins importants</h2> <p> 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. </p> <h3>VII. NOMINATION D'UNE ÉQUIPE DEBIAN SUR LES QUESTIONS LÉGALES</h3> <p> 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. </p> <h3>VIII. RÉVISION DES RÈGLES D'UTILISATION DES MACHINES DEBIAN</h3> <p> Lorsque j'ai lu pour la première fois les <a href="http://www.debian.org/devel/dmup";>règles d'utilisation des machines Debian</a>, 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ères trop ainsi et elle sont trop floues à certains endroits. </p> <h3>IX. PLACE DU PROJET DEBIAN SUR UNE SCÈNE POLITIQUE PLUS LARGE</h3> <p> 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. </p> <p> 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) apparaît de plus en plus fréquemment sur les médias internationaux. </p> <p> 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. </p> <p> 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). </p> <h3>X. SUPPRESSION DES LOGICIELS NON LIBRES POUR LES FONCTIONS DU PROJET OFFICIEL</h3> <p> Une rapide relecture de notre <a href="http://www.debian.org/social_contract";>\ contrat social</a> 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 <code>qmail</code> sur les machines qui hébergent nos listes de diffusion. </p> <p> 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 pas omission. </p> <p> 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. </p> <p> 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 <code>Received:</code>. </p> <h2>Conclusion</h2> <p> 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. </p> <hr /> <h2>Réfutation (14 mars 2002)</h2> <p> 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 <code>debian-vote</code>. </p> <p> Ni Raphaël ni Bdale n'ont été malavisés de se présenter à l'élection du responsable du projet Debian. Tous deux ont clairement identifiés 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. </p> <p> 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. </p> <p> 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 <code>#debian-devel</code> 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. <code>:-)</code> </p> <p> 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 <code>debian-legal</code>, 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. </p> <p> 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 <a href="$(HOME)/vote/2002/platforms/bdale">programme</a>, 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. » </p> <p> Je ne peut 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 <em>réfléchir</em> à 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 : </p> <p> Prenez la <em>qualité</em> par exemple. Bdale semble reconnaître que des outils comme <code>debhelper</code>, <code>lintian</code> et des ressources comme les <a href="http://buildd.debian.org/stats/";>statistiques et les graphiques des démons de construction</a> 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 <a href="http://master.debian.org/~wakkerma/bugs/";>\ graphique des bogues critiques pour la publication de la prochaine version</a> illustre aussi ce point. Voila, je pense que les bases de Debian sont bonnes et que nous n'avons besoin que d'une évolution, par d'une révolution. </p> <p> 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 sais 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 <code>debconf</code>, qui est une innovation relativement récente, peut difficilement être exagérer. Ses sorties modulaires (LDAP, fichier texte) et ces 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. </p> <p> 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 <em>particulière</em>. </p> <p> 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à. <code>:-)</code> </p> <p> Notre lenteur à sortir de nouvelles versions est certainement un problème, mais chaque développeur en est terriblement conscient. Nous sommes <em>déjà</em> tous motivés pour corriger ce problème, quoi qu'il advienne. Je ne pense pas que nous devions être si obsédés par cela au point de nous cacher d'autre 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. </p> <p> 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. </p>
Attachment:
signature.asc
Description: Digital signature