-- .~. Nicolas Bertolissio /V\ nico.bertol@free.fr // \\ /( )\ ^`~'^ Debian GNU-Linux
#use wml::debian::template title="Programme de Raphaël Hertzog" BARETITLE="true" NOHEADER="true" #include "$(ENGLISHDIR)/vote/style.inc" #use wml::debian::translation-check translation="1.5" maintainer="Nicolas Bertolissio" <h2>Introduction</h2> <p> J'ai 28 ans. Je suis marié et n'ai encore aucun enfant. Je suis un indépendant et je décide seul de comment je passe mon temps. </p> <p> Pour ce qui concerne Debian, j'ai toujours été intéressé par les questions d'organisation et par l'assurance qualité. Pour donner des projets plus précis : j'ai aidé à installer <a href='http://alioth.debian.org'>\ Alioth</a> et je l'administre actuellement. J'ai créé le <a href='http://packages.qa.debian.org'>système de suivi des paquets</a> et le maintiens toujours avec l'aide de quelques autres. Il y a longtemps, j'ai également fait avancé le <a href='http://lists.debian.org/debian-devel/1999/07/msg01530.html'>principe de parrainage</a>. J'ai fait ma part d'empaquetage, de chasse aux bogues, de mises à jour indépendantes, de création des chartes Perl/python, de maintenance de debian-cd et de choses semblables pendant les 8-9 années où je me suis impliqué (1998-2007). </p> <p> Je me suis déjà présenté une fois pour être responsable du projet Debian en 2002. Veuillez regarder <a href='http://www.debian.org/vote/2002/platforms/raphael'>le programme que j'avais écrit à ce moment-là</a>. Regardez combien de mes idées et projets étaient justes et ont été mis en application depuis, et comment j'ai mis en application de manière cohérente plusieurs des projets que j'avais annoncés. </p> <p> Pourquoi concouré-je pour être responsable du projet Debian cette année ? Simplement parce que... </p> <h2>Je veux un conseil de responsables du projet Debian</h2> <p> Je pense avoir une bonne compréhension et une bonne expérience du projet dans son ensemble. Je voudrais employer cette expérience pour servir le projet, mais si je devais seul gérer les devoirs d'un rôle si exigeant, je ne concourrais pas. Je suis sûr de ne pas être le seul dans cette position. Je pense que le temps est terminé de mettre trop d'espoir dans un candidat unique chaque année. </p> <p> Je suis vraiment convaincu que travailler dans un conseil de responsables du projet Debian est la meilleure manière pour moi de servir le projet et de faire des propositions constructives. Je ne suis nullement parfait, et je fais des erreurs, mais je suis habitué à travailler avec d'autres (même lorsqu'ils ne sont pas d'accord avec moi), et le conseil de responsables du projet Debian doit exister pour la raison suivant : j'ai toujours besoin du conseil d'autres membres de confiance pour améliorer toute proposition de sorte qu'elle puisse être largement accepter. Je ne crains pas les antagonismes dans le conseil, parce que je laisserais tomber une idée en voyant que trois membres ne l'aiment pas plutôt que de la proposer largement et de produire encore une autre guerre verbale inutile. </p> <p> Croyez-moi ou pas, je suis convaincu que <a href='http://lists.debian.org/debian-vote/2007/02/msg00153.html'>nous pouvons convenir</a> d'un <a href='http://lists.debian.org/debian-vote/2007/02/msg00156.html'>certain niveau de départ</a> et construire en partant de là. </p> <p> Comment cela pourrait-il fonctionner ? Je l'ai décrit dans un <a href='http://lists.debian.org/debian-project/2007/02/msg00061.html'>récent courriel sur debian-project</a> et j'ai demandé des commentaires en retour. Je projette de déléguer toutes les prérogatives du responsable du projet Debian au conseil avec un ensemble de règles définissant comment le conseil peut prendre des décisions. Ensuite je ne devrais pas être obliger d'employer directement mes prérogatives de responsable du projet Debian (à moins que le conseil n'en ait besoin), et je compte jouer un rôle actif dans le conseil en faisant des propositions chaque fois que nécessaire. </p> <p> Tous les membres du conseil seraient ajoutés à l'alias <a href='mailto:leader@debian.org'>leader@debian.org</a>. En plus de cela, une liste de discussion archivée publiquement et restreinte aux membres du conseil serat installée. Cette liste serait l'outil principal pour le conseil. Chaque fois qu'un membre du conseil sentirait le besoin de prendre une décision officielle, il ferait une proposition qui serait alors débattue sur cette liste. </ br> Après un certain temps, le déposant déciderait que la discussion a assez duré et demanderait un vote. Ce vote durerait une semaine et le quorum serait très faible. Le vote serait souvent une simple question avec comme réponses possibles oui/non/poursuivre la discussion. Mais le déposant pourrait demander un vote selon la méthode de Condorcet si c'était ce qui lui semblerait le plus approprié. </p> <p> Le conseil devrait représenter le projet dans sa diversité à une échelle plus petite. Ceci devrait permettre des <q>discussions par procuration</q> où la discussion resterait courtoise parce que le conseil aurait été choisi avec cet objectif à l'esprit. Les membres du conseil devraient être choisis avec un but de maximiser la capacité de chaque développeur de contacter quelqu'un du conseil de sorte qu'il puisse exprimer son point de vue avec confiance et que quelqu'un le comprendra et représentera son avis. </p> <p> Que ferait le conseil ? Tout ce que les membres du conseil pensent qu'il est nécessaire de faire. Ils auront les prérogatives du responsable du projet Debian et je m'attends à ce qu'ils les emploient avec sagesse pour exercer toute activité bénéfique à Debian. </p> <p> Si possible je voudrais travailler avec le conseil suivant : </p> <ul> <li>Bdale Garbee <<a href='mailto:bdale@debian.org'>bdale@debian.org</a>></li> <li>Steve McIntyre <<a href='mailto:93sam@debian.org'>93sam@debian.org</a>></li> <li>Jeroen van Wolffelaar <<a href='mailto:jeroen@debian.org'>jeroen@debian.org</a>></li> <li>Enrico Zini <<a href='mailto:enrico@debian.org'>enrico@debian.org</a>></li> <li>Josip Rodin <<a href='mailto:joy@debian.org'>joy@debian.org</a>></li> <li>Steve Langasek <<a href='mailto:vorlon@debian.org'>vorlon@debian.org</a>></li> <li>Wouter Verhelst <<a href='mailto:wouter@debian.org'>wouter@debian.org</a>></li> <li>Sam Hocevar <<a href='mailto:sho@debian.org'>sho@debian.org</a>></li> </ul> <p> Les quatre premiers sont inconditionnellement prêts à servir dans un conseil de responsables du projet Debian. Josip soutiendrait plutôt un conseil élu <a href='http://lists.debian.org/debian-project/2007/02/msg00180.html'>comme il le décrivait sur debian-project</a>. Les autres préfèrent réserver leur décision jusqu'à la fin du scrutin. Steve Langasek veut évidemment attendre qu'Etch soit publiée. Wouter et Sam préféreraient probablement être impliqués si le projet décidait qu'avoir un conseil de responsables du projet Debian est une bonne idée. Et ils ne veulent également pas approuver indirectement ma candidature. </p> <p> Ce conseil sera probablement complété avec un développeur de langue allemande et un autre d'Asie ou d'Australie. Je n'ai pas pu pas obtenir les accords demandés à temps pour la publication de ce programme, aussi est-ce le premier exercice pour l'après scrutin. </p> <h2>Mes projets et avis personnels</h2> <p> Naturellement, si je suis élu, la décision finale sur mes projets sera prise par le conseil. Cependant, cela vaut la peine d'indiquer à un peu plus dans quelle direction je voudrais emmener le projet. </p> <h3>Transparence et communication</h3> <p> J'ai lu ma part des discussions enflammées ces dernières années et il devient ennuyeux de voir que nous avons quelques problèmes récurrents qui pourraient être la plupart du temps évités avec un peu plus de courriels venant des responsables qui sont derrière de diverses adresses de fonction. Évidemment ils ont leurs raisons de rester silencieux la plupart du temps et je crois que ceci est directement lié aux (mauvaises) habitudes de communication que nous avons développées au sein du projet. </p> <p> Mon expérience avec Alioth m'a prouvé que donner des nouvelles en public apporte quelques critiques inutiles. Néanmoins, je continue à donner des nouvelles et à gérer beaucoup de choses publiquement parce que je crois que c'est nécessaire pour la santé à long terme de l'équipe. Sans ceci nous ne pourrions pas avoir recruté deux nouveaux volontaires. </p> <p> Alioth est maintenant employé pour maintenir beaucoup de paquets et pour développer une partie importante de notre infrastructure, ainsi ce service est-il important et aussi étroitement observé que d'autre services gérés par l'administration système de Debian. Mais il semble que nous ayons évité la majeure partie de la critique en le gérant. </p> <p> Je veux construire sur cette expérience et écrire un ensemble de <q>directives pour les équipes internes</q> qui serait largement approuvé par le projet, puis, avec le temps, travailler avec les diverses équipes pour les aider à répondre à ces objectifs. </p> <h3>Employer ce que nous empaquetons et empaqueter ce que nous employons</h3> <p> Ce n'est pas vraiment un projet, mais une politique que je voudrais favoriser. Il y a trop de cas où nous employons des choses qui ne sont pas empaquetées dans notre dépôt principal. En général nous avons de bonnes raisons à cela : parce que c'est spécifique à Debian ou que c'est un bidouillage. Voici des exemples qui me viennent à l'esprit le ssh maintenu par l'administration système de Debian, le système de suivi des paquets (oui, je ne l'ai pas empaqueté), la différence entre sbuild sur les buildds et le paquet sbuild, etc. </p> <p> Je pense que nous devrions viser à toujours employer les paquets de <q>l'archive principale de Debian</q> parce que cela nous obligerait à penser un peu plus globalement et à adapter nos outils de sorte qu'ils puissent aussi servir à d'autres. Nous avons beaucoup de distributions dérivés mais elles n'emploient pas toujours la même infrastructure que nous, en partie en raison de cela. Un autre avantage d'avoir des paquets est que cela offre naturellement l'interface du système de gestion des bogues qui peut être employée pour signaler des problèmes, des idées pour des améliorations... et c'est de plus utile pour les volontaires qui veulent dépanner une équipe particulière et qui recherchent quelque chose d'intéressant à faire. </p> <h3>Autoriser les personnes à faire des choses (utiles)</h3> <p> Historiquement, nous avons de nombreux exemples des personnes qui ont fait des choses seules sans aucune approbation du projet ou de l'équipe responsable : Anthony n'était pas responsable ftp lorsqu'il a écrit britney, j'ai poussé pour Alioth parce que je pensais que c'était une bonne idée et l'administration système de Debian n'a jamais approuvé ni bloqué quoi que ce soit, de même pour l'équipe de sécurité de la distribution de test. </p> <p> Si certaines personnes ont la sensation d'être bloquées dans leur travail par un problème courant et sont disposées à aider, je ferai tout ce que je peux pour leur fournir les ressources nécessaires. Alternativement je proposerai des idées novatrices pour contourner les problèmes. Prenons l'exemple du manque de machines d'architecture alpha accessibles aux développeurs Debian pour le portage. Nous pourrions imaginer un service qui permettrait à des tiers d'offrir l'accès à leur propre machine. Le développeur Debian qui a besoin de l'accès à une telle machine la demanderait sur un formulaire internet. Le propriétaire de la machine aurait juste à installer un paquet spécifique qui exporterait trois environnement fermés d'exécution et mettrait à jour automatiquement la liste d'accès (y compris les clefs publiques SSH) toutes les 15 minutes à partir d'un centre de confiance. La machine exporterait également quelques données descriptives (information de contact, mémoire vive, espace disque disponible, type de microprocesseur, etc.) qui pourraient être utilisées par le développeur pour choisir sur quelle machine il est susceptible de pouvoir effectuer son travail. </p> <h3>Soutenir les contributeurs occasionnels</h3> <p> Nous avons l'ambition d'être le système d'exploitation universel et je partage entièrement ce but. Mais pour ceci, nous devons accroître la puissance des nombreux contributeurs occasionnels. Quelques discussions récentes ont prouvé que nous pouvons faire mieux dans ce domaine : nous pourrions fournir une meilleure vue d'ensemble des modifications liées à l'empaquetage aux centaines d'empaqueteurs qui ne passent que quelques heures par mois sur leur (souvent petit) paquet. Annoncer les modifications sur debian-devel-annonce a été proposé et est susceptible d'être fait. Je pense également que l'idée proposée par Anthony Towns l'année dernière devrait être mise en application : après quelques parrainages réussis, nous devrions pouvoir donner l'accès en téléchargement pour un paquet spécifique à son responsable et nous ne devrions pas exiger de lui qu'il passe par le processus du nouveau responsable de paquets s'il ne le veut pas parce qu'il n'est pas plus largement intéressé par projet que ça. Naturellement, nous devons mettre en place quelques contrôles pour éviter toute perte de qualité. </p> <h2>Pourquoi voter pour moi ?</h2> <p> Pourquoi pas ? Il semble que bon nombre de mes projets ont eu des résultats positifs. Essayons en quelques autres ! </p> <h2>Réfutation</h2> <h3>Sur mon propre programme</h3> <p> Je me suis volontairement concentré sur une liste limitée de projets mais il y a beaucoup plus à faire, en particulier au sujet de la communication extérieure à Debian. Je voudrais employer le conseil pour rédiger quelques documents expliquant les rapports entre Debian et les divers acteurs du monde du logiciel libre (voir l'<a href='http://www.debian.org/vote/2002/platforms/raphael#message'>idée originale dans mon programme de 2002</a>). En outre nous avons quelques bons communicants dans le conseil et je suis sûr que ceci mènera à plus de visibilité pour Debian. </p> <h3>Wouter Verhelst</h3> <p> Je suis d'accord avec la majeure partie de ce que Wouter a indiqué. Son plan pour discuter d'abord et décider ensuite est la seule chose raisonnable à faire. Mais cette étape de <q>recueil d'informations</q> est mieux réalisée dans une équipe parce qu'elle fournit une meilleure couverture des divers rapports interpersonnels qui sont en jeu. </p> <p> Si je suis élu, j'espère qu'il confirmera sa participation au conseil de responsables du projet Debian et qu'il poursuivra tous les buts qu'il a décrits dans son programme. </p> <h3>Sam Hocevar</h3> <p> Tous les buts de Sam sont intéressants. Je partage la majeure partie de son analyse de la situation. Cependant, en tant que responsable du projet Debian indépendant je crains qu'il ne soit trop isolé pour agir efficacement avec toutes les équipes internes. </p> <p> Si je suis élu, j'espère qu'il confirmera sa participation au conseil de responsables du projet Debian et qu'il poursuivra tous les buts qu'il a décrits dans son programme. </p> <h3>Steve McIntyre</h3> <p> Le programme de Steve ne donne pas beaucoup de projets concrets mais plutôt une direction globale qu'il veut suivre. J'accueille favorablement toute initiative pour résoudre les problèmes qu'il a décrits. </p> <p> Je suis heureux qu'il ait accepté de faire partie du conseil de responsables du projet Debian. </p> <h3>Anthony Towns</h3> <p> Anthony identifie le besoin de plus <q>aider les responsables</q> pour <q>répartir la charge de travail</q>. Il explique même comment s'impliquer dans des activités de responsable du projet Debian vous aide à être plus efficace en tant que responsable du projet Debian à part entière plus tard. </p> <p> Clairement être responsable du projet Debian vous donne l'accès à plus d'informations que la moyenne des développeurs Debian et ces informations sont cruciales pour faire évoluer Debian sans (trop de) ruptures. Je pense que ces informations doivent être partagées par autant de personnes sages que possible et c'est le but d'un conseil de responsable du projet Debian. </p> <p> J'aime son choix des mots sujets clés mais la plupart des projets décrits n'exigent pas d'être responsable du projet Debian. Je lui fournirai avec plaisir l'appui désiré de sorte qu'il puisse accomplir <a href='http://azure.humbug.org.au/~aj/blog/2006/04/12'>son projet de soutenir les responsables non-développeurs Debian</a>. Avoir des <q>ambassadeurs</q> est une belle idée, mais avec un conseil, nous avons déjà beaucoup de coresponsables du projet Debian qui sont des ambassadeurs de fait du projet. Je suis toujours ouvert à l'idée cependant. </p> <h3>Aigars Mahinovs</h3> <p> Ses grands plans ne deviendront pas réalité simplement parce qu'il a été élu. Le seul projet spécifique à Debian est si ambitieux, qu'il est peu susceptible d'être jamais accompli. Toutefois j'accueillerai certainement avec plaisir de nouveaux outils pour faciliter la collaboration avec des distributions dérivées, mais ça ne se produira pas si un changement important est nécessaire comme il le suggère. </p> <h3>Gustavo Franco</h3> <p> Il y a tant d'idées dans son programme qu'il devrait l'avoir structuré et leur avoir donné des priorités. Le raisonnement qui est derrière ce grand choix de projets et d'idées ne me semble pas clair. </p> <h3>Simon Richter</h3> <p> Simon voit le responsable du projet Debian comme quelqu'un qui doit participer à toutes les discussions importantes avec le but de favoriser une position intermédiaire et raisonnable. C'est une tâche difficile parce que vous favorisez inévitablement votre propre avis. C'est pourquoi je préfère avoir les discussions à une échelle plus petite dans un conseil représentant la diversité de Debian. Le but est identique, mais il est atteint différemment. </p> <p> Son programme n'aborde que le seul problème de la communication interne. Je n'arrive pas à trouver une vue d'ensemble de la direction qu'il veut donner à Debian. </p> <h3>Sven Luther</h3> <p> Son programme n'était pas en ligne quand j'ai écrit cette réfutation. </p>
Attachment:
signature.asc
Description: Digital signature