[rfr] wml://www.debian.org/vote/2002/raphael.wml
--
#use wml::debian::template title="Programme de Raphaël Hertzog" BARETITLE="true"
#use wml::debian::translation-check translation="1.15" maintainer="Nicolas Bertolissio"
<h2>Présentation</h2>
<p>
Je m'appelle Raphaël Hertzog. On me surnomme <i>buxy</i> sur IRC. Je suis
Français, j'ai 23 ans et je suis étudiant à l'<a
href="http://www.insa-lyon.fr";>INSA de Lyon</a>. Je fais partie du <a
href="http://www.if.insa-lyon.fr/if/";>département informatique</a>.
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).
</p>
<h2>Mon histoire dans Debian</h2>
<p>
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.
</p>
<p>
En&bvsp;1998, j'ai rejoint Debian en tant que développeur et j'ai commencé avec
un unique paquet nommé « <a href="http://packages.debian.org/sympa";>\
sympa</a> ». 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.
</p>
<p>
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é <a href="http://packages.debian.org/dpkg-ftp";>\
dpkg-ftp</a> (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 les
souhaits.
</p>
<p>
En 1999, l'équipe debian-cd a rencontré un problème car leur script
n'était pas vraiment conçu pour gérer plusieurs cédéroms et Slink était la
première version de Debian qui avait besoin de plus d'un seul cédérom. C'est la
raison pour laquelle j'ai écrit YACS, <i>Yet Another Cd Script</i> encore un
autre script de cédérom (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 cédéroms et des cédéroms personnalisés (vous pouviez
facilement personnaliser le contenu des cédéroms). Je suis toujours le
responsable de debian-cd.
</p>
<p>
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 <a
href="http://lists.debian.org/debian-devel/1999/debian-devel-199907/msg01530.html";>\
mécanisme de parrainage</a>. 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
outils 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).
</p>
<p>
Toujours en 1999, je ne me rappelais pas avoir tant fait au cours de la
même années&nbsb;! :-), 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 <a
href="$(HOME)/doc/packaging-manuals/perl-policy/">charte sur Perl</a>.
</p>
<p>
Après cela, j'ai travaillé à la résurrection de l'assurance qualité de Debian.
J'ai lancé <a href="http://qa.debian.org";>qa.debian.org</a>, 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 faisait 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.
</p>
<p>
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 que n'arrive les problèmes (paquets mal entretenus, paquets oubliés
mais non orphelins...) C'est pourquoi j'ai lancé le <a
href="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200201/msg00011.html";>\
système de suivi des paquets</a> 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
avoir 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).
</p>
<p>
En 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.
</p>
<p>
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...).
</p>
<h2>Le rôle du responsable du projet</h2>
<p>
À mon avis, les principales tâches du responsable est l'organisation et la
communication.
</p>
<p>
La partie d'organisation concerne le travail interne de Debian, il doit
s'assurer que les infrastructures de Debian sont adaptées au travail de Debian.
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 <a
href="#projects">programme</a>.
</p>
<p>
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.
</p>
<p>
Quoi qu'il en soit, il n'est pas toujours possible d'aller partout où vous êtes
invités et donc je réfléchis à la possibilité de désigner des représentants
locaux du responsable (volontaires bien sûr).
</p>
<p>
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...
</p>
<h1 align="center"><a name="projects">Projets pour Debian</a></h1>
<p>
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.
</p>
<p>
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 :
</p>
<ul>
<li><a href="#organisation">1. Organisation</a>
<ul>
<li><a href="#sf">1.1 Sourceforge pour les développeurs Debian</a></li>
<li><a href="#ping">1.2 Vérification des responsables actifs</a></li>
<li><a href="#adoption">1.3 Recrutement de gens pour adopter des
paquets</a></li>
<li><a href="#l10n">1.4 Infrastructure de traduction</a></li>
<li><a href="#security">1.5 Seconde équipe de sécurité</a></li>
<li><a href="#release1">1.6 Séparation des paquets stables et
instables</a></li>
<li><a href="#release2">1.7 Publications et gels plus fréquents</a></li>
<li><a href="#pts">1.8 Extension du système de suivi des paquets</a></li>
<li><a href="#cvs">1.9 Dépôt CVS pour les répertoires debian/</a></li>
</ul>
</li>
<li><a href="#communication">2. Communication</a> (interne et externe)
<ul>
<li><a href="#dbpp">2.1 Meilleures façons d'empaqueter pour
Debian</a></li>
<li><a href="#ddr">2.2 Mise à jour de la référence du développeur
Debian</a></li>
<li><a href="#backup">2.3 Promotion de l'idée de collaboration pour la
maintenance et de responsable de secours</a></li>
<li><a href="#dd-local">2.4 Création de plus de listes
debian-devel-<langue></a></li>
<li><a href="#message">2.5 Publicité des offres et des besoins de Debian
vers les acteurs du logiciel libre</a></li>
<li><a href="#upstream">2.6 Contact avec les développeurs
originels</a></li>
<li><a href="#bizcases">2.7 Promotion de Debian dans
l'entreprise</a></li>
<li><a href="#otherdistro">2.8 Reconnaissance et coopération avec les
distributions basées sur Debian</a></li>
</ul>
</li>
</ul>
<hr width="100%" align="center" />
<h2><a name="organisation">1. Organisation</a></h2>
<h3><a name="sf">1.1 Sourceforge pour les développeurs Debian</a></h3>
<p>
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 :
</p>
<ul>
<li>les listes de diffusion et les services CVS traditionnels fournis par
Debian ne sont utilisés que pour des projets d'intérêt général pour Debian.
Les développeurs ne peuvent pas demander une liste de diffusion ou un dépôt
CVS pour un projet non directement lié à Debian (en particulier s'il ne
concerne qu'un petit nombre de personnes). Les outils sourceforge
permettraient à chaque développeur d'avoir une liste de diffusion ou un
dépôt CVS (ainsi que tous les services sourceforge) pour leurs
projets ;</li>
<li>tous les projets hébergés sur sourceforge.debian.org seraient identifiés
comme venant de la communauté Debian et cela nous rendrait plus visible
comme part active de la communauté du logiciel libre ;</li>
<li>sourceforge est un bon moyen de lancer des projets que nous souhaitons
étendre au-delà de Debian. Par exemple le système de menus, il a été
initialement développé par Debian, mais il n'est pas vraiment spécifique à
Debian (Mandrake l'utilise aussi) mais si nous avions été quelque part où
des personnes hors de Debian auraient pu apporter leur aide facilement,
peut-être serait-il utilisé par bien plus de gens maintenant ;<li>
<li>sourceforge peut être un bon outil pour permettre à des non développeurs
de travailler sur certaines parties de Debian. Je pense à la documentation
et aux nombreux traducteurs.</li>
</ul>
<p>
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.
</p>
<hr width="75%" align="center" />
<cite>
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'ai 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 :
</cite>
<h3><a name="ping">1.2 Vérification des responsables actifs</a></h3>
<p>
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éponses ou autre). Il est temps que nous contactions effectivement les
responsables qui, soit ont des paquets en mauvais état, soit ont disparus (en
fonction des informations dont nous disposons) :
</p>
<ul>
<li>nous pouvons détecter les responsables disparus et rendre leurs paquets
orphelins ;</li>
<li>nous pouvons informer les responsables de l'état de leurs paquets et leur
faire prendre conscience qu'ils devraient trouver de l'aide ou rendre leurs
paquets orphelins s'ils sont en mauvais état ;</li>
<li>les responsables qui ont oublié qu'ils étaient développeurs Debian
pourraient souhaiter prendre leur retraite (je préférerais qu'ils
reviennent travailler, mais s'ils ne prévoient pas de revenir vers Debian,
alors ils devraient prendre leur retraite afin de réduire le risque de
piratage de leur clef).</li>
</ul>
<h3><a name="adoption">1.3 Recrutement de gens pour adopter des paquets</a></h3>
<p>
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).
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
Tout ce travail pourrait être coordonné <i>via</i> 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).
</p>
<hr width="75%" align="center" />
<cite>
É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...
</cite>
<h3><a name="l10n">1.4 Infrastructure de traduction</a></h3>
<p>
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 :
</p>
<ul>
<li>nous devons traduire (et garder à jour au moins les questionnaires
DebConf, les descriptions de paquets et les programmes spécifiques à Debian
(messages et documentation). Aller plus loin impliquerait des coordinations
avec les gens qui travaillent sur les logiciels libres hors de
Debian ; ce serait intéressant, mais nous devrions d'abord nous
concentrer sur ce qui est lié directement à Debian ;</li>
<li>nous avons besoin d'une manière efficace pour distribuer le travail de
traduction. Pour cela, je pense que le DDTP représente un grand
pas ;</li>
<li>nous devons nous assurer que les traductions qui sont envoyées au système
de suivi des bogues sont effectivement incluses. Trop nombreuses sont
celles qui dorment dans le système de suivi des bogues même lorsqu'il est
très facile de les inclure.</li>
</ul>
<p>
Vous pouvez également regarder les <a href="$(HOME)/intl/l10n/">statistiques de
traduction de Debian</a> 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).
</p>
<hr width="75%" align="center" />
<cite>
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.
</cite>
<h3><a name="security">1.5 Seconde équipe de sécurité</a></h3>
<p>
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).
</p>
<p>
En fait, cette seconde équipe coordonnerait 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.
</p>
<p>
Cette seconde équipe ferait plus ou moins ce qui <a
href="http://lists.debian.org/debian-security/2001/debian-security-200109/msg00225.html";>\
existe déjà</a>, 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).
</p>
<hr width="75%" align="center" />
<cite>
Vous savez tous que nous avons des problèmes graves avec la gestion des
publication. 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 !
</cite>
<h3><a name="release1">1.6 Séparation des paquets stables et instables</a></h3>
<p>
Nous avons plusieurs problèmes dans la situation actuelle :
</p>
<ul>
<li>la distribution de test est dérivée de l'instable qui reçoit
systématiquement les nouvelles versions de tous les paquets (et les
nouveaux bogues en même temps) ;</li>
<li>lorsque nous fournissons un paquet mis à jour pour la distribution de
test, nous devons retraverser l'instable. Cela signifie qu'un paquet
devrait être recompilé avec les versions précédentes des bibliothèques
(celles qui n'étaient pas encore disponibles lorsque la version précédente
du paquet avait été téléchargée) ce qui pourrait le maintenir dans la
distribution instable (parce que les bibliothèques pourraient avoir des
problèmes ou d'autres conflits) ;</li>
<li>lorsque nous travaillons sur les paquets instables, nous ne pouvons pas
les garder dans la distribution instable sans remplir de bogue critique
pour la publication de la prochaine version de la distribution. Je pense
aux paquets préparatoires à la publication de Gnome 2. Ils ne doivent
jamais apparaître dans la distribution de test qui deviendra notre
prochaine version stable. La même chose s'applique à XFree 4.2,
Branden ne va pas la télécharger dans la distribution instable car cela
signifierait qu'il ne pourrait plus fournir de mises à jour de
XFree 4.1 pour la distribution de test...</li>
</ul>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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&nsbp;:
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.
</p>
<p>
Et que ce 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...
</p>
<p align="center">
<img src="http://people.debian.org/~hertzog/release-management.png";
alt="Gestion des publications" width="465" height="251">
</p>
<h3><a name="release2">1.7 Publication et gels plus fréquents</a></h3>
<p>
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).
</p>
<p>
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).
</p>
<hr width="75%" align="center" />
<cite>
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 :
</cite>
<h3><a name="pts">1.8 Extension du système de suivi des paquets</a></h3>
<p>
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 :
</p>
<ul>
<li>disponibilité d'une nouvelle version bêta du paquet pour des
tests ;</li>
<li>prévision de la date de sortie du paquet (pour permettre aux traducteurs
de mettre à jour leurs traductions par exemple) ;</li>
<li>reconstruction du paquet en cours&nsbp;;</li>
<li>manière de corriger une version bloquée ;</li>
<li>travail sur une mise à jour indépendante ;</li>
<li>vacance du responsable (si le responsable souhaite publier cette
information... elle serait bien sûr facultative) ;</li>
<li>disponibilité d'une nouvelle version originelle et prévision
d'empaquetage ;</li>
<li>chasse aux bogues sur ce paquet.</li>
</ul>
<p>
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...).
</p>
<p>
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.
</p>
<h3><a name="cvs">1.9 Dépôt CVS pour les répertoires debian/</a></h3>
<p>
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.
</p>
<p>
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 :
</p>
<ul>
<li>l'équipe de traduction pourrait envoyer directement les traductions sans
que cela ne demande de travail au responsable ;</li>
<li>les personnes faisant des mises à jour indépendantes n'auraient plus
besoin d'envoyer de correctifs au système de suivi des bogues. Les
correctifs seraient appliqués directement dans le CVS ; le responsable
pourrait les annuler ou les conserver ;</li>
<li>il serait bien plus facile d'avoir des coresponsables, le responsable
n'aurait pas besoin de centraliser les correctifs. Il aurait juste besoin
de mettre à jour son dépôt local de temps en temps ;</li>
<li>nous pourrions facilement maintenir deux versions des paquets (stable et
instable par exemple) en utilisant les branches CVS ;</li>
<li>les responsables pourraient recevoir un courriel pour chaque
enregistrement avec le correctif et le journal. Avec un tel système, ils
pourraient voir qui a fait quoi, et détecter des erreurs potentielles.</li>
</ul>
<p>
Bien sûr, ce service serait optionnel, les responsables ne seraient pas obligés
de l'utiliser.
</p>
<!-- ##### -->
<hr width="100%" align="center" />
<h2><a name="communication">2. Communication</a></h2>
<p>
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).
</p>
<h3><a name="dbpp">2.1 Meilleures façons d'empaqueter pour Debian</a></h3>
<p>
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.
</p>
<p>
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.
</p>
<h3><a name="ddr">2.2 Mise à jour de la référence du développeur Debian</a></h3>
<p>
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).
</p>
<p>
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...).
</p>
<p>
D'autres traductions devraient également être disponibles.
</p>
<h3><a name="backup">2.3 Promotion de l'idée de collaboration pour la maintenance et de responsable de secours</a></h3>
<p>
L'idée de maintenance collaborative n'est par 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...).
</p>
<p>
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é... :-)
</p>
<h3><a name="dd-local">2.4 Création de plus de listes debian-devel-<langue></a></h3>
<p>
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).
</p>
<hr width="75%" align="center" />
<cite>
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.
</cite>
<h3><a name="message">2.5 Publicité des offres et des besoins de Debian vers les acteurs du logiciel libre</a></h3>
<p>
Nous avons certainement beaucoup de choses à dire à tout le monde. Cependant
nous devons adapter notre message à chaque population. Ce que nous devons leur
dire exactement est ce que Debian peut leur apporter et ce dont Debian à 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) :
</p>
<ul>
<li>à un utilisateur moyen :
<ul>
<li>comment obtenir Debian (les vendeurs de cédéroms) et les
distributions dérivées,</li>
<li>où trouver de l'aide sur Debian (par la communauté ou en
payant),</li>
<li>comment faire des dons (d'argent ou de matériel) à Debian ;</li>
</ul></li>
<li>à un contributeur (un utilisateur avancé) :
<ul>
<li>comment suivre le développement de Debian (tests, listes de
diffusion, système de suivi des paquets...),</li>
<li>comment rapporter des bogues et comment les suivre,</li>
<li>comment aider sans être développeur (traductions, correctifs,
retours, assurance qualité en général...) ;</li>
<li>comment devenir développeur pour s'investir plus ;</li>
</ul></li>
<li>à un groupe d'utilisateurs Linux :
<ul>
<li>où trouver le nécessaire pour des fêtes d'installation, des
démonstrations, des expositions (affiches, documentation, logos, images
de fond, explications sur les avantages de Debian...),</li>
<li>comment aider les débutants qui découvrent Debian à travers leur
liste de diffusion locale,</li>
<li>comment ouvrir des services aux utilisateurs Debian (miroir local,
vente de cédéroms de Debian...) ;</li>
</ul></li>
<li>à un auteur de logiciel libre :
<ul>
<li>comment demander que quelqu'un empaquette son logiciel (RFP dans
wnpp),</li>
<li>comment suivre le paquet dans Debian (systèmes de suivi des paquets
et des bogues),</li>
<li>comment aider le responsable et quelle est la coopération
attendue,</li>
<li>comment devenir développeur pour entretenir le paquet
lui-même ;</li>
</ul></li>
<li>à une entreprise commerciale :
<ul>
<li>comment obtenir de l'aide payante pour Debian,</li>
<li>comment faire connaître publiquement leur utilisation de Debian
(« fonctionne avec Debian »),</li>
<li>comment faire un don à Debian (d'argent ou de matériel),</li>
<li>comment embaucher des développeurs Debian pour leur support interne
et leur permettre de travailler à temps partiel pour Debian.</li>
</ul></li>
</ul>
<h3><a name="upstream">2.6 Contact avec les développeurs originels</a></h3>
<p>
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.
</p>
<p>
Mieux un auteur originel connaît Debian, meilleures 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.
</p>
<h3><a name="bizcases">2.7 Promotion de Debian dans l'entreprise</a></h3>
<p>
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.
</p>
<p>
La chose la plus simple que nous pouvons faire pour cela est de donner la
possibilité aux utilisateurs de Debian de publier les endroits où et comment
Debian est utilisée dans le monde des entreprises (Mandrake fait quelque chose
qui y ressemble à <a href="http://www.mandrakebizcases.com";>\
MandrakeBizCases</a>).
</p>
<p>
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 <a href="$(HOME)/consultants/">pages des conseillers</a> ou à la
listes des marchands qui vendent du <a href="$(HOME)/distrib/pre-installed">\
matériel avec Debian préinstallée</a>.
</p>
<h3><a name="otherdistro">2.8 Reconnaissance et coopération avec les distributions basées sur Debian</a></h3>
<p>
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.
</p>
<p>
C'est pourquoi je pense que nous devrions avoir une page reconnaissant leur
existence (il <a href="$(HOME)/misc/related_links">existe déjà quelque
chose</a> 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.
</p>
<hr width="75%" align="center" />
<cite>
Je pense que c'est suffisant, une années 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.
</cite>
<h2>Conclusion</h2>
<p>
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 !
</p>
<hr />
<p>
<b><a href="mailto:hertzog@debian.org";>Raphaël Hertzog</a></b>.
</p>
<hr />
<h1>Réfutation</h1>
<h2>Sur le programme de Bdale</h2>
<p>
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 il les promeuvent
suffisamment pour les rendre possibles.
</p>
<p>
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.
</p>
<p>
Bdale obtiendra certainement<sup>*1</sup> mon soutien pour tout projet concret
qu'il souhaitera lancer et lié à l'un des points qu'il a cité dans son
programme (qualité, prévision des publications, première impression des
utilisateurs, infrastructure, sécurité, base standard de Linux).
</p>
<p>
[*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.
</p>
<h2>Sur le programme de Branden</h2>
<p>
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 ! ;-)
</p>
<p>
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 :-)).
</p>
<p>
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.
</p>
<h2>Sur mon programme</h2>
<p>
À 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.
</p>
<p>
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.
</p>
Reply to: