Le 14/03/2013 17:08, Baptiste a écrit : > Voici quelques suggestions. Merci à toi et à Stéphane. > J'ai aussi remarqué que tu utilise parfois « chef de > projet » et d'autres fois « chef du projet ». Je n'y ai pas touché, mais peut être > faut il homogénéiser. Les deux sont déjà utilisées sur le site (dans des proportions semblables si je me souviens bien), alors je préfère éviter la monotonie et les répétitions. Par avance merci pour vos autres relectures. Il n’est pas encore officiellement en ligne, mais est sur mon serveur de test : http://www.tilapin.org/debian/vote/2013/platforms/lucas Amicalement David
#use wml::debian::template title="Programme de Lucas Nussbaum" BARETITLE="true" NOHEADER="true"
#include "$(ENGLISHDIR)/vote/style.inc"
#use wml::debian::translation-check translation="1.3" maintainer="David Prévot"
<table class="title">
<tr>
<td>
<h1 class="titlemain">Programme de chef du projet Debian</h1>
<h3 class="titlerest">Lucas Nussbaum</h3>
</td>
</tr>
</table>
<h2 class="section">Qui suis-je, contributions précédentes à Debian</h2>
<p>
Français, 31 ans, utilisateur de logiciel libre depuis 1997, <a
href="http://fr.wikipedia.org/wiki/Ma%C3%AEtre_de_conf%C3%A9rences_%28France%29";>\
Maître de conférences</a> en informatique à l'<a
href="http://www.univ-lorraine.fr/";>Université de Lorraine</a>
où j'ai l'opportunité d'enseigner le logiciel libre et Debian
dans le contexte d'un cursus d'administration système.
</p>
<p>
J'ai commencé à contribuer à Debian en 2005.
Mes principales contributions sont les suivantes.
</p>
<dl class="description">
<dt class="dt-description"><b>Ruby</b></dt>
<dd class="dd-description">
Je me suis impliqué dans Debian en maintenant des paquets au sein de
l'équipe <a href="http://wiki.debian.org/Teams/Ruby";>pkg-ruby-extras</a>.
Je comaintiens les paquets de l'interpréteur et ai initialisé notre
nouvel assistant d'empaquetage, gem2deb (= dh-make-ruby + dh_ruby),
qui facilite énormément l'empaquetage de logiciels Ruby et a
amélioré significativement nos relations avec la communauté amont.
</dd>
<dt class="dt-description"><b>Collaboration avec Ubuntu</b></dt>
<dd class="dd-description">
J'ai travaillé à l'amélioration des moyens de gérer les divergences entre
Debian et Ubuntu, et pour faire revenir les améliorations d'Ubuntu dans Debian.
J'ai beaucoup contribué à détendre les relations
entre Debian et Ubuntu les premières années, aux <a
href="https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000182.html";>\
pratiques comme l'énumération des modifications d'Ubuntu dans les entrées
du journal de modifications d'Ubuntu</a>, et ajouté des façons d'obtenir
des renseignements à propos des paquets dans Ubuntu avec la <i>boîte
Ubuntu</i> sur le <a href="http://packages.qa.debian.org/d/dpkg.html";>\
système de suivi de paquets</a> et la colonne Ubuntu dans le <a
href="http://qa.debian.org/developer.php?login=lucas%40debian.org&comaint=yes";>\
DDPO</a> (plus de renseignements sur les <a
href="http://www.loria.fr/~lnussbau/files/fosdem2010-debian-ubuntu.pdf";>\
diapositives d'une présentation au FOSDEM 2010</a>).
</dd>
<dt class="dt-description"><b>Reconstructions de l'archive</b></dt>
<dd class="dd-description">
J'ai reconstruit tous les paquets de Debian de façon régulière depuis 2006.
Par conséquent, j'ai soumis 7000 bogues critiques <q>FTBFS</q>.
Effectivement, ça m'a donné un peu mauvaise conscience, mais
j'essaye de le voir comme une détection de problème a priori,
pas seulement comme une cause de retard des publications.
La même infrastructure est aussi utilisée pour tester les migrations
majeures ou les modifications de chaîne de compilation impliquant GCC, <a
href="http://clang.debian.net/";>Clang</a> et Python (plus de renseignements
sur les <a href="http://www.loria.fr/~lnussbau/files/fosdem07-auttest.pdf";>\
diapositives d'une présentation au FOSDEM 2007</a> et
l'<a href="http://www.lucas-nussbaum.net/blog/?p=718";>\
article sur la récente migration vers AWS</a>).
</dd>
<dt class="dt-description"><b>Base de données ultime Debian (UDD)</b></dt>
<dd class="dd-description">
Les services Debian (dak, wanna-build, BTS, DEHS, popcon, lintian, etc.)
sont très hétérogènes en termes de technologies et d'interfaces.
L'effet positif est que tout le monde peut très facilement développer
un nouveau service et l'intégrer dans notre infrastructure existante.
L'effet négatif est la grande difficulté pour combiner les données.
La <a href="http://udd.debian.org/";>base de données ultime Debian</a>
résout cela en important toutes les données pertinentes de Debian
(et des distributions dérivées) dans une seule base de données SQL.
Plusieurs services ont été développés sur UDD (y compris <a
href="http://udd.debian.org/bugs.cgi";>bugs.cgi</a> et le <a
href="http://udd.debian.org/dmd.cgi";>tableau de bord du responsable Debian</a>)
et bien d'autres utilisent UDD comme sources de données (plus de renseignements
en <a href="http://www.loria.fr/~lnussbau/files/msr2010-udd.pdf";>exposé</a>
et <a href="http://www.loria.fr/~lnussbau/files/msr2010-udd-slides.pdf";>\
diapositives</a> au MSRÂ 2010, et dans une <a
href="http://www.loria.fr/~lnussbau/files/debconf9-ultimate-debian-database.pdf";>\
présentation à DebConf9</a>).
</dd>
<dt class="dt-description"><b>Introduction à l'empaquetage Debian</b></dt>
<dd class="dd-description">
J'ai écrit une <a href="$(HOME)/doc/devel-manuals#packaging-tutorial">\
introduction à l'empaquetage Debian</a> (paquet <a
href="http://packages.debian.org/sid/packaging-tutorial";>\
<tt>packaging-tutorial</tt></a>) pour fournir une
documentation plus accessible aux futurs mainteneurs.
Je l'ai utilisé parfois pour enseigner l'empaquetage Debian
et elle a été traduite en allemand, français et espagnol.
C'est aussi un bon moyen de promouvoir les bonnes pratiques, comme
l'empaquetage avec <i>dh</i> (diapositive 26) ou les premiers pas pour
s'impliquer dans Debian (s'impliquer dans des équipes, adopter des
paquets existants, mais pas empaqueter plus de logiciels inutiles quand
de meilleurs alternatives existent déjà dans Debian, diapositive 42).
</dd>
<dt class="dt-description"><b>Autres</b></dt>
<dd class="dd-description">
Je participe marginalement à l'équipe Debian Science.
J'ai été intercesseur dans le processus de nouveaux membres.
J'ai parfois aussi résumé de longs fils sur debian-devel@ (par exemple à propos
de <a href="http://lists.debian.org/debian-devel/2011/05/msg00111.html";>\
rolling</a> et de la procédure permettant de <a
href="http://lists.debian.org/debian-devel/2012/10/msg00469.html";>\
rendre un paquet non maintenu orphelin</a>).
</dd>
</dl>
<p>
En général, la plupart de mes contributions à Debian ont pour but de
s'occuper de problèmes à l'échelle de la distribution (assurance qualité,
traitement de données) et à l'amélioration de la collaboration et la
communication (avec les nouveaux contributeurs et les distributions dérivées).
</p>
<h2 class="section">Ã?tat de Debian, vision et objectifs</h2>
<h3 class="subsection">Ã?tat du projet</h3>
<p>
Le projet Debian est en très bon état interne.
Bien sûr, les améliorations sont toujours possibles, et les
coins sombres existent, mais toutes nos équipes principales sont
raisonnablement fonctionnelles, notre infrastructure est en bon
état général, et aucune grosse crise Debian n'est prévisible.
Stefano Zacchiroli a joué un rôle important pour arriver dans cet état,
et nous devrions tous lui en être particulièrement reconnaissant.
</p>
<p>
Cependant, j'ai souvent l'impression que le projet
perd de l'élan, de l'énergie positive, et ralentit.
Cela se passe comme si nous vivions sur les acquis du passé.
Beaucoup de choses très sympathiques se passent dans
l'écosystème Debian, mais souvent en marge du projet Debian.
C'est bien d'être une base solide pour de nombreuses distributions
dérivées innovantes, mais devons-nous nous contenter du rôle de
<a href="http://joeyh.name/blog/entry/the_supermarket_thing/";>\
supermarché de paquets</a> ?
</p>
<h3 class="subsection">� quoi Debian devrait ressembler dans cinq ans ?</h3>
<p>
Debian devrait viser au <b>renforcement de sa position
au centre de l'écosystème du logiciel libre</b>.
Elle devrait être le <b>principal intermédiaire actif
entre les projets amonts et les utilisateurs finaux</b>.
Bien sûr, fournir une bonne base aux dérivées est important,
parce que les utilisateurs des dérivées sont des utilisateurs de
Debian, même si certains d'entre eux ne le reconnaissent pas.
Nous devrions viser aussi au <b>renforcement de la visibilité
et de l'impact de Debian elle-même, parce que les valeurs
extrêmement importantes pour lesquelles nous nous battons en
tant que projet sont souvent négligées par nos dérivées</b>.
</p>
<p>
Oui, cela signifie travailler à faire revenir certains des trucs sympathiques
faits par les dérivées dans Debian et créer plus de <i>produits</i> Debian.
Par exemple, nous avons fourni une version rolling plutôt bonne depuis
<a href="http://lists.debian.org/debian-devel/2000/08/msg00906.html";>\
près de treize ans</a> avec <i>testing</i>, mais nous avons
totalement échoué à le présenter comme quelque chose de
pris en charge et d'utilisable par les utilisateurs finaux.
Maintenant qu'Ubuntu envisage de <a
href="https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036537.html";>\
basculer vers un cycle de vie de deux ans avec en plus une version
rolling</a>, ils pourraient obtenir toute la bonne presse à notre place.
Ne pourrions-nous pas travailler à répondre aux différents besoins et cas
d'utilisation avec différents <i>produits</i> (version rolling, peut-être des
images autonomes), sans compromettre la qualité de nos versions stables ?
Je pense même qu'avoir plus d'utilisateurs de <i>testing</i> augmenterait la
qualité de nos versions stables en ayant plus d'yeux pour trouver des bogues
(rappel : le <a href="http://www.donarmstrong.com/posts/bug_reporting_rate/";>\
taux de bogues signalés diminue</a>).
</p>
<h3 class="subsection">Comment y parvenir ?</h3>
<dl class="description">
<dt class="dt-description"><b>Promouvoir l'innovation au sein de Debian</b></dt>
<dd class="dd-description">
Nous devrions mieux accueillir l'innovation
et les expérimentations au sein du projet.
Souvent, nous les tolérons à peine, et la
bureaucratie les rend difficiles et lentes à mener.
<p>
Même si ce n'est pas le rôle du chef de projet de décider des directions
du projet, si je suis élu, j'encouragerai (les discussions sur) les idées
innovantes, examinerai comment les ressources du projet peuvent être
utilisées pour les soutenir, et communiquerai sur les expérimentations.
Bien sûr, ces expérimentations devront contenir des mesures de succès
et les avertissements nécessaires (pas de garantie à long terme
du maintien de l'expérimentation, pas de suivi en sécurité, etc.)
</p>
</dd>
<dt class="dt-description"><b>Améliorer l'accessibilité de Debian et baisser la barrière pour contribuer</b></dt>
<dd class="dd-description">
Alors que de plus et plus de gens utilisent des logiciels libres
(qui sont des contributeurs potentiels), de plus et plus de projets
sont en compétition avec nous pour attirer les contributeurs.
De nombreux efforts ont été réalisés dans ce domaine,
mais il reste encore beaucoup de choses à améliorer.
<ul class="itemize">
<li class="li-itemize">
Nous devrions <b>améliorer notre documentation pour les
développeurs</b> (j'ai moi-même contribué à cela en écrivant
une <a href="$(HOME)/doc/devel-manuals#packaging-tutorial">\
introduction à l'empaquetage Debian</a> et en tant
qu'éditeur de la référence du développeur Debian).
Certaines équipes n'ont toujours pas de documentation adéquate
de leur mode de fonctionnement et outils dans les sous-pages
de <a href="http://wiki.debian.org/Teams";>wiki.d.o/Teams</a>.
Comment pouvons-nous attendre que les développeurs
restent si la documentation n'est pas satisfaisante.
De la consolidation est aussi possible ici : par exemple, nous
n'avons pas vraiment de documentation de référence du mode de
fonctionnement de l'empaquetage avec Git (j'ai commencé une <a
href="http://wiki.debian.org/GitPackagingWorkflow";>initiative à ce propos
lors de DebConf11</a>, mais elle est surtout restée en sommeil depuis).
C'est très mauvais : d'un point de vue de contributeur, cela
fait comme si chaque équipe Debian était un projet séparé.
</li>
<li class="li-itemize">
Nous devrions <b>simplifier nos pratiques de développement</b>
en (1) annonçant mieux les pratiques recommandées et en les
(2) implémentant plus rapidement dans la plupart des paquets (cela prend
souvent <a href="http://www.lucas-nussbaum.net/blog/?p=751";>des années
avant qu'une bonne nouvelle pratique soit adopté majoritairement</a>).
Par exemple, nous devrions annoncer qu'Ã moins de savoir ce que vous faites
(oui, il y a de bonnes raisons de faire les choses autrement)Â : vous
devriez utiliser <tt>dh</tt>, vous devriez maintenir vos paquets au sein
d'une équipe ou, en absence d'équipe adéquate, utiliser un dépôt Git du
projet <tt>collab-maint</tt> (et penser à rechercher des comainteneurs).
Nous devrions aussi essayer de basculer les paquets existants vers
ce modèle, et documenter proprement ce processus, mais je me répète.
</li>
<li class="li-itemize">
Nous devrions <b>améliorer notre infrastructure de parrainage</b> (rappel :
<a href="http://www.lucas-nussbaum.net/blog/?p=746";>la moitié des mainteneurs
de paquets ne sont ni développeurs Debian, ni mainteneurs Debian</a>) :
<a href="http://mentors.debian.net/";>debexpo et mentors.d.n</a> sont
géniaux, mais pourraient avoir plus de fonctionnalités, comme plus
de tests automatisés d'assurance qualité (construction, piuparts).
Par ailleurs, je vois deux façons de combattre la situation de manque de main
d'Å?uvre pour l'examen des paquets : (1) enfin mettre en place un dépôt de
paquets personnels, pour que l'attente d'examen devienne un peu moins pénible
et (2) demander aux non développeurs Debian d'examiner les paquets à la façon
d'un site web social (c'est aussi une façon très sympathique d'apprendre).
</li>
<li class="li-itemize">
Nous devrions continuer à pousser pour la
<b>maintenance collaborative en équipe</b>.
Nous devrions aussi réfléchir à <b>réduire la propriété de paquet</b>.
Alors qu'avoir des mainteneurs qui se sentent responsables de leurs
paquets (et sont souvent de véritables experts de ces paquets)
est une force importante de Debian, les mainteneurs devraient
penser en termes de <q>paquets dont je m'occupe actuellement dans
Debian</q> plutôt qu'en <q>paquets que je possède dans Debian</q>.
La <a href="http://dep.debian.net/deps/dep1.html";>pratique actuelle de mises
à jour indépendante (NMU)</a> (une modification que j'avais pilotée en 2008)
est une bonne base, mais nous pourrions profiter d'une petite évolution
culturelle en accueillant mieux les contributions d'autres contributeurs.
Par exemple, nous pourrions généraliser le modèle de sécurité
de collab-maint (c'est-à -dire <q>tous les développeurs Debian
ont accès en écriture</q>) pour plus de dépôts de paquets.
<p>
Cependant, la maintenance en équipe cache parfois les cas
où plus aucun mainteneur n'est actif dans une équipe.
Nous devrions aussi nous améliorer à identifier ces cas,
et adapter notre infrastructure et procédures en fonction.
</p>
</li>
</ul>
</dd>
<dt class="dt-description"><b>Améliorer la communication avec les projets amont</b></dt>
<dd class="dd-description">
Les mainteneurs n'ont souvent pas de contact
du tout avec les développeurs amont.
Nous devrions favoriser les relations fonctionnelles avec les projets
amont, en les faisant participer à la maintenance de paquet s'ils le
veulent et en leur transmettant les renseignements sur les bogues
affectant Debian ou les correctifs du paquet Debian (améliorant <a
href="http://patch-tracker.debian.org/";>http://patch-tracker.d.o/</a>).
</dd>
</dl>
<p><br /></p>
<p>
Ce qui précède devrait vous donner une bonne idée de mes positions.
Bien sûr, je n'aurai sans doute pas le temps de m'en occuper moi-même
(et devenir chef du projet rend cela encore plus improbable), mais vous
savez au moins ce que je considère important et ce que j'encouragerai.
</p>
<h2 class="section">Rôle du chef de projet et modèle de gouvernance</h2>
<h3 class="subsection">Sur la gouvernance</h3>
<p>
J'ai l'intention de continuer l'initiative d'<i>assistants DPL</i>.
De nombreux autres développeurs Debian (y compris d'anciens chefs
de projet) ont d'excellentes idées pour le projet, mais peu
peuvent dédier suffisamment de temps pour être le chef du projet.
J'aimerais construire un environnement leur permettant de partager
la charge de travail du chef de projet et avancer avec leurs idées.
</p>
<p>
La direction globale que j'aimerais viser ici est une équipe ouverte de
développeurs Debian pilotant le projet, menée par le chef du projet.
� long terme, cela pourrait permettre de diminuer la charge spécifique du
chef de projet, qui deviendrait alors un simple responsable de ce groupe.
Bien sûr, ça ne doit pas tourner à la cabale et ne doit pas
affecter les processus de prise de décision à base de consensus.
Aussi, par souci de clarté, je n'ai pas l'intention d'aller dans la
direction d'une équipe du chef de projet institutionnalisée pendant mon
mandat : je pense que nous avons besoin de plus de temps pour comprendre
comment une <i>équipe du chef de projet</i>, institutionnalisée
ou pas, peut apporter quelque chose au projet et pour évaluer
les inconvénients d'une équipe du chef de projet institutionnalisée.
</p>
<h3 class="subsection">Sur la médiation</h3>
<p>
Une partie importante du rôle de chef du projet est d'être un médiateur et de
contribuer à résoudre les problèmes complexes qui surviennent nécessairement
de temps en temps dans n'importe quel projet à base de bénévolat.
</p>
<p>
Une chose que j'aimerais faire avancer dans ce contexte est un
<i>observatoire du projet</i>Â : rassembler un ensemble de mesures
à propos du projet afin de détecter les problèmes a priori et se
rapprocher des gens avant que le problème ne dégénère en grosse crise.
Bien sûr, tout ne peut pas être détecté en utilisant ce genre
de mesures et j'ai aussi l'intention d'utiliser les réunions
d'<i>assistants DPL</i> comme un moyen pour construire une vision
plus étendue du projet et de l'évolution de ses problèmes.
</p>
<p>
J'ai parfois eu l'impression par le passé que le chef du projet n'était pas
nécessairement la meilleure personne pour piloter une médiation (parce qu'il
n'avait pas de (bonnes) relations personnelle avec les développeurs Debian
concernés ou parce qu'il n'avait ce genre de relations que d'un côté.
Les réunions d'<i>assistants DPL</i> seront de bonnes opportunités
pour trouver des médiateurs plus adéquats si nécessaire.
</p>
<h3 class="subsection">Sur l'organisation</h3>
<p>
L'organisation construite par Stefano Zacchiroli pendant
ses trois mandats s'est montrée particulièrement efficace.
Si je suis élu, j'opterai pour la même organisation, y compris les
courriers mensuels sur d-d-a et le journal d'activité quotidien privé.
Les réunions d'<i>assistants DPL</i> seront organisées
régulièrement (au moins toutes les deux semaines).
</p>
Attachment:
signature.asc
Description: OpenPGP digital signature