Programme d'Anthony Towns

Bonjour, je m'appelle Anthony Towns. Je suis candidat à l'élection du responsable du projet Debian cette année. Voici ce sur quoi j'aimerais travailler.

Accueillir des personnes dans le projet

Je pense qu'il est important que le projet accepte des contributions d'un groupe de personnes techniquement compétentes aussi large que possible. Je pense que la meilleure façon d'y arriver est :

  1. de truffer nos listes de discussions techniques intéressantes qui accueillent les contributions intelligentes des nouveaux venus et ne perdent pas plein de temps à revenir sur d'anciens sujets classés ou sur du hors sujet. Remarques complémentaires : [1] [2] ;
  2. d'inviter les nouveaux arrivants à venir assister des groupes existants ; et à traiter les assistants comme des personnes plutôt que comme des nouveaux programmes qui ont besoin de passer par une suite de tests standardisés. Remarques complémentaires : [1] ;
  3. de permettre aux utilisateurs de participer au projet de façon reconnue, et ainsi de pouvoir les consulter directement sur les décisions plutôt que de laisser les développeurs deviner leur opinion. Remarques complémentaires : [1] [2] [3] ;
  4. de rendre nos activités bien plus publiques, par exemple, en menant plus de débats sur les listes existantes, en créant des listes temporaires pour des discussions rapides qui seraient cependant archivées de façon permanente dans Debian, et en résumant les débats sur IRC sur des listes de manière systématique ;
  5. d'essayer activement d'inclure des dérivés dans le projet plutôt que d'espérer passivement qu'ils contribueront — par exemple inclure des projets comme Knoppix, backport.org, Ubuntu, fink et d'autres dans l'archive là où c'est possible ; et sinon développer les relations avec des organismes comme HP, Linspire, SkoleLinux et d'autres. Remarques complémentaires : [1].

Efficacité du projet

Bien qu'il soit parfois difficile de le dire, Debian a actuellement un but : à savoir créer un fantastique système d'exploitation libre. Il est important que nous soyons efficaces pour arriver à cet objectif — il ne sert à rien d'avoir le meilleur des concepts de système d'exploitation, les meilleures des chartes pour l'assembler, ou les meilleures des procédures pour l'entretenir si nous n'arrivons pas à suivre ces concepts, ces chartes et ces procédures, ni à implanter quoi que ce soit. Je pense que Debian a pris du retard dans ce domaine, et que la manière de résoudre cela est de travailler à prendre des décisions et à les suivre plutôt que d'essayer d'entretenir un consensus bancal en menant constamment les même débats avec de nouveaux participants.

Nos mécanismes pour prendre des décisions sont :

  1. le consensus sur les listes de diffusion ;
  2. l'expertise des délégués et des responsables de paquets ;
  3. l'expertise du comité technique ;
  4. les résolutions générales des développeurs dans l'ensemble.

Le premier a été la clef du succès de Debian — toute décision qui peut satisfaire plus ou moins tout le monde dans un groupe hétérogène est assez bonne. Il n'est bien sûr pas toujours possible de prendre une décision de cette façon ; c'est pourquoi nous avons besoins des autres possibilités. Malheureusement, elles ne fonctionnent pas très bien actuellement.

J'ai la conviction que Debian pourrait s'améliorer ici simplement en donnant aux délégués une autorité claire pour prendre des décisions dans leurs domaines d'expertise, ainsi qu'en acceptant que l'on puisse persuader et convaincre les délégués et les responsables de paquets que quelque chose pourrait être fait d'une certaine façon. Remarques complémentaires : [1]

De plus, je pense que le comité technique servirait mieux le projet s'il était composé des membres actifs d'équipes clefs plutôt que par les vieux sages actuels ; cela à la fois comme un signe de confiance envers nos délégués et pour s'assurer que la connaissance des processus de Debian par le comité technique est aussi récente et complète que possible. Remarques complémentaires : [1].

Qualité de la distribution

Somme toute, je pense que nous pourrions produire une distribution substantiellement meilleure. La plus grande partie du travail a déjà été faite par les dérivés — comme l'accélération des scripts d'initialisation sur laquelle ont travaillé les gens d'Ubuntu, ou le développement d'un CD direct pour lequel Knoppix est connue — et nous pouvons acquérir ces caractéristiques simplement en travaillant à une meilleure intégration des dérivés ; mais il y a d'autres sujets, à mon avis, sur lesquels Debian lui-même devrait travailler :

  1. une meilleure charte — à présent la « charte » est fragmentée entre la charte Debian, la référence du développeur, divers documents spécifiques pour des sous-systèmes, et le bouche à oreille. Je pense que nous devrions travailler à leur intégration dans un unique paquet, si ce n'est dans un seul document ;
  2. une meilleure assurance qualité — avoir la totalité du code source de tous les logiciels que nous fournissons est la chance d'exceller dans un faisceau de domaines du type de l'assurance qualité ; je pense que nous ne devrions pas simplement avoir pour but de récolter tous les logiciels sympathiques qui passent à notre portée pour les mettre dans un .deb, mais que nous devrions aussi polir les parties rugueuses en écrivant des ensembles de tests automatiques pour nos paquets afin de nous assurer que tout est documenté et pour tendre vers le zéro défaut pour tout ce que nous embarquons.
  3. une meilleure sélection de paquets — l'un des problèmes que tout utilisateur de Debian a rencontré et rencontrera certainement encore est de trouver quels paquets installer ; par exemple ether-wake ou wakeonlan ? Je pense que cela fait longtemps que nous n'avons pas fait de progrès significatifs dans ce domaine, en nous posant des questions sur le classement et l'imbrication des paquets, ainsi que l'accessibilité des paquets non libres ou commerciaux.

Addenda

Enfin, quelques autres notes que vous trouverez pertinentes ou pas.

Je pense que le rôle du responsable du projet Debian est, eh bien, de mener le projet : trouver les domaines particuliers sur lesquels le projet devrait se concentrer, ainsi que trouver les domaines où le projet fonctionne mal et l'aider à s'en sortir. Le responsable du projet Debian n'a en fait qu'un seul pouvoir, donner de l'autorité aux autres. C'est un pouvoir assez subtile — c'est la différence entre celui qui a le mot de passe du superutilisateur et celui qui a la permission de l'utiliser. Mais dans un groupe de personnes qui se soucie aussi résolument qu'un développeur Debian de ce qui est juste et ce qui est faux, c'est en fait un pouvoir relativement important. Remarques complémentaires : [1] [2].

Pour ceux que ça intéresse, j'ai rejoint Debian au début 1998. Je suis l'auteur d'ifupdown et de debootstrap. J'ai écrit des correctifs pour gzip (bogues n° 30537, n° 184057), pour dpkg (bogues n° 93386, n° 112386, n° 184635), pour pax (bogue n° 139943), et d'autres. J'ai participé aux forums sur la base standard Linux et le standard hiérarchique des systèmes de fichiers, ainsi que sur diverses listes Debian. J'attends toujours avec impatience le jour où les bogues n° 18733 et n° 62529 seront résolus.

J'ai écrit des scripts SGI pour bugs.debian.org comme preuve de faisabilité et j'ai commencé à conserver d'anciens rapports de bogue plutôt que de les laisser se perdre à jamais un mois après leur clôture. Je me suis alors retrouvé dans l'équipe des bogues de Debian lorsque les vieux scripts qui généraient les pages statiques une ou deux fois par jour ont commencé à défaillir juste parce que nous avions trop de bogues. J'ai également ajouté le support des étiquettes de bogues, des requêtes par rapporteur, le clonage des bogues et le blocage de l'accès à l'adresse control@ pour les personnes qui en abusent.

Mon activité la plus exposée dans le projet est ma participation à la gestion des éditions. J'ai commencé à m'y impliquer en 1998 en m'engageant dans le débat à propos du « modem de publication de Debian », Debian release modem, (sic) sur -devel, et avec d'autres personnes intéressées nous sommes arrivés à l'idée qui est derrière la distribution de test. Après de plus amples discussions et des modifications, j'ai commencé à implanter « britney » en 1999 en entretenant une copie de l'archives par des liens durs, et pour finir nous sommes arrivés à un point où je pensais qu'on était prêt à l'intégrer correctement en 2000. À ce moment, j'ai proposé à Richard Braakman de l'aider dans la gestion de l'édition de Potato, il avait pratiquement fuit le pays, et j'ai dû réaliser les phases finales de la publication de Potato qui est sortie en août 2000. J'ai ensuite travaillé avec Jason Gunthorpe (qui est l'auteur principal d'apt) et James Troup pour convertir l'archive en zones afin de pouvoir abandonner les horribles liens durs et de pouvoir faire des miroirs de la distribution de test, et nous avons sorti cette distribution fin 2000. C'est à cette époque que j'ai été ajouté au groupe des responsables ftp pour rendre plus facile l'intégration. J'ai poursuivi en tant que responsable de publication pour Woody, j'ai alors pensé que suivre l'exemple de Richard serait une bonne chose et j'ai eu la chance que Steve Langasek et Colin Watson se portent volontaires.

J'ai saisi l'occasion de me retirer du rôle de gestionnaire de publication l'année dernière pour différentes raisons. À long terme, je souhaitais transmettre le rôle de responsable de publication depuis quelques temps déjà — je suis plus intéressé (et efficace) dans la conception initiale et l'implantation que sur l'entretien à long terme — et Colin et Steve étaient déjà capables de réaliser la plupart du travail eux-mêmes. À court terme, je n'étais plus convaincu d'avoir le soutien du projet pour faire le travail du responsable de publication, et Colin et Steve auraient une bien meilleure occasion de le poursuivre sans confusion ni distraction. Je pense que ça s'est plutôt bien passé.

Mon activité de responsable ftp consiste principalement en la maintenance de britney, en travail de conception, avec de temps en temps le suivi de nouveaux paquets et des demandes de suppression. J'ai fait pas mal de travail de coordination pour le passage des logiciels de chiffrement dans l'archive principale, à comprendre comment refaire le suivi de sécurité pour l'édition Woody, et j'ai conçu et implanté les fichiers Released signés et aidé à leur support par apt.

Conclusion

Je pense que mes expériences à l'intérieur de Debian correspondent raisonnablement bien avec ce que j'aimerais accomplir et que des progrès intéressants devraient être possibles cette année dans les domaines ci-dessus. Mais bon, il m'est déjà arrivé de me tromper.

Critiques des autres candidats

Eh ! Il leur est aussi arrivé de se tromper !

Réfutation

Angus Lees

J'envie la brièveté d'Augus à ce niveau, et j'espère que j'arriverai à l'égaler un jour.

Matthew Garrett

Je pense que le programme de Matthew est assez bon. Ses priorités sont un peu différentes des miennes, mais je pense que s'il accomplit ce qu'il souhaite, ce sera bien pour Debian.

Cependant, je ne suis vraiment pas d'accord avec l'accent que met Matthew sur les débats sans confrontation. Je crois que tenter d'éviter les confrontations tend à essayer de satisfaire les personnes les plus tenaces, car elles essayeront de s'assurer qu'il y ait une confrontation à moins qu'elles n'obtiennent exactement ce qu'elles souhaitent, alors que des personnes plus discrètes n'engageront généralement pas de confrontation avant que les choses ne commencent réellement à laisser désirer. Je crois vraiment que les gens sont capables de gérer avec respect des opinions divergentes et des approches différentes, sans devoir se disputer ni être violents ; mais je pense qu'il est important que toute personne dans une position de direction soit prête à mener une discussion en règle pour défendre les gens qui travaillent avec elle, et cela comprend des confrontations de manière occasionnelle. Je crois qu'il est bien meilleur d'avoir ces confrontations et de les résoudre que de les éviter.

Andreas Schuldei et le projet Scud

Je trouve le développement du projet Scud assez déconcertant ; il semble qu'un groupe secret de développeurs Debian s'est formé avec le seul but de prendre le contrôle du projet, et vraiment je ne vois pas comment quelque chose comme cela puisse être autrement que déconcertant.

Andreas et Steve ont mené toute (ou presque toute) l'organisation de la cabale contre la publication qui s'est tenue à Vancouver (les 5 et 6 mars), ce fut une grande idée, et je pense qu'elle a été efficace —  mais elle a été organisée sans en avertir le responsable actuel du projet Debian, sans plus d'informations que celles fournies au reste du projet. J'aime plaisanter de cette cabale dans Debian, mais parce que, de mon expérience, *c'est* une plaisanterie ; toutes les personnes qui ont du pouvoir dans Debian ont une opinion assez différente et assez joyeusement travaillent les unes contre les autres, ne communiquent pas plus entre elles qu'avec le reste du projet, et ont toutes sortes d'autres problèmes. Le projet Scud au contraire semble avoir été une réelle « cabale » jusqu'à présent, et je ne sais pas trop comment nommer délibérément un tel groupe pour diriger Debian pourrait être une bonne chose pour la promotion du développement ouvert, public et orienté vers la communauté pour lequel Debian est connu.

Un autre soucis avec le projet Scud est que s'il est élu, sa façon de fonctionner n'est pas claire du tout —  chaque membre a-t-il déjà un domaine d'autorité bien défini, le responsable du projet Debian prendra-t-il les décisions et l'équipe les mettra-t-elle en œuvre, ou essayeront-ils de prendre les décisions en groupe avec comme président le responsable du projet ? Cela dépendra peut-être du candidat élu. Le soutien du projet Scud aux programmes de ses deux candidats ou la façon dont les candidats soutiennent chaque membre de l'équipe ne sont pas clairs non plus. On a un peu l'impression que voter pour l'un ou l'autre des candidats du projet Scud, c'est comme jouer à la roulette.

Branden Robinson

Je ne peux sans doute pas écrire grand chose sur Branden qui ne puisse être écarté par quelque chose comme « Oh, mais AJ et Branden se disputent tout le temps, bien sûr qu'il l'a dit ». Et si vous aimez ce genre de choses, Branden et moi avons rejoint le projet la même semaine (fin février 1998 pour ceux qui souhaitent vérifier les archives de -private —  la même semaine que Eric S. Raymond).

Quoi qu'il en soit, j'ai deux soucis que vous pouvez ou non prendre en compte avec Branden. Le premier est son attachement régulier lors de ces années de campagnes aux problèmes de procédures à l'exclusion des problèmes techniques : je pense qu'il est bien plus important pour les membres du projet de s'attacher à ce que nous souhaitons accomplir plutôt qu'à la manière d'y arriver, et que nous serons bien mieux si nous bloquons occasionnellement le processus mais ne perdons pas de vue ce que nous essayons de réaliser que le contraire. Je pense que les priorités du responsable du projet devraient refléter cela.

Mon second soucis est que je ne pense pas que Branden ait démontré qu'il serait très efficace pour arriver à ses objectifs. Lorsqu'il est devenu trésorier de SPI en août 2001, son but était de corriger les problèmes de conservation des registres qui s'étaient accrus jusque là, et d'être bien plus transparent et efficace pour l'acceptation et le traitement des dons et des remboursements. Malheureusement, et pour diverses raisons, il n'y est pas arrivé — au point que des dons au projet Debian n'ont pas été déposés du tout pendant une période d'environ une année, ont expiré et ne peuvent plus être déposés à nouveau. Avec la rétrogradation de Branden en trésorier adjoint de Jimmy Kaplowitz, il semble être devenu beaucoup plus efficace, ce qui est en sa faveur, mais, à mon avis, indique toujours qu'il n'est pas prêt pour un poste de direction important. Remarques complémentaires : [1].

Je sens que je devrais aussi noter que pendant que Branden indique que le projet Scud soutient la méthode de scrutin que nous utilisons au moins pour l'élection du responsable du projet Debian, il était l'un de ceux qui avaient voté contre son adoption lorsqu'elle avait été proposée ; et de plus il avait fortement argumenté pour encourager les votes non sincères avant le scrutin sur l'archive non libre il y a un peu plus d'un an.

Jonathan Walther

Commentaires similaires d'Erinn Clark sur la proposition de comité de Jonathan.

Je trouve que je ne suis pas d'accord avec le sentiment que Jonathan indique dans son programme, sentiment d'intérêt croissant pour l'implication des femmes dans Debian. Personnellement, j'ai été plutôt encouragé à la fois par le nombre croissant de femmes qui pensent pouvoir participer à Debian et par la forme de leur participation, en particulier les magnifiques diagrammes d'état de dpkg de Margarita Manterola, les présentations d'Hanna Wallach lors des conférences sur Linux, et le programme de parrainage mené par Helen Faulkner, ainsi que l'étendue habituelle d'entretien, de rapports et de corrections de bogues de paquets. Autant que je sache, cette activité est due principalement au travail d'Erinn Clark et Helen Faulkner à la conduite et à l'entretien du projet Debian Women. Il est en particulier impressionnant que toutes ces femmes aient fait toutes ces contributions avant d'avoir réussi à passer le processus du nouveau responsable.

Je pense que la meilleure des choses que nous puissions faire pour la participation des femmes à Debian soit d'admirer ce qu'elles ont réalisé aujourd'hui, de faire ce qui nous est possible pour les aider à améliorer leurs succès, et nous assurer que nous incorporons leurs réussites dans d'autres domaines du projet.