À mon sujet

Salut ! Je m'appelle Sam, et je suis sérieux.

Pourquoi je suis candidat

Je suis développeur Debian depuis l'an 2000. Avant cela, j'étais un utilisateur heureux depuis environ 1996. Avoir 150 développeurs fortement qualifiés travaillant ensemble sur la plus grande distribution Linux existante était très impressionnant, et j'ai toujours admiré à la fois le projet pour ses buts nobles et la distribution pour son excellence technique. C'était un honneur et un défi de devenir une partie de ce projet et il m'a aidé à devenir meilleur en programmation, en communication, en travail d'équipe et même en anglais.

Au même moment, en 1998, j'ai commencé à apporter mon aide à un petit projet appelé VideoLAN. Dans ce projet j'ai rapidement évolué du petit nouveau timide mais fervent au contributeur doué. Pendant que je recueillais des connaissances sur les bases de programmation et le respect d'autres développeurs, je suis devenu omniprésent et j'ai commencé à contrôler ce que les autres faisaient, en étant leur tuteur ou en prenant des décisions éclairées au niveau du projet. J'ai été naturellement submergé de travail et j'ai dû contrôler mes priorités, écartant les choses les moins pressantes et verrouillant des tâches parce que je ne faisait pas confiance à d'autres pour les accomplir de la manière parfaite que j'avais prévue. Plusieurs contributeurs sont partis frustrés et aujourd'hui je crois qu'en dépit de la qualité et de la popularité de VideoLAN, il aurait été encore meilleur si je n'avais pas empêché ces développeurs de travailler librement.

C'est une histoire personnelle mais elle n'est certainement pas isolée. L'histoire d'autres projets ne doit pas être ignorée : egcs (bien que nous l'appelions maintenant gcc) a outrepassé les contrôles de la FSF et étouffé gcc, X.org a rapidement remplacé XFree86 après que tout le monde en a eu assez du contrôle de l'équipe principale. Et je prévois le même destin pour glibc si Ulrich Drepper reste responsable de tout.

Je crois qu'une chose semblable arrive à Debian. Je vois l'enthousiasme, je vois le conservatisme, je vois les contrôles accablants et je vois la frustration. Je comprends les deux points de vue mais je pense également que la confrontation blesse profondément le projet. Et je suis candidat au poste de responsable du projet Debian principalement parce que j'aime Debian et que je veux le changer avant qu'il ne soit trop tard et que quelque chose d'autre ne se relève des cendres de Debian (et certains disent que cela s'est déjà produit).

Ma vision pour Debian

Debian a peur de changer trop rapidement. Nous avons une histoire faite de bonnes choses, innovatrices et populaires, mais supprimer nos verrues de temps en temps est une bonne idée. Nous ne sommes pas seuls et la simple énonciation Debian sera toujours la meilleure ne rend pas vraie cette assertion.

Grand, dynamique, bon : n'en choisir que deux ?

Je ne le pense pas. Je crois que nous pouvons avoir les trois, à la fois en matière de personnes et de produits. Ce que nous laissons actuellement lentement tomber est le dynamisme, et je veux le retrouver sans impacter les autres facteurs. C'est un défi, c'est presque trop pour une seule personne, et il serait malhonnête de gager que d'autres feront ce que je suggère. Mais même si je ne peux pas vous le faire faire, j'espère bien sûr que je peux vous inciter à vouloir le faire.

Mes buts

Refaire de Debian un projet amusant

Admettons-le, nous sommes devenus un groupe de vielles biques qui s'amusent beaucoup moins qu'avant. J'ai du mal à autant m'amuser à travailler pour Debian quand il y a tant de frustration.

Il y a beaucoup de manières de réduire cette frustration :

Plus d'équipes

Le travail en équipe est bon. Il vous incite à communiquer. Le champ Uploaders: est l'une des meilleures choses qui soit arrivée à l'organisation de Debian. C'est vraiment brillant. Naturellement il permet à plusieurs personnes de travailler sur le même paquet, mais il aide également à réduire la sensation que des paquets sont possédés et il nous incite à créer des équipes.

Je veux encourager la comaintenance en en faisant la norme, pas l'exception, en faisant rejoindre aux candidats nouveaux responsables une équipe existante au lieu d'ajouter de nouveaux paquets à l'archive, en essayant d'avoir au moins une personne de secours pour télécharger un paquet pour chaque paquet de priorité standard, en ayant une politique de détournement allégée (comaintenance obligatoire) des paquets négligés (par exemple pour les vieux bogues restés sans réponse, pour les correctifs non appliqués), y compris pour des candidats nouveaux responsables. Plus de j'ai été occupé par la vie réelle ces six derniers mois mais je vous met au défi de toucher à mon paquet, je promets que je m'occuperai de ses bogues le mois prochain.

De plus grandes équipes

Je crois qu'avoir de plus grandes équipes est une des solutions au problème de latence élevée que certaines de nos équipes principales rencontrent. Je veux pouvoir nommer des assistants supplémentaires et volontaires à celles de nos équipes principales (administration système de Debian, ftp maître, administrateurs des démons de construction, responsable des comptes Debian) qui semblent en avoir besoin. Je sais que certaines d'entre elles en ont déjà, mais depuis si longtemps que vous pouvez vous demander pourquoi ils ne sont toujours qu'assistants.

Après qu'une période raisonnable (disons, 3 mois) je veux que ces assistants soient soit approuvés par l'équipe en tant que membres à part entière soit rejetés avec une justification appropriée (par exemple inactivité, incompétence, problèmes importants de relations humaines).

Dans le meilleur des cas, ces assistants devraient être cooptés. Il y a cependant, pour des raisons historiques, une concentration importante de pouvoir par un nombre très réduit d'individus. J'ai toutes les raisons de croire qu'elle rend une partie du travail plus efficace, mais elle a également des inconvénients :

Tout ceci ajoute à la frustration. Je voudrais, à terme, que ces équipes aient aussi peu que possible de membres communs, et que les membres inactifs (par exemple les administrateurs des démons de construction qui ne font pas fonctionner de démon) soient rétrogradés au statut d'assistant.

Je sais qu'il est difficile de gérer les nouveaux venus. Ils ont besoin de formation et d'aide, et toute formation et toute aide prennent du temps et de l'énergie qui pourraient être employés à faire le travail réel à la place. Mais beaucoup de gens peuvent apprendre simplement en observant, et puisque certains membres actuels des équipes semblent effectivement ne faire qu'observer, il ne devrait y avoir aucun problème à ajouter des volontaires aux équipes.

De petits projets

J'aime les petits projets. Les petits projets sont amusants. Les petits projets prennent moins de temps, et avant que nous ne finissions un grand projet de six mois nous pouvons réaliser une douzaine de projet de deux semaines, et si quelqu'un s'ennuie avec un petit projet, il peut simplement en commencer un autre et ne pas gaspiller six mois de travail.

Une vraie gestion des projets

Nous avons des problèmes pour gérer de grands projets. Nous luttons pour publier les versions parce que la publication est un projet énorme et nous ne savons pas gérer d'énormes projets (ou nous n'appliquons simplement pas ce que nous savons). Nous finissons par réussir, mais je n'appellerais pas exactement ce que nous faisons de la gestion de projet. Étant des volontaires, toutes les règles de gestion de projet ne s'appliquent pas, mais il serait idiot de toutes les ignorer.

Une capacité appropriée à rendre compte fait partie de ces règles. Non seulement cela aide le projet en cours en rendant la communication meilleure, mais cela aide également de futurs projets à apprendre de notre calendrier, des dates limites manquées et des raisons de ces manques. Malheureusement, je ne sais pas comment obtenir des comptes-rendus appropriés sans les rendre obligatoires pour pouvoir garder sa fonction. J'ai vu beaucoup de gens jouer le mort puis ne réagir soudainement qu'à un blâme public. Mais je suis disposé à considérer des solutions de rechange plus constructives.

Les comptes-rendus ne sont pas seulement une exigence ennuyante du processus, ils sont également valorisants et utiles. D'autres projets tels qu'OpenSolaris en ont ressenti le besoin et le font déjà.

Nous ne cacherons pas les problèmes : ce n'est pas valable uniquement pour le système de gestion des bogues

Nous avons actuellement des problèmes dont nous ne parlons pas publiquement. Nous annonçons les nouveaux développeurs, pourtant nous n'annonçons pas les personnes qui quittent le projet ou prennent de longues coupures, même lorsqu'elles sont les personnes importantes. Je ne pense pas qu'il y ait de raison valable à cela tant que nous ne révélons pas leurs motivations.

Nous avons également peur de dire que nous sommes en retard sur notre calendrier ou que nous manquons de main d'œuvre. Je préférerais que nous admettions qu'à ce jour, nous allons rater la date limite de deux mois quatre mois avant la date limite afin qu'on se donne des coups de pied aux fesses pour travailler davantage ou reconsidérer nos priorités, plutôt que de seulement dire qu'il n'y a rien de trop dramatique et de laisser passer la date limite.

Nouvelles personnes

Un effet secondaire de nos demandes de haute qualité pour les nouveaux responsables est que nous recrutons des personnes qui ont de très bonnes capacités pour l'entretien de paquets, dont l'énergie est alors gaspillée à ne pas réellement travailler sur des paquets, alors qu'il y a du travail aussi important à faire. Je veux que les traducteurs, les auteurs de documentation, les graphistes etc. soient aussi développeurs Debian. Nous voulons l'excellence, mais notre processus de recrutement n'est basé que sur l'excellence d'entretien de paquets et Debian n'est pas que cela.

Pour réaliser ceci je veux abaisser le seuil pour devenir développeur Debian, tout en ne donnant pas immédiatement le droit de télécharger et en gardant les conditions actuelles pour les obtenir. Les responsables ftp ont montré récemment qu'il était trivial d'ajouter des restrictions de téléchargement par développeur au kit pour les archives Debian, ce devrait donc être vraiment facile à mettre en application.

Je voudrais également que le travail des conseillers soit plus visible pour nos utilisateurs et je suis ouvert aux idées qui permettront de le réaliser. Par exemple, de la même façon que nous avons une section expérimentale pour les logiciels expérimentaux, nous pourrions avoir des sections conseillers ou non-sûr auxquelles les candidats au processus de nouveau responsable de paquet obtiendraient les droits de téléchargement après un certain temps et quelques obligations de confiance (telles qu'un nombre minimal d'intercesseurs). Cette section ne serait ni construite automatiquement ni signée, et les paquets feraient une transition vers la distribution instable une fois qu'un parrain les auraient approuvés et signés.

Nouveaux jouets

Debian a de l'argent. La dernière fois que quelqu'un a voulu employer cet argent pour faire quelque chose, nous étions en désaccord, et il a trouvé l'argent ailleurs. Nous avons donc toujours cet argent, et je voudrais l'employer au moins pour réparer notre matériel cassé. Je ne peux pas croire que cela soit dans le programme d'un responsable du projet Debian, mais escher est arrêté depuis longtemps, les développeurs n'ont pas accès à une machine d'architecture alpha, et nous n'avons même pas essayé de résoudre ce problème avec de l'argent.

Nouvelles fêtes

En parlant d'argent, des choses qui en exige beaucoup sont les réunions. Les réunions virtuelles ne sont pas suffisantes pour certaines tâches, et isoler des personnes dans un endroit clôt pour travailler ensemble sur rien d'autre que leur projet Debian s'est avéré fonctionner très bien. Bien que je sois effrayé par le luxe toujours plus grand du logement des conférences Debian, je crois que nous pouvons et nous devrions nous permettre d'organiser bien plus de réunions. Il y a des structures locales dans de nombreux pays (Extramadure en Espagne, Cetril en France) qui peuvent s'occuper de la logistique.

Il y a eu une annonce récente que je trouve tout à fait parfaite. Que la décision de poursuivre cette initiative dans quelques mois soit mienne, je serait volontiers d'accord. Je préférerais un rapport circonstancié plutôt qu'un bref résumé de ce qui s'est passé, mais peut-être est-ce ce qui est déjà prévu et ces mots sont-ils simplement impropres.

Rendre à nouveau Debian séduisant

Admettons-le, Debian pourrait être plus séduisant. Actuellement, Debian rime avec épicurien, octogénaire et homme des cavernes. Même le site de FreeBSD est plus attirant que le nôtre, comment pouvons-nous espérer attirer des utilisateurs ? Avez-vous vu comment le site s'affiche sur Internet Explorer ?

Nous avons perdu d'innombrables utilisateurs passés à Ubuntu. Évidemment, Ubuntu a attiré beaucoup de ses utilisateurs d'autres distributions et même de Windows. Mais il n'y a aucune raison pour que Debian soit simplement la distribution sur laquelle sont basées d'autres distributions, nous pouvons également gagner de nouveaux utilisateurs en étant plus attrayants.

Un site plus séduisant, un système de gestion des bogues plus séduisant

Il y a plein de concepteurs doués partout qui voudraient certainement aider à concevoir un site qui semblerait avoir été mis à jour au moins une fois au XXIe siècle. Au moins quelques uns considèrent la renommée comme une récompense suffisante, par conséquent la seule chose à faire est de dire que nous sommes intéressés par une nouvelle conception du site. Nous avons également besoin d'un site plus dynamique, pas, par exemple, avec une liste pathétiquement courte de dix nouvelles par an. Il y a d'autres choses intéressantes à dire à nos utilisateurs sur la page d'accueil, nous avons juste besoin que des responsables du site les ajoutent. Avec mon plan d'augmenter le nombre de développeurs qui ne se concentrent pas sur l'empaquetage, nous aurons bien assez de personnes pour effectuer ce travail.

Notre système de gestion des bogues est laid et à peine utilisable. Si vous ne le pensez pas, vous n'avez probablement jamais été voir le pseudo paquet des paquets en souffrance et paquets souhaités. Je suis malade d'entendre que notre système de gestion des bogues est meilleur que Bugzilla parce que Bugzilla n'a pas d'interface par courriel comme excuse pour cacher le fait que notre système de gestion des bogues est plus laid que Bugzilla et ne vous permet pas d'exécuter des tâches simples en utilisant une interface sur la Toile.

Bien que je voudrais vraiment une interface sur la Toile à notre système de gestion des bogues, des ajouts très mineurs peuvent être faits très rapidement, par exemple en faisant travailler des artistes sur des icônes significatives pour les étiquettes de bogues (voir une maquette ici).

Il y a des services très utiles, comme http://www.buildd.net/, http://bts.turmzimmer.net/ ou http://bjorn.haxx.se/debian/. Je n'arrive pas comprendre pourquoi ce ne sont pas des services de Debian. On peut ne les voir qu'en tant que simples services externes, je les appelle des mises à jour indépendantes de notre infrastructure qui devraient être reconnues et fusionnées. Et si nous manquons de puissance de calcul, j'ai expliqué que nous avions de l'argent pour corriger ceci. Il y a également http://www.backports.org/ qui est un service impressionnant mais qu'il serait subtil d'intégrer à Debian, particulièrement en raison des mises à jour de sécurité, mais nous pouvons au moins essayer de rendre les transitions de lui vers les distributions de test et instable plus douces.

Une distribution plus séduisante

La distribution s'est améliorée en matière de séduction des utilisateurs. Faire travailler des artistes sur des icônes pour nos paquets l'améliorerait encore, de même que le feraient des traducteurs travaillant aux fichiers .desktop.

Les descriptions de paquets sont ce que l'utilisateur voit avant même d'installer le logiciel. Les traduire (en distribuant des fichiers Packages-xx.gz) bénéficierait également à nos utilisateurs.

Publier Etch et Lenny !

La taille de notre distribution est à la fois une fierté et une malédiction. Etch est sur le point d'être publiée et nous sommes parvenus à réduire le temps entre les versions avec un processus plus strict, mais nous ne sommes toujours pas très bons. Au fur et à mesure que le logiciel libre gagne des utilisateurs, des développeurs et des fonds, les projets sont publiés plus souvent et au lieu de suivre cette tendance nous éditons des versions moins souvent.

Il est grand temps que nous mettions en application l'une des plus agressives des stratégies débattues pour obtenir plus de publications avec des logiciels plus à jour, en commençant par Lenny. J'ai personnellement une favorite, mais je ne pense pas qu'il appartienne au responsable du projet Debian de décider laquelle choisir. Je m'assurerai juste que les gens qui veulent rendre cela possible obtiennent les outils et le pouvoir de le faire.

Refaire de Debian le meilleur

Debian est exceptionnel, et il n'y a rien qui ressemble à Debian. Mais nous sommes souvent trop fiers pour admettre que nous pouvons faire mieux ou que d'autres font mieux que nous.

Récupérer d'autres distributions

Il y a des informations qui peuvent être automatiquement récupérées d'autres distributions, même de non-Linux tels que les projets BSD. Naturellement le développeur dévoué à Debian en est bien conscient, et communique déjà avec les développeurs amonts et les développeurs d'autres distributions, mais une manière de surveiller quels correctifs sont appliqués en amont et quels correctifs sont partagés par les distributions serait une bonne chose. Les développeurs amonts et ceux d'autres distributions pourraient tirer bénéfice d'un outil qui surveillerait :

Ubuntu n'est pas le diable seulement à la manière de Google, nous n'obtiendrons pas de correctifs d'eux par pure philanthropie. Mais nous pouvons apprendre de leurs processus autant que nous le pouvons de leurs correctifs, alors servons-nous tout simplement. Gentoo est une autre excellente distribution sur laquelle nous devrions étroitement garder un oeil. En dépit de toute les critiques qui peuvent être faites, il y a également beaucoup à apprendre. Ils ont été plus rapides que nous pour ajouter de nouvelles architectures et de nouveaux noyaux à leur infrastructure principale, par exemple.

Demeurer le système d'exploitation universel

J'aimerais voir d'avantage de projets alternatifs bénéficier du reste de notre infrastructure (particulièrement buildd.d.o) bien plus tôt dans le processus de portage. Nous avons raison d'avoir des conditions pour inclure ces nouvelles architectures, mais les bogues de portabilité ignorés ne sont pas rares, de même que les régressions, un cas pour lequel le responsable ne doit pas nécessairement être blâmé si les journaux de construction ne sont pas disponibles. L'inclusion de l'architecture amd64 a souffert de retards pathétiques que je ne veux pas que cela se reproduise.

Un autre grand ajout à la distribution serait la gestion multiarchecture. Il est en cours, et si chacun y travaille nous pourrons le réaliser dans Lenny.

Je suis également intéressé à soutenir l'approche de dpkg-cross pour construire sur une autre architecture la distribution pour les cibles qui ne peuvent pas faire fonctionner une infrastructure de construction (telle que les processeurs très spécifiques sur les plates-formes embarquées).

En ce qui concerne l'organisation, je pense qu'au moins un porteur par architecture devrait avoir accès à wanna-build.

Utiliser le kit pour les archives Debian pour nous aider

Nous pourrions employer quelques améliorations du logiciel de gestion d'archives. Par exemple, éviter les attentes inutiles dans la file des nouveaux paquets (comme les simples changements de nom d'objets partagés) en acceptant les nouveaux paquets binaires pour un paquet source qui est déjà dans les archives. La latence de traitement de la file d'attente des nouveaux paquets ne devrait pas affecter le développeur de tous les jours, et l'abus de binaires multiples pourrait être traité par le système de gestion des bogues.

Lintian pourrait également être intégré dans le kit pour les archives Debian pour rejeter automatiquement les téléchargements contenant des erreurs manifestes (binaires dans etc/, mention de droit d'auteur manquante, bibliothèque partagée sans informations de dépendances...).

Déboguer Debian

Une infrastructure de débogage n'est pas quelque chose de nouveau, beaucoup de développeurs en ont parlé et y ont travaillé. Il reste toujours beaucoup de travail à réaliser et je voudrais en faire une priorité : produire de manière transparente des paquets de débogage .ddeb (par exemple pendant le dh_strip ou une étape équivalente), les intégrer dans le kit pour les archives Debian, les intégrer dans apt, les intégrer avec les infrastructures de plus haut niveau telles que les gestionnaires de signaux d'erreurs de segmentation de Gnome et de KDE.

Je voudrais également rendre les journaux de construction obligatoires. Il n'y a actuellement aucune manière de savoir comment les paquets que nous téléchargeons ont été exactement construits, et nous pourrions facilement nous raccrocher à dpkg-buildpackage pour créer le journal de construction et l'attacher au .changes, puis rendre cela obligatoire plus tard. dh_buildinfo est une autre initiative sous-exploitée.

Donner du pouvoir aux équipes transversales

Nos équipes transversales (particulièrement les traducteurs) font déjà des mises à jour indépendantes de paquets pendant des périodes de publication. Permettons-leur de toujours le faire, avec des règles raisonnables. Selon ces règles je voudrais que les mises à jours indépendantes à faible latence deviennent par la suite le standard plutôt que l'exception (actuellement environ 150 personnes, qui sont probablement parmi les développeurs les plus actifs, se sont inscrites).

L'équipe d'assurance qualité ressemble aux éboueurs des archives, faisant des téléchargements d'assurance qualité de paquets orphelins. Je veux qu'il devienne totalement naturel de voir des téléchargements d'assurance qualité réalisés par n'importe qui pour n'importe quel paquet ayant de vieux bogues non traités avec des correctifs, par exemple. Pour éviter les abus, on pourrait rendre obligatoire le délai de la file d'attente pour les mises à jour indépendantes d'assurance qualité.

Ubuntu gère les transitions bien mieux que nous parce que personne ne possède de paquets. En ayant une sorte de force de frappe des transitions, ou des escouades plus génériques agréées par les responsables de publication, je pense que nous pouvons parvenir au même résultat. Ces équipes (idéalement tous les développeurs, naturellement, avec une protection contre les abus) auraient également un accès limité à wanna-build pour un réordonnancement rapide de la file d'attente.

La fin

C'est tout. Merci de m'avoir lu

Réfutation

Wouter Verhelst (yoe)

Le programme de Wouter est un programme de soumission et d'indécision. Il est difficile de commenter ce qu'il fera puisqu'il ne le sait pas encore et ne croit pas que le responsable du projet Debian a le pouvoir de faire grand chose de toute façon, et même ses quelques exemples des choses qu'il ne fera pas n'en disent pas beaucoup (aucun changement radical, mais aucun arrêt complet ?).

J'aurais aimé un peu de substance pour la commenter. Actuellement tout que je peux dire c'est que d'autres candidats, y compris moi, proposent des choses concrètes que Wouter peut ou pas essayer de faire aussi bien, mais jusqu'ici je ne vois ni la reconnaissance de beaucoup des problèmes que nous rencontrons ni un réel désir de changer les choses.

Aigars Mahinovs (aigarius)

Aigars suggère principalement des décisions techniques qui n'ont rien à faire avec la position du responsable du projet Debian. Certaines de ces suggestions sont des changements radicaux de notre manière de travailler (le tronc permanent) qui signifieraient, je crains, une perte totale d'identité et feraient abandonner Debian par certains utilisateurs et développeurs. La suggestion d'abandonner nos marques déposées est cohérente avec cette perte d'identité.

Le processus de l'ancien responsable de paquets semble digne de considération mais je crois que les développeurs incapables de suivre la charte ou de maintenir les qualifications techniques globales exigées soit partiront par eux-mêmes soit seront supprimés par le processus des développeurs perdus de toute façon.

Gustavo Franco (stratus)

Il y a un manque de clarté et de raisonnement globaux (à quoi servira le renouvellement de comité technique, qui va mettre en application toutes ces choses techniques) et une main d'œuvre clairement surestimée. Un bon nombre de je vais partout, que je ne trouve pas réalistes pour une position de responsable du projet Debian.

Cependant Gustavo voit les mêmes problèmes que moi, et le chevauchement entre mon programme et le sien est étonnant. Je travaillerais avec plaisir avec lui si l'occasion m'en est donnée. Boa sorte !

Sven Luther (luther)

Étant donné qu'il n'a pas répondu aux questions sur -vote, je ne pensent pas que Sven continue à être candidat à l'élection de responsable du projet Debian.

Sam Hocevar (sho)

Ce type est excellent. Je vote pour lui.

Steve McIntyre (93sam)

Ayant été l'ombre du responsable du projet Debian, Steve mérite une part de la critique adressée à Anthony, mais son programme est clairement concentré sur le futur plutôt que le passé.

Comme moi, il s'occupe de notre problème de communication en suggérant des comptes-rendus, mais il n'explique pas comment on peut s'assurer que ces rapports seront faits. Comme moi, il favorise l'accueil de nouveaux venus dans des équipes, mais il ne le fait que du point de vue des équipes de nouveaux responsable et d'empaquetage et ne mentionne pas nos équipes principales.

Le programme de Steve pointe beaucoup de problèmes réels que nous avons et avec lesquels je suis d'accord. En fait je suis d'accord avec la plupart de ce qui est énoncé. Il n'y a cependant pas beaucoup de suggestions sur la façon de les résoudre.

Raphaël Hertzog (hertzog)

Je ne suis pas fanatique de l'idée de l'équipe de direction de Raphaël. Il vaut naturellement mieux avoir plus de personnes pour effectuer le travail, mais je crains que la prise de décision puisse souffrir de cette procédure supplémentaire, particulièrement en matière de retards.

Raphaël explique comment l'administration système de Debian n'a jamais approuvé ni bloqué son travail sur Alioth. Je suis un peu circonspect sur le fait que son idée d'autoriser des personnes à faire des choses pourrait signifier les encourager à les faire en solo ou à contourner d'autres équipes, au lieu de coopérer.

Naturellement son futur programme sera l'équipe de direction. Alors qu'il n'y a personne dans cette équipe avec qui je n'apprécierais pas de travailler, je ne me sentirais probablement pas à l'aise pour discuter à nouveaux de mes idées au lieu d'être dans la position plus rassurante d'avoir été élu sur un programme avec des propositions concrètes.

Anthony Towns (ajt)

D'après son programme, Anthony semble chercher sa réélection en se basant sur son mandat 2006-2007. Tout parle du passé, pas grand chose du futur. Ce qui est remarquable dans sa revue est sa participation à SPI (si bien que si j'étais élu et recherchais un représentant à SPI je saurais à qui m'adresser).

En outre, en recherchant le mot communication dans son programme il ne semble pas qu'il reconnaisse ou prévoit de s'attaquer aux problèmes de communication qui ont été soulevés tout au long de son mandat. Tandis qu'il admet que le recrutement n'a pas marché comme prévu, il ne fait aucune proposition pour le rendre meilleur, particulièrement au sujet des équipes principales (bien qu'il plaide avoir, l'année dernière, encouragé les fonctions d'assistants). Au global, je ne crois pas qu'Anthony ait fait de Debian un endroit bien meilleur pour des développeurs.

Simon Richter (sjr)

Simon se concentre sur les raisons de nos problèmes pour publier de nouvelles versions et de la polémique sur Dunc-Tank, pourtant il ne fait pas de suggestions sur la façon de les alléger. En fait je n'ai aucune idée de ce qu'il fera s'il est élu.