Programme de Raphaël Hertzog

Présentation

Je m'appelle Raphaël Hertzog. On me surnomme buxy sur IRC. Je suis Français, j'ai 23 ans et je suis étudiant à l'INSA de Lyon. Je fais partie du département informatique. J'obtiendrai mon diplôme d'ingénieur cet été après quoi je chercherai du travail lié au logiciel libre (ce qui, je l'espère, me laissera du temps pour mon travail pour Debian).

Mon histoire dans Debian

Mon premier contact avec Linux fut avec Debian 1.3. Cela remonte à 1997. J'ai commencé par essayer Debian car quelqu'un m'avait dit que Perl y était installé par défaut et parce que j'avais découvert Perl sur Windows quelques mois auparavant et que je pensais que c'était vraiment un bon outil. Cependant, j'ai rapidement effacé ma partition Debian pour essayer d'autres distributions (surtout Red Hat). Je suis revenu à Debian quelques mois plus tard principalement pour deux raisons : elle était utilisée par les personnes les plus compétentes que je connaissais dans mon LUG, et j'avais compris que c'était la seule distribution où je pouvais m'investir et aider.

En 1998, j'ai rejoint Debian en tant que développeur et j'ai commencé avec un unique paquet nommé «  sympa ». Il n'était même pas libre d'après les principes du logiciel libre selon Debian (il avait une clause restrictive contre les utilisations commerciales), cependant la licence a été corrigée après discussion avec les auteurs originels.

J'ai rapidement été intéressé par le travail d'assurance qualité de Debian qui était alors géré par Vincent Renardias. Il m'y a initié. J'ai commencé chercher des paquets sur lesquels je pourrais travailler avec mes compétences en Perl, et j'ai trouvé dpkg-ftp (la méthode ftp de dselect). Je m'en suis emparé car il était dans un très mauvais état, et j'ai corrigé tous les bogues connus, y compris la réponse aux souhaits.

En 1999, l'équipe debian-cd a rencontré un problème car son script n'était pas vraiment conçu pour gérer plusieurs CD et Slink était la première version de Debian qui avait besoin de plus d'un seul CD. C'est la raison pour laquelle j'ai écrit YACS, Yet Another Cd Script encore un autre script de CD (cela dit j'ai utilisé une partie du code de slink_cd de Steve McIntyre) ; YACS est devenu le debian-cd officiel de l'édition Potato. Il était de meilleure conception ce qui permettait de traiter efficacement plusieurs CD et des CD personnalisés (vous pouviez facilement personnaliser le contenu des CD). Je suis toujours le responsable de debian-cd.

En 1999 également, nous avons eu de gros problèmes avec l'équipe des nouveaux responsables. Elle avait fermé les vannes pour diverses raisons. Je n'étais pas d'accord avec cette décision. C'est pourquoi j'ai lancé le mécanisme de parrainage. Le principe est simple : chaque responsable en devenir doit trouver un développeur Debian officiel qui vérifie son travail et qui télécharge son paquet dans Debian. Bien sûr, le développeur Debian partage ses observations sur le paquet avec le futur responsable pour qu'il progresse. Et c'est pour cela que ce système de parrainage a survécu même après la réouverture des portes aux nouveaux responsables. Il s'est révélé être un outil fantastique pour l'entraînement du futur développeur et pour s'assurer qu'il partage nos principes (contrat social, principes du logiciel libre selon Debian).

Toujours en 1999 (je ne me rappelais pas avoir tant fait au cours de la même année ! :-), j'ai aidé Darren Stalder à préparer perl-5.005 et j'ai géré toute la migration de Perl (tous les modules binaires devaient être recompilés, j'ai contacté toutes les personnes concernées et réalisé des mises à jours indépendantes pour les paquets qui n'avaient pas été mis à jour dans les temps). En même temps, j'ai écrit la première version de la charte sur Perl.

Après cela, j'ai travaillé à la résurrection de l'assurance qualité de Debian. J'ai lancé qa.debian.org, qui existe toujours mais dont le contenu a été complètement mis à jour depuis grâce au bon travail de nombreux autres travailleurs de l'assurance qualité comme Josip Rodin et Martin Michlmayr, et j'ai créé le comité pour l'assurance qualité. Ce comité n'existe plus car il ne fonctionnait pas. C'était une tentative pour organiser l'assurance qualité avec une équipe qui décidait de ce qui devait être réalisé et avec des travailleurs qui faisaient réellement le travail. Mon analyse de cet échec est que c'était trop centralisé pour Debian et que cela ne correspondait pas à la façon de faire de Debian.

De nos jours, je suis convaincu que pour ne pas se laisser distancer par la quantité de travail et pour conserver sa grande qualité, Debian doit s'adapter pour éviter les problèmes (paquets mal entretenus, paquets oubliés mais non orphelins...) C'est pourquoi j'ai lancé le système de suivi des paquets avec l'aide d'Anthony Towns. L'idée principale qui se cache derrière ce système de suivi des paquets est que nous devrions disposer de plus de personnes pour s'occuper de chaque paquet. S'occuper d'un paquet peut signifier plusieurs choses, d'aider le responsable (pour un autre développeur) à simplement surveiller que le paquet est correctement entretenu (pour un utilisateur avancé qui s'intéresse à ce paquet en particulier).

Et pendant tout ce temps, j'ai suivi de nombreuses listes de diffusion et j'ai participé à des douzaines de discussions (et trolls, même si j'avais tendance les sauter car très souvent on ne fait qu'y perdre son temps). J'ai parrainé plusieurs futurs responsables et j'ai participé à de nombreuses chasses aux bogues. Et bien sûr j'ai réalisé mon travail habituel de responsable : j'entretiens cinq modules Perl, dpkg-ftp, debian-cd et logidee-tools.

Grâce à cette expérience, je crois être assez familier de Debian et de sa façon de travailler. J'ai été en contact avec de nombreuses personnes impliquées dans tous les aspects clefs concernant Debian (les disquettes de démarrages, les responsables ftp, le responsable de publication, les responsables du système de suivi des bogues, l'équipe de sécurité, l'équipe d'assurance qualité, l'équipe du site, les administrateurs, les porteurs et les responsables du démon de construction des paquets...).

Le rôle du responsable du projet

À mon avis, les principales tâches du responsable sont l'organisation et la communication.

La partie d'organisation concerne le travail interne de Debian, le responsable du projet doit s'assurer que les infrastructures de Debian sont adaptées notre travail. Si nécessaire, il doit initier des projets pour résoudre ces problèmes. Si vous souhaitez savoir de quelles infrastructures je parle, veuillez regarder mon programme.

La partie communication peut être scindée en deux catégories : interne et externe. Le responsable doit être en contact avec autant de personnes que possible à l'intérieur de Debian et doit s'assurer que chacun va dans la même direction. Le responsable représente également Debian dans le monde extérieur, il répond aux entretiens, participe aux expositions etc.

Quoi qu'il en soit, il n'est pas toujours possible d'aller partout où vous êtes invités et je réfléchis donc à la possibilité de désigner des représentants locaux du responsable (volontaires bien sûr).

En bref, le responsable doit s'assurer que le travail de Debian peut être réalisé dans de bonnes conditions et que chaque personne impliquée s'amuse et peut être fière de ce qu'elle fait...

Projets pour Debian

Mon programme comporte tellement de points que je ne peux pas garantir de les achever tous. Cependant je ferai tout mon possible pour en mener le maximum leur terme. Chaque projet sera assigné à une personne responsable (les candidats sont invités à me contacter) qui devra me tenir informé de ses progrès. Je publierai régulièrement des messages expliquant où en est chaque projet et quel est son état.

Voici la liste de tous les projets que je souhaiterais gérer pendant la prochaine année. Ils sont classés en deux catégories :


1. Organisation

1.1 Sourceforge pour les développeurs Debian

Créer un sourceforge.debian.org pour permettre aux développeurs Debian d'héberger leurs propres projets de logiciels libres est une bonne idée pour plusieurs raisons :

Bien sûr, les projets hébergés sur sourceforge.debian.org n'auraient pas besoin d'être spécifiques à Debian. Le seul critère serait d'être demandés par un développeur Debian.


Comme vous le savez, je fais partie de l'effort d'assurance qualité de Debian depuis un certain temps et en tant que tel, je souhaiterais qu'il soit mieux connu et plus efficace. Bien que je n'aie pas de solution miracle (nous pouvons le promouvoir un peu plus, mais cela fait partie de mes projets de communication), j'ai de nouvelles tâches pour lui :

1.2 Vérification des responsables actifs

Cette idée revient souvent, mais personne ne l'a vraiment réalisée. Martin Michlmayr a commencé quelque chose pour rechercher les responsables portés disparus mais il ne contacte personne, seulement les gens qui ont été détectés comme disparus par quelqu'un d'autre (qui a trouvé une grande liste de bogues sans réponse ou autre). Il est temps que nous contactions effectivement les responsables qui, soit ont des paquets en mauvais état, soit ont disparu (en fonction des informations dont nous disposons) :

1.3 Recrutement de gens pour adopter des paquets

Comme vous le savez, le nombre de paquets orphelins augmente et bien plus de paquets qui ne sont pas orphelins devraient l'être (car ils ne sont pas bien entretenus). Nous avons deux solutions avec les paquets orphelins : soit nous les supprimons, soit nous leur trouvons un nouveau responsable. L'équipe d'assurance qualité supprime déjà des paquets de temps en temps. Mais personne n'essaye réellement de trouver de nouveaux responsables. Rendre la liste des paquets orphelins disponible sur la Toile n'est pas suffisant (la parcourir est difficile).

Nous devons mettre sur pied une équipe pour prendre contact avec les responsables (passés et actuels), les contributeurs passés que l'on peut trouver dans le système de suivi des bogues, les auteurs originels et les listes de diffusion spécialisés sur ces paquets. Le but est de trouver un nouveau responsable et plusieurs personnes motivées qui s'abonneraient au système du suivi des paquets pour aider à nettoyer (et à entretenir) le paquet. Si nous n'arrivons pas à trouver le développeur Debian actuel, l'équipe devrait trouver un parrain jusqu'à ce qu'une des personnes intéressées devienne développeur officiel.

Les responsables pourraient aussi demander l'aide de cette équipe pour trouver des « responsables de secours » ou des contributeurs pour les aider dans la gestion de leur paquet.

Tout ce travail pourrait être coordonné via un nouveau paquet virtuel dans le système de suivi des bogues (un peu comme wnpp, même si je n'ai pas d'idée de nom pour le moment).


Étant Français, je connais assez bien les problèmes de traduction (et d'internationalisation). Nous avons encore beaucoup de travail avant d'arriver à une internationalisation complète. Je crois que nous avons besoin d'une meilleure infrastructure pour coordonner les traducteurs, les relecteurs et les développeurs. Le DDTP de Michael Bramer est un premier pas dans cette direction même s'il a généré des discussions très enflammées sur debian-devel...

1.4 Infrastructure de traduction

Je n'ai pas encore d'idée précise sur la manière de le mettre en place. Cependant, nous connaissons les problèmes que nous devons gérer :

Vous pouvez également regarder les statistiques de traduction de Debian pour en apprendre plus sur le processus de traduction et pour voir le type d'information que la nouvelle infrastructure devrait fournir (en temps réel).


Après des années de bons comptes-rendus, Debian a récemment reçu une mauvaise publicité sur sa manière de gérer les alertes de sécurité. J'aimerais y apporter des améliorations.

1.5 Seconde équipe de sécurité

Nous pouvons créer une seconde équipe de sécurité qui aurait accès aux mêmes informations que la principale et qui aurait accès aux mêmes outils (rbuilder...) L'objectif principal de cette seconde équipe serait de fournir des paquets à jour pour les distributions non stables. Elle pourrait également aider ponctuellement l'équipe principale en fournissant des paquets prêts qui auraient juste à être testés (par l'équipe principale).

En fait, cette seconde équipe assurerait la coordination avec le responsable du paquet pour obtenir une correction rapide dans la distribution instable. Elle fournirait également un paquet pour la distribution de test (ou toute autre distribution que nous pourrions créer...) en rétroportant le correctif si nécessaire. Ces paquets corrigés pourraient être directement placés dans la distribution de test ou être simplement fournis sur security.debian.org/testing jusqu'à ce qu'un paquet corrigé se soit propagé dans la distribution de test.

Cette seconde équipe ferait plus ou moins ce qui existe déjà, mais qui n'est pas encore très efficace. Cela a besoin d'être étendu (deux personnes ne suffisent pas) et il faut travailler à mettre en place l'infrastructure nécessaire (nous n'avons pas encore de rbuilders pour toutes les architectures).


Vous savez tous que nous avons des problèmes graves avec la gestion des publications. Il ne faut pas jeter la pierre à Anthony Towns, il a réalisé beaucoup de travail jusqu'à présent, mais nous avons besoin d'aller plus loin. J'ai des propositions, mais elles ont toutes besoin d'être débattues et amendées. Cependant il n'est pas encore temps d'en discuter... C'est simplement pour vous faire savoir que j'ai l'intention de travailler à l'amélioration de la gestion des publications car la situation actuelle n'est pas acceptable sur le long terme. Tout cela est bien sûr pour la version qui suivra Woody, Anthony continuera à gérer la publication de Woody et je l'aiderai autant que nécessaire !

1.6 Séparation des paquets stables et instables

Nous avons plusieurs problèmes dans la situation actuelle :

C'est pourquoi je pense que nous avons besoin d'une distribution totalement séparée pour la prochaine version stable en cours de préparation et pour la version instable. C'est au responsable de décider quand son paquet est prêt être inclus dans la distribution en préparation.

Pour la suite de mon explication, j'appelle distribution de travail la distribution en cours de préparation vers laquelle le responsable décide de télécharger les paquets qu'il croit être pratiquement prêts à être inclus dans la distribution stable.

Les gens travaillent toujours dans la distribution instable, mais lorsque le paquet est prêt dans l'instable, il est téléchargé dans la distribution de travail ! tout paquet téléchargé dans cette distribution est compilé dedans.

Cela permettrait (par exemple) à Branden de télécharger XFree 4.2.0 dans la distribution instable tout en finalisant XFree 4.1 dans celle de travail. Ou, Gnome 2.0 pourrait facilement être préparé dans la distribution instable en gardant Gnome 1.4 dans celle de travail sans problème. Une fois qu'un paquet (ou qu'un ensemble de paquets) est prêt dans la distribution instable, nous pourrions avoir un script qui le pousserait dans celle de travail et tous les constructeurs automatiques (y compris ceux pour l'architecture i386) le prendraient et le construiraient. De cette façon nous éviterions certains téléchargements de sources non nécessaires et qui peuvent introduire des bogues.

L'une des conséquences est que nous devrions avoir des constructeurs automatiques aussi bien pour la distribution de travail que pour l'instable. Cela signifie que nous aurons besoin de plus de constructeurs automatiques et d'environnements fermés d'exécution pour les constructions... mais c'est une étape nécessaire pour faciliter le travail du responsable de publication : chaque responsable déciderait si ses paquets conviennent à la distribution stable. Une fois téléchargés dans la distribution de travail, le responsable de publication aurait bien sûr toujours la possibilité de contrôler ce qu'il accepte.

Et que se passe-t-il avec la distribution de test ? Bien, nous la conservons pratiquement telle qu'elle est, parce qu'elle est parfaite pour certains de nos utilisateurs avancés et qu'elle est un bon moyen de voir si un paquet est un bon candidat pour la version de travail ou non. Et nous introduisons la version publiable qui est le résultat des scripts de la distribution de test lancés sur celle de travail. Cette distribution publiable serait systématiquement basée sur les paquets de celle de travail. Ainsi, on ne serait pas loin d'obtenir une distribution prête à être publiée...

Gestion des publications

1.7 Publication et gels plus fréquents

Comme la distribution de travail n'est constituée que de paquets considérés comme bons par leurs responsables, le système de base et standard contenu dans cette distribution devrait toujours être presque prêt et pouvoir être gelé régulièrement (tous les huit mois) sans demander plus de quelques semaines de travail. À ce moment, nous aurions une période d'un ou deux mois après laquelle une nouvelle distribution stable pourrait être sortie (quoi qu'il arrive les paquets qui ne seraient pas prêts à temps seraient simplement abandonnés).

Cela ignore complètement les disquettes de démarrage car je suppose qu'elles doivent toujours être prêtes (si une nouvelle version n'est pas prête, alors l'ancienne devrait toujours être utilisable).


Pour finir, mais ce n'est pas de moindre importance, nous devons approfondir la maintenance collaborative des paquets. J'ai deux idées à l'esprit :

1.8 Extension du système de suivi des paquets

J'ai implanté (avec l'aide d'Anthony Towns pour les modifications du système de suivi des bogues) le système de suivi des paquets. Mais il pourrait être étendu par une interface sur la Toile ; chaque paquet source aurait sa propre page (avec une URL de la forme http://activity.debian.org/<paquet source>). Cette page aurait pour but d'être un portail pour le paquet source. Elle inclurait de nombreux liens (vers le système de suivi des bogues, les pages lintian, packages.debian.org) et des informations supplémentaires (comme celles fournies par madison sur auric). Elle contiendrait aussi un système de nouvelles où les gens pourraient ajouter des nouvelles simplement en envoyant une message à <paquet source>@activity.debian.org, nouvelles qui seraient disponibles directement sur la Toile. Voici le genre de nouvelles qui pourraient être intéressantes :

Le responsable pourrait également ajouter des informations statiques sur cette page, comme la façon de faire des mises à jour indépendantes, ou les autres ressources utiles disponibles pour ce paquet (système de gestion des bogues originel, canaux irc, listes de diffusion...).

Cette extension serait accessible rapidement à de nombreuses personnes et leurs permettrait de connaître les informations essentielles sur le paquet. Les travailleurs de l'assurance qualité pourraient vérifier ce qui se passe sur ce paquet, et lors des périodes de gel ce pourrait être un outil inestimable pour indiquer ce que les travailleurs de l'assurance qualité ont l'intention de faire sur ce paquet.

1.9 Dépôt CVS pour les répertoires debian/

Une autre étape naturelle lorsque plusieurs personnes travaillent sur le même paquet est de mettre les fichiers de debian/* sous contrôle de version. Nous devons fournir de l'espace disque sur notre serveur CVS pour cela. Nous avons besoin d'un outil pour créer automatiquement un tel dépôt (c'est-à-dire que chaque responsable pourrait demander un dépôt CVS pour ses propres paquets en appelant un programme sur le bon serveur). L'intégration avec les outils d'empaquetage devrait être étudiée et des outils d'aide fournis (pour mettre jour, envoyer, gérer les branches (stable, instable) et étiqueter les fichiers lorsqu'un paquet est téléchargé, etc.). cvs-buildpackage pourrait être utilisé pour cela.

En supposant que tous les développeurs Debian aient accès en écriture à tous ces dépôts CVS, les avantages seraient nombreux et le responsable principal aurait toujours le contrôle :

Bien sûr, ce service serait optionnel, les responsables ne seraient pas obligés de l'utiliser.


2. Communication

Pour commencer, notre communication interne doit être améliorée. Certaines choses utiles ne sont connues que par les responsables qui suivent soit debian-devel soit #debian-devel. Ce n'est pas vraiment acceptable. Les choses intéressantes pour tous les développeurs devraient être documentées (et annoncées sur debian-devel-announce).

2.1 Meilleures façons d'empaqueter pour Debian

La première fois que j'ai entendu parler de cela, c'était sur IRC  c'était une idée de Matthew Wilcox. Comme j'ai beaucoup aimé le principe de cette idée, je l'ai incluse dans mon programme.

Les meilleures façon d'empaqueter pour Debian sera un manuel référençant les meilleures de toutes les solutions disponibles pour entretenir un paquet : l'utilisation de DBS pour gérer plusieurs paquets originels, de DebConf pour l'interaction avec les utilisateurs, la manière de traiter des fichiers de configuration générés automatiquement, etc. Nous avons accumulé des années d'expérience que nous devons capitaliser.

2.2 Mise à jour de la référence du développeur Debian

La référence du développeur Debian est déjà une documentation inestimable pour les responsables, mais nous devons la garder à jour en fonction des ressources disponibles (documenter le système de suivi des paquets par exemple, et tous les autres projets achevés et mentionnés dans la première partie de mon programme).

De plus, elle devrait aussi fournir une liste des choses qu'un développeur peut (ou devrait) faire en plus de la maintenance de ses propres paquets (c'est-à-dire l'assurance qualité, le parrainage, la gestion des candidatures de nouveaux responsables, le travail sur l'installateur, la participation aux chasses aux bogues...).

D'autres traductions devraient également être disponibles.

2.3 Promotion de l'idée de collaboration pour la maintenance et de responsable de secours

L'idée de maintenance collaborative n'est pas très répandue au sein de Debian. Seuls quelques paquets sont gérés par une équipe entière. Cela doit changer. Nous devons expliquer l'utilité d'avoir plusieurs responsables pour chaque paquet. Nous devons documenter toutes les ressources disponibles pour la comaintenance (système de suivi des paquets, champ Uploaders, CVS...).

Pour les paquets plus petits, où plusieurs responsables ne sont pas vraiment nécessaires, il est toujours utile d'avoir un responsable de secours qui puisse aider ponctuellement comme lorsque le responsable est en vacances (ou lorsqu'il est très occupé). Et puisqu'ils suivraient le paquet, ils éviteraient que le paquet ne soient oublié... :-)

2.4 Création de plus de listes debian-devel-<langue>

J'ai créé debian-devel-french il y a quelques mois et il serait intéressant d'avoir plus de listes dédiées comme celle-ci (nous avons également debian-devel-spanish) pour les principales langues (je n'ai pas de critère pour définir ces langues principales). De telles listes sont utiles car les responsables qui ne suivent pas debian-devel pourrait suivre sa contrepartie régionale qui a généralement bien moins de trafic. Si de bonnes idées apparaissent sur les listes régionales, elles pourront toujours être renvoyées par un responsable suivant les deux listes. Le contraire peut aussi arriver : il pourrait aussi être débattu sur les listes régionales de quelque chose venant de debian-devel. La liste servirait également les objectifs de debian-mentor mais dans la langue maternelle (il est bien plus facile de trouver un parrain dans ce contexte).


Malgré l'ouverture de Debian, nous n'essayons pas trop de communiquer avec les personnes hors de Debian : nous les laissons simplement trouver par elles-mêmes ce qu'elles souhaitent savoir sur le site. Nous devrions être plus actifs, nous devons essayer de leur dire ce que nous souhaitons qu'elles sachent.

2.5 Publicité des offres et des besoins de Debian vers les acteurs du logiciel libre

Nous avons certainement beaucoup de choses à dire à tout le monde. Cependant nous devons adapter notre message à chaque population. Ce que nous devons dire à chacune d'entre elles est ce que Debian peut lui apporter et ce que Debian a besoin qu'elle lui fournisse. Voici la liste des personnes concernées et des exemples de messages (la liste n'est pas exhaustive et peut être allongée bien sûr) :

2.6 Contact avec les développeurs originels

J'ai le sentiment que trop peu de responsables ont de réels contacts avec les auteurs originels. Cela devrait changer, nous devrions avoir de meilleurs contacts avec eux et nous devrions même essayer de recruter les développeurs originels qui utilisent déjà Debian. Nous devrions les informer de la manière de nous aider (sans forcément devenir développeur Debian) en souscrivant au système de suivi des paquets et en prenant en compte les rapports de bogues qui leur sont renvoyés.

Mieux un auteur originel connaît Debian, meilleure devrait être la coopération. C'est pourquoi je souhaiterais que nous écrivions une sorte de lettre ouverte aux auteurs de logiciels libres (qui pourrait être inspirée des pages décrites au point précédent), lettre que chaque responsable devrait renvoyer aux développeurs originels de ses paquets.

2.7 Promotion de Debian dans l'entreprise

Bien que Debian ne soit pas une distribution commerciale, elle est destinée être utilisée partout y compris dans des environnements d'entreprises et commerciaux. Le développement de Debian dans ce domaine devrait être encouragé car plus les entreprises connaissent Debian, plus nous pouvons recevoir de dons, et plus les développeurs peuvent être rémunérés pour leur travail sur Debian.

La chose la plus simple que nous pouvons faire pour cela est de donner la possibilité aux utilisateurs de Debian de publier où et comment Debian est utilisée dans le monde des entreprises (Mandrake fait quelque chose qui y ressemble à MandrakeBizCases).

Ce site pourrait également fournir des liens vers les pages qui pourraient intéresser les entreprises cherchant une utilisation d'entreprise de Debian. Je pense aux pages des conseillers ou à la listes des marchands qui vendent du matériel avec Debian préinstallée.

2.8 Reconnaissance et coopération avec les distributions basées sur Debian

Toutes les distributions qui sont basées sur Debian aident Debian en répandant le format de paquets de Debian et en fournissant d'autres manières (parfois plus simples) d'installer Debian. Nous devons en être fiers car elles réutilisent toujours beaucoup de choses de Debian. Elles ne créent pas de branches juste par plaisir, elles ajoutent de la valeur à Debian. Et la plupart du temps, elles y contribuent en retour.

C'est pourquoi je pense que nous devrions avoir une page reconnaissant leur existence (il existe déjà quelque chose mais cela a besoin d'être amélioré et d'être rendu plus visible). Je pense également que nous devrions renforcer nos relations avec elles, simplement pour nous assurer que leurs parties les plus intéressantes rentrent dans Debian.


Je pense que c'est suffisant, une année ne fait que 365 jours. :-) Si travailler à l'un de ces projets vous intéresse, faites-le moi savoir. Bien sûr, il y a beaucoup d'autres projets qui valent la peine d'être menés (un installateur plus simple basé sur l'installateur Debian, la détection du matériel...) et j'espère que nous les atteindrons mais le responsable du projet Debian n'en a pas particulièrement la charge.

Conclusion

Je vous remercie de votre attention. Cette année à venir sera très intéressante et difficile pour le prochain responsable du projet  il aura besoin de votre appui. C'est pourquoi j'espère que vous voterez tous lors des prochaines élections. Jusque-là, amusez-vous bien !


Raphaël Hertzog.


Réfutation

Sur le programme de Bdale

Je n'ai pas grand chose à dire sur le programme de Bdale car je suis d'accord avec la plupart de ce qu'il dit. Je peux simplement reconnaître son expérience au sein de Debian et le travail inestimable qu'il a déjà réalisé. Je partage sa vision de Debian  cependant je pense que son programme manque de propositions concrètes. C'est parfaitement compréhensible car vous pouvez savoir où vous souhaitez aller sans savoir comment y aller. S'il est élu, j'espère qu'il verra que certains des projets que je propose vont dans la direction vers laquelle il veut nous emmener et que donc qu'il en fera suffisamment la promotion pour les rendre possibles.

Il a mentionné qu'il assisterait à de nombreux événements grâce à son nouveau travail aux laboratoires Linux de HP ; en tant que tel je serais très heureux s'il souhaitait être l'un des représentants du responsable du projet Debian.

Bdale obtiendra certainement*1 mon soutien pour tout projet concret qu'il souhaitera lancer et lié à l'un des points qu'il a cités dans son programme (qualité, prévision des publications, première impression des utilisateurs, infrastructure, sécurité, base standard de Linux).

[*1] Bien, je ne peux pas le garantir car je ne sais pas ce que ces projets seront... mais je dis cela car je sais que Bdale est très raisonnable et a toujours fait du bon travail. Prenez cela comme une reconnaissance.

Sur le programme de Branden

Branden est *quelqu'un* au sein de Debian, personne ne lui est indifférent. Tous le monde peut se rappeler comment il nous a gentiment chacun descendu en flamme. Je suis habitué à la manière de faire de Branden ; je souhaite que chacun le soit, au moins ne sera-t-il pas blessé en discutant avec lui. :-) Je dois admettre que j'apprécie l'effort de Branden pour être plus compréhensif et ne descendre en flamme qu'en dernier ressort. Continue comme cela ! ;-)

Il a toujours fait du bon travail avec XFree86 et il a prouvé sa capacité gérer d'autres problèmes non techniques (le trésorier de SPI me vient l'esprit mais je pense également aux diverses propositions qu'il a faites pour modifier la constitution ou la charte d'utilisation des machines Debian, et aussi plusieurs choses qu'il a gérées sur debian-private et que je ne peux pas citer ici :-)).

Voici mes commentaires sur son programme. Bien que je comprenne ses motivations à définir clairement le rôle du responsable du projet Debian et de ses délégués, je pense vraiment que ce n'est pas nécessaire pour Debian et que c'est juste une sorte de bureaucratie dont nous n'avons pas besoin. Les équipes sont connues, les gens savent qui en fait partie, et la manière de les contacter est documentée. Nous n'avons pas besoin de plus. Je partage totalement les deux points de son programme « conserver la base des développeurs active » et « représenter Debian lors de cérémonies ». Les points « relations de Debian avec SPI » et « réactivation du comité technique de Debian » ne m'intéressent pas tellement mais sont bons et valent la peine d'être poursuivis, et je serais donc heureux de permettre à Branden de les gérer en tant que délégué du responsable du projet Debian.

Sur mon programme

À ce point, je ne veux pas modifier quoi que ce soit dans mon programme (sauf quelques erreurs d'orthographe :-)) : je crois que les clarifications nécessaires ont déjà été faites sur debian-vote.

La plus grande préoccupation a été à propos de « SourceForge ». Nous ne l'appellerons pas « SourceForge » pour qu'il soit clair que ce n'est pas affilié à VA Research. Mais nous utiliserons le code de sourceforge car il est empaqueté et fonctionne bien. Cependant si quelqu'un apporte un autre logiciel libre qui fonctionne avec autant de fonctionnalités, nous l'étudierons bien évidemment.