-- .~. Nicolas Bertolissio /V\ [EMAIL PROTECTED] // \\ /( )\ ^`~'^ Debian GNU-Linux
#use wml::debian::template title="Programme de Gustavo Franco" BARETITLE="true" NOHEADER="true" #include "$(ENGLISHDIR)/vote/style.inc" #use wml::debian::translation-check translation="1.7" maintainer="Nicolas Bertolissio"
<h1>
Programme de Gustavo Franco
</h1>
<h2>
Introduction
</h2>
<p>
Je suis né à Rio de Janeiro, au Brésil – il y a un certain temps. Je
travaille pour une O.N.G. appelée Information Network for the Third Sector
– qui a pour but sur le renforcement des organismes de la société
civile et des mouvements sociaux ; j'y coordonne l'équipe technologique,
dirigeant les services internet de notre propre FAI et menant le développement
d'une distribution personnalisée basée sur Debian.
</p>
<p>
J'emploie les logiciels libres depuis dix années et Debian depuis sept ans, en
même temps j'ai donné beaucoup d'entretiens liés aux systèmes libres et à code
source ouvert à travers le pays. Sans compter GNU/Linux, j'ai également utilisé
les systèmes d'exploitation FreeBSD et OpenBSD. Je les aime et attends avec
intérêt une publication de Lenny avec kfreebsd-i386 et kfreebsd-amd64, au
moins.
</p>
<h2>
Pourquoi voter pour Gustavo Franco ?
</h2>
<p>
J'ai commencé à contribuer au projet Debian il y a presque six ans et j'ai
attendu la création de mon compte après avoir été recommandé au responsable des
comptes de Debian pendant plus de trois années, c'est arrivé il y a deux ans.
Pendant ces deux années j'ai fait beaucoup plus qu'avant, et le mot-clé
est : motivation.
</p>
<p>
Je demande votre voix pour garder motivées les personnes qui travaillent à
faire aboutir nos objectifs pendant mon mandat. J'expliquerai ces buts en
détail ci-dessous et si vous en partagez beaucoup, je pense que je suis votre
candidat, autrement si vous n'en partagez que quelques uns je pense que vous
devriez me classer juste au-dessous de votre candidat préféré. Il est possible
que je n'ai décrit ici aucun but commun que nous partagions, ne me rejetez pas
immédiatement. Envoyez-moi un message en privé et indiquez-moi vos buts dans le
projet de Debian. Je ferai de mon mieux pour en préciser au moins un que nous
avons en commun et sur lequel nous travaillerons pendant mon mandat, si je suis
élu.
</p>
<p>
Je voudrais vous informer qu'en considérant que nous ne pouvons pas forcer des
volontaires à travailler, les gens qui ont des positions clés et qui sont
surchargés ou incapables d'effectuer le travail volontaire pour quelque raison
que ce soit, devront partager leurs rôles avec d'autres pour améliorer notre
système d'exploitation universel. Voter pour moi signifie que vous respectez
les contributions et les compétences des personnes mais que vous n'acceptez pas
des fonctions mal documentées et immuables dans notre structure d'organisation.
</p>
<h2>
Mon histoire dans Debian
</h2>
<p>
Après avoir rejoint l'équipe pkg-Perl et avoir contribué au groupe dans son
ensemble, y compris à la charte des mises à jour. Je me suis aperçu que nous
n'avions pas eu de projet semblable pour les modules Python aussi ai-je fondé
l'équipe des modules Python de Debian avec Guilherme Pastore juste après que
nous ayons été rejoints par Raphaël Hertzog et beaucoup d'autres contributeurs.
J'ai également lancé le groupe pkg-ltsp après avoir parlé en tête à tête avec
Otavio Salvador au sujet de l'état d'empaquetage de ltsp et de comment nous
traînions derrière Ubuntu. Ensuite j'ai organisé une réunion en ligne avec les
responsables d'Ubuntu de ltsp et ceux de Debian pour discuter de notre
coopération, nous avons donc maintenant presque le même ensemble de
fonctionnalités dans la distribution instable et la version Etch de Debian peut
être facilement utilisée comme serveur de clients légers.
</p>
<p>
Je suis également parvenu à recoller ensemble : le site de développement
pour la bureautique de Debian, la liste de diffusion debian-desktop et le
projet de debian-desktop d'Alioth – comprenant les membres de
pkg-gnome, de pkg-kde et de pkg-xfce pour travailler autour d'un vrai projet de
bureautique pour Debian avec des graphismes communs et un ensemble de
fonctionnalités communes, pendant le cycle de développement d'Etch. En outre
avec la coopération des membres des projets tasksel, debian-Cd et debian-live,
je pensent que nous avons dans Etch le meilleur acquis de bureautique de Debian
jamais obtenu.
</p>
<p>
Je suis également membre et j'ai contribué aux groupes suivants : pages du
site Debian, équipe de Gnome, tasksel, debtags, Debian-BR, équipe
d'incorporation des améliorations d'Ubuntu et pkg-galago.
</p>
<h2>
Mon programme
</h2>
<p>
Je projette de consacrer plus de temps aux principaux points ci-dessous. Je
veux envoyer des revues mensuelles mais aussi en fonction des avancées à
debian-devel-announce avec les numéros de bogues concernés (s'il y en a) ou des
résumés de rapports. Je vous tiendrai au courant de ce que je considère comme
important et d'autres questions dont je suis sûr qu'elles apparaîtront :
</p>
<ul>
<li>
<p>
Les équipes principales
</p>
<p>
Je considère l'administration des serveurs de Debian (y compris des
archives ftp), la gestion des porte-clés, la documentation, les portages,
la sécurité, la gestion des publications et l'installateur comme les
domaines principaux du projet. Ces domaines et les équipes principales
correspondantes excepté pour la documentation, la gestion des publications
et l'installateur sont de loin les groupes les plus critiqués depuis plus
de six années. Pendant ce temps nous avons publié Slink, Woody, Sarge et
nous sommes défiés par des distributions jeunes qui, dans les six années à
venir ou plus tôt, seront plus appropriées que Debian dans chaque domaine
et pourrons clamer qu'elles développent vraiment le logiciel d'exploitation
universel.
</p>
<p>
Je demanderai aux équipes principales des procédures claires sur la façon
dont un développeur Debian peut y contribuer et les rejoindre après un
certain temps, en fonction de son mérite. Je veux rendre claire la
différence entre un rôle d'assistant et un membre à part entière d'une
équipe principale ainsi que la manière pour un assistant de postuler afin
de devenir un membre à part entière. En moins d'un an, il n'y aura aucun
point d'échec dans aucun des domaines principaux, si c'est vraiment ce qui
est voulu.
</p>
<p>
Précisons que je ne serai pas moi-même candidat en tant que membre d'aucune
équipe principale pendant mon mandat.
</p>
<p>
Je travaillerai également pour maintenir la page de la structure
d'organisation de Debian à jour et pour documenter chaque poste qui y est
énuméré.
</p>
</li>
<li>
<p>
Objectifs de publication
</p>
<p>
Le projet Debian n'a aucun programme fixe de publication et l'argument de
base de ceux qui soutiennent cette approche est que cela augmente la
qualité. Indépendamment du nombre d'heures que vous passez sur un cycle de
développement, si vous n'effectuez pas le travail il n'y a aucune qualité à
promouvoir. L'autre point est que si vous continuez à travailler sans buts
clairs en dehors de la qualité la meilleure possible, vous ne publiez
jamais.
</p>
<p>
J'ai entendu parler qu'une compagnie basée à Redmond est connue pour
laisser passer beaucoup d'années entre les versions de son système
d'exploitation et que cette seule approche n'a pas augmenté la qualité du
produit ni qu'elle a les meilleurs ni les derniers outils empaquetés avec
son système d'exploitation.
</p>
<p>
Les précédents candidats responsables du projet Debian ont proposé que
Debian augmente son rythme de publication et ait un calendrier fixe de
publication. Malheureusement, je n'ai vu d'eux aucune vraie action en
dehors du travail difficile de l'équipe de publication pendant le cycle de
développement d'Etch.
</p>
<p>
Je veux avancer et définir clairement des objectifs de publication de Lenny
pendant mon mandat. Je pense qu'il y a beaucoup de logiciel et de projets
principaux (faisant participer des groupes ou des groupes de groupes) dans
Debian qui peuvent être employés comme <q>moyens de support</q> pour nos
publications (par exemple : le noyau, l'installateur, le serveur web
le plus utilisé, les environnements de bureau les plus communs). Par ces
<q>moyens de support</q>, j'ai voulu dire qu'une fois que nous avons les
versions amonts que nous avons définies à l'avance en place, il est temps
de passer en phase de gel et de définir le système d'exploitation dans son
ensemble. De même que nous avons une procédure pour qualifier une
architecture pour la publication, je veux discuter avec l'équipe de
publication et avec vous d'une procédure pour qualifier un logiciel ou un
projet comme objectif de publication.
</p>
</li>
<li>
<p>
Le système de suivit de bogues^W Debian
</p>
<p>
En fait, nous n'employons pas la pleine capacité de notre système de suivi.
Le code derrière bugs.debian.org, avec juste quelques adjonctions, quelques
ajustements et l'utilisation appropriée des étiquettes utilisateurs peut
servir en tant que ce que j'appelle le système de suivi de Debian. Vous
êtes libre de continuer à l'appeler <q>système de suivi des bogues</q>
cependant, mais si je suis élu je promouvrai les changements
suivants :
</p>
<ul>
<li>
ajouter la gestion des votes. S'il est bien mis en application, un
contributeur ou un développeur peut facilement repérer les bogues qui
affectent beaucoup d'utilisateurs. Chaque bogue critique pour la
publication suscite l'attention avant une publication, on ne peut pas
dire de même des bogues qui ne sont pas critiques pour la publication,
mais beaucoup d'eux gênent de nombreux d'utilisateurs ;
</li>
<li>
ajouter un <q>rapport un bogue</q> sur la Toile. Permettre aux
utilisateurs d'écrire des rapports de bogue contre des paquets ou des
pseudo-paquets dans la page bugs.debian.org/nom_du_paquet, en exigeant
l'adresse électronique du déposant et en mettant peut-être en
application CAPTCHA. Envoyer au déposant un message <q>veuillez
confirmer votre rapport de bogue</q> avant d'envoyer le rapport de
bogue au responsable de paquet et de le lister dans l'interface sur la
Toile ;
</li>
<li>
ajouter le pseudo-paquet debian-admin. Je voudrais que l'équipe
d'administration de Debian d'admin emploie de préférence ce système
pour suivre les problèmes publics en cours. Veuillez lire également le
rapport n° 408150 à http://bugs.debian.org/408150 ;
</li>
<li>
ajouter une page de statistiques. Elle contiendrait au moins les cinq
principales personnes ayant fermé des bogues récemment, les bogues
clôturés et les bogues ouverts ;
</li>
<li>
prolonger le concept des étiquettes utilisateurs à des bogues
utilisateurs, comme étant des bogues que seuls le déposant ou un groupe
de personnes ayant souscrit (y compris ou pas le déposant) peut
contrôler par courriels, mais qui ne sont pas montrés dans la page des
bogues d'un paquet ou d'un pseudo-paquet. Ce dispositif est utile pour
des projets comme utnubU et pourrait également être employé pour les
transitions.
</li>
</ul>
<p>
Je veux également m'assurer qu'aucune initiative de traduction impliquant
une interface web pour coordonner les traductions ne rendra cauchemardesque
l'entretien actuel par les bogues souhaités dans le système de suivi des
bogues. Je pense que nous pouvons rendre caduque le comportement actuel en
important périodiquement les traductions en attente dans le nouveau
système, mais il serait mieux que ce nouveau système puisse coexister et
respecter les numéros de bogues du système de suivi des bogues. De cette
façon importer une traduction pour la publication d'un paquet, clôturera
toujours le bogue.
</p>
<p>
Malheureusement je n'ai pas encore discuté de ces propositions (excepté
pour le bogue n° 408150) avec les administrateurs du système de suivi
des bogues par manque de temps, mais si je suis élu je préparerai une
proposition plus détaillée avec l'aide d'autres personnes pour chaque
caractéristique et je proposerai des correctifs de base.
</p>
</li>
<li>
<p>
Nouveaux développeurs
</p>
<p>
Il est clair que nous avons besoin de développeurs nouveaux et compétents,
les développeurs Debian sont une ressource rare, les contributeurs
réguliers à Debian ne sont pas si communs et nous avons beaucoup
d'utilisateurs à satisfaire. Ce n'est pas aussi facile que ça en a l'air,
laissons venir du <q>sang frais</q>. Je voudrais donner à Joerg Jaspert des
privilèges complets de responsable des comptes de Debian (y compris la
possibilité d'entretien des porte-clés), et promouvoir un responsable de
candidature bien connu par ses résultats comme assistant des responsables
des comptes de Debian pour collaborer avec Joerg et James.
</p>
</li>
<li>
<p>
Nouveaux paquets
</p>
<p>
Je pense qu'une ou deux nouvelles personnes peuvent gérer les paquets dans
la file d'attente des nouveaux paquets qui ne sont pas vraiment nouveaux,
mais simplement de vieux paquets source produisant de nouveaux paquets
binaires sans autoriser de modifications. Ce changement sera fait si
nécessaire, après une revue d'équipe de ftpmaster. Qui et pourquoi les
assistants sont des assistants et ce qu'ils ne peuvent pas faire que des
membres à part entière sont censés faire.
</p>
</li>
<li>
<p>
Comité technique
</p>
<p>
Le comité technique est créé par la constitution de Debian, à la
section 6. C'est le corps qui prend une décision finale sur des
conflits techniques au sein du projet de Debian. Si la page du site est à
jour leur dernière décision technique a été prise en 2004, le comité a
été ensuite étendu malgré tout. Je serais heureux de voir un comité
technique plus actif pendant mon mandat.
</p>
<p>
Je projette également de proposer une résolution générale de modifier notre
constitution (6.6) et introduire au moins deux membres élus dans le comité
technique pendant mon mandat et être sûr que la constitution modifiée
permettra une rotation des membres du comité techniques de temps en temps.
Je crois que nous verrons les programmes intéressants venant de personnes
compétentes du projet et intéressées par les revues et le travail sur la
résolution des problèmes exposés dans le système de suivi de Bogues^W
Debian (pseudopaquet : tech-ctte). Je pense que ce peut être la prochaine
étape logique pour les membres actifs de la communauté ayant une histoire
intéressante dans le projet, et je pense qu'ils peuvent agir comme un lien
entre n'importe quel contributeur de Debian et le cœur du projet sur
les questions techniques.
</p>
</li>
<li>
<p>
Trésors cachés de Debian : groupes, sous-projets et super-groupes
</p>
<p>
Il y a beaucoup d'utilisateurs et d'enthousiastes autour de Debian qui ne
réalisent pas combien nous avons évolué en termes de groupes, de
sous-projets et de super-groupes. J'entends groupes en tant que n'importe
quel groupe dans Alioth ; sous-projets en tant que groupes plus
officiels avec une page sur notre site officiel et super-groupes en tant
que groupe de groupes (par exemple : debian-desktop).
</p>
<p>
Je pense que sans notre GForge installé (sur Alioth) nous n'aurions pas de
groupes, de super-groupes et même certains sous-projets qui existaient déjà
mais n'avaient pas une activité aussi organisés. Pendant mon mandat, je
discuterai avec le comité technique pour savoir s'il vaut la peine d'écrire
des procédures techniques détaillées qui s'appliqueraient à un groupe
d'Alioth pour être promu en sous-projet. Ce serait particulièrement utile
pour les groupes orientés en service (par exemple : les rétroporteurs
et les parrains) parce que certains utilisateurs ne les connaissent
simplement pas ou refusent de les employer parce que leur statut n'est pas
officiel.
</p>
<p>
Des groupes, des sous-projets ou des super-groupes, je pense qu'en tant que
communauté que nous devrions employer et favoriser plus ce qui est sympa et
qui fonctionne. Je vois des propositions impliquant des choses que les
mentors et les parrains font depuis longtemps. Parlez de vos projets Alioth
favoris maintenant !
</p>
</li>
<li>
<p>
Nouveaux logiciels dans les publications stables et rétroportages
</p>
<p>
Basé sur les critères pour promouvoir les groupes en sous-projets, je
voudrais voir favorisés les rétroportages pendant le cycle de développement
de Lenny. De cette façon nous pourrons ajouter des logiciels nouveaux mais
gérés officiellement dans une version stable. La gestions et les critères
de sécurité pour l'insertion ont besoin de davantage de discussion, ce que
je prévois de faire avec les équipes impliquées et le comité technique.
</p>
</li>
<li>
<p>
Debian est un système d'exploitation universel
</p>
<p>
Où est donc la sphère Debian ? Le projet Debian a besoin de plus
d'événements officiels et d'un calendrier pour les suivre. Je pense que les
organisateurs actuels et passés des conférences Debian (notre événement
annuel principal) peuvent partager leur expérience avec les organisateurs
locaux d'événements sur la façon d'obtenir et de gérer des fonds de
sponsors et publier les conférences locales. Je discuterai aussi avec les
parties impliquées de la possibilité de créer une équipe formelle pour les
événements.
</p>
<p>
Je ferai de mon mieux pour voir au moins une conférence Debian en Asie, en
Amérique du Nord et en Amérique latine se produire après notre conférence
Debian mondiale en Écosse cette année et avant celle d'Argentine. Ces
conférences locales de Debian devraient être plus petites et focalisées sur
la réunion de développeurs et de contributeurs qui ne pouvaient pas
assister à l'événement mondial à cause de son éloignement et de sa date,
elles devraient présenter des exposés relatifs à des problématiques
locales, développer un ordre du jour local, travailler à l'organisation de
chasses aux bogues. Avec la possibilité d'inviter et d'accueillir quelques
étrangers naturellement.
</p>
<p>
Je veux favoriser la <q>semaine de Debian</q>, une semaine en août où des
groupes d'utilisateurs de Debian, des groupes d'utilisateurs de Linux et la
communauté de Debian dans l'ensemble seront encouragés à favoriser des
événements destinés aux utilisateurs. Les développeurs peuvent participer
en aidant à organiser de tels événements ou produisant des exposés. Les
groupes intéressés par les discours des développeurs de zones éloignés
pourront nous contacter et nous pourrons agir en tant que lien entre les
organisateurs, les sponsors et le développeur pour payer le voyage et
couvrir d'autres coûts. Les organisateurs de la <q>semaine de Debian</q>
prépareront une liste des développeurs souhaitant présenter des exposés de
façon volontaire, près de chez eux ou dans des zones plus éloignées.
</p>
<p>
Je suis totalement pour le développement de réunions de groupes <q>à la
demande</q>, un équipe chargée des événements pourrait effectuer le dur
travail d'organisation de conférences aussi spécialisées et le groupe de
développement pourrait consacrer la majeure partie de son temps à faire ce
qu'il fait de mieux. L'équipe des événements peut également agir en tant
que relais entre l'équipe de presse et le groupe occupé à travailler sur
notre prochaine grande fonctionnalité, pour s'assurer que les résultats de
la rencontre de développement sont bien diffusés à toutes les personnes
intéressées.
</p>
</li>
<li>
<p>
Portages de Debian
</p>
<p>
Je ferai de mon mieux pour motiver plus de personnes pour nous aider à
publier Lenny avec la gestion des architectures kfreebsd-i386 et
kfreebsd-amd64, et j'essayerai de pousser un fournisseur important à gérer
officiellement des serveurs Debian GNU/KFreeBSD, si je suis élu.
</p>
<p>
Je veux également discuter des téléchargements de code source seul et de la
possibilité de forcer un téléchargement de code source seul à compiler sur
une architecture assez rapide avant d'essayer sur une plus lente. Je
voudrais aider Lucas Nussbaum à travailler sur piuparts pour la
distribution de test pendant le cycle de développement de Lenny pour
repérer les bogues qui sont passés inaperçus et si cela réussi permettre
des tests fondamentaux de mise à niveau, d'installation et de suppression
sur presque n'importe quel paquet, après la compilation sur une
architecture suffisamment rapide.
</p>
<p>
Je suis totalement pour des essais de construction virtualisée,
particulièrement sur des architectures que nous ne publierons pas dans
Etch. Les personnes intéressées par ce projet, si je suis élu, peuvent me
contacter. Je ferai une proposition pour le comité technique liée à des
directives de résultats des démons de construction. Si tout va bien avec la
version suivant Lenny cette discussion sera une chose du passé et nous
aurons des constructeurs automatiques virtualisés nombreux et stables.
</p>
</li>
<li>
<p>
Matériels et fournisseurs favorables à Debian
</p>
<p>
Pendant mon mandat, je veux faire vendre et supporter des machines de
bureau avec Debian Etch préinstallé à au moins un fournisseur principal de
matériel d'ordinateur de bureau. Je veux également faire utiliser Debian
Etch à un fournisseur important de gadgets fonctionnant sous Linux. En se
basant sur les résultats de HP en 2006, en théorie il serait plus
facile de voir un fournisseur important ajouter le support d'un ou deux
produits du côté des serveurs. Quoi qu'il en soit, il encouragera ses
concurrents, ainsi que des acteurs plus petits à également vendre et
supporter Debian. Il y a deux effets secondaires intéressants et
intentionnels : nos utilisateurs auront plus de choix pour faire
fonctionner Debian, et nous agrandirons l'univers des employeurs possibles
de contributeurs de Debian.
</p>
<p>
Je travaillerai avec les équipes qui en ont la charge pour écrire la
documentation spécifique pour les fournisseurs intéressés par la
préinstallation sans modification de Debian sur leurs systèmes. C'est plus
facile qu'ils ne pensent en utilisant la préconfiguration de l'installateur
Debian, nous devons juste le leur dire.
</p>
<p>
Je suis au courant des constructeurs d'ordinateurs qui préinstallent Debian
listés à : http://www.debian.org/distrib/pre-installed. Je ne suis pas
sûr que la liste soit vraiment précise, mais je travaillerai avec les
équipes de presse et www pour en faire une utilisation plus large et pour
s'assurer que nous maintenons les entrées à jour.
</p>
</li>
<li>
<p>
Site de Debian
</p>
<p>
Nous avons un site fantastique en termes de contenu et de traduction mais
sans moteur de recherche je n'ai pas de plaisir à le parcourir et je suis
sûr que d'autres partageront la même opinion. Je veux passer en revue avec
l'équipe du site les cas d'utilisation du site de Debian les plus communs
et que nous ne couvrons pas, une petite mise à jour de conception, la
possibilité d'intégration d'une partie du contenu du wiki et travailler sur
des directives de Debian pour le contenu que nous n'hébergeons pas. Je veux
rendre plus facile pour les gens qui travaillent sur des sites autour de
l'écosystème Debian l'utilisation d'une conception semblable et la
favoriser.
</p>
<p>
Je suis ouvert à la création d'une branche temporairement du site pour
examiner de nouvelles idées, avec un accès limités aux seuls développeurs
et pour rassembler leurs opinions sur la liste de diffusion debian-www.
Ces nouvelles idées peuvent être des essais pour couvrir certains cas
d'utilisation et une petite mise à jour de conception, comme cité
ci-dessus. J'aime la barre dans une des propositions à la disposition de
debian-community.org (http://www.debian-community.org/dc_proposal2.png), et
je pense que des détails comme ceux-là pourraient être examinés sur le
contenu actuel du site.
</p>
</li>
<li>
<p>
Publicité sur Debian
</p>
<p>
Je discuterai avec l'équipe de presse et la liste de diffusion
debian-publicity de stratégies sur la façon de plus promouvoir ce qui est
réellement si bien dans le projet Debian et dans le système d'exploitation
Debian GNU/Linux. Il y a des tonnes de possibilités, comme plus favoriser
Alioth et l'utilisation de sponsors.debian.net pour les nouveaux venus.
Sortir plus de communiqués de presse avec un contenu approprié ou avec des
entreprises, en publiant qu'elles ont de bons résultats en utilisant Debian
ou vendant de l'expertise. Je voudrais lire plus d'articles sur Debian sur
les sites et les magazines liés aux technologies générales et non pas sur
les sites consacrés aux systèmes libre et à code source ouvert et je ferai
de mon mieux pour cela pendant mon mandat.
</p>
</li>
<li>
<p>
Mises à jours indépendantes
</p>
<p>
Je favoriserai les mises à jours indépendantes à faible seuil, telles
qu'expliquées actuellement dans le wiki et sur la base du volontariat des
développeurs, pour chaque paquet. Nous pouvons le faire en utilisant un
nouveau fichier facultatif dans le répertoire debian, appelé
<q>nmupolicy</q> et contenant quelque chose comme ce qui suit :
</p>
<pre>
Format: 1
NMUFriendly: Yes|No
NMUNotes: <comment>
</pre>
<ul>
<li>
les paquets sans ces deux champs devraient être mis à jour de manière
indépendante selon les règles actuelles ou comme indiqué par l'équipe
de gestion de publication ;
</li>
<li>
les paquets avec le champ NMUFriendly positionné à oui et sans champ
NMUNotes devraient toujours être traités comme maintenus par la
personne ou le groupe listé dans le champ Maintainer mais
téléchargeable par n'importe quel autre développeur, selon une règle
simple : joindre le correctif à un bogue dans le système de
gestion des bogues avant le téléchargement ;
</li>
<li>
les paquets avec le champ NMUFriendly positionné à oui et avec un champ
NMUNotes devraient donner dans ce champs des indications claires sur la
façon de procéder pour le responsable de la mise à jour indépendante
autre que <q>joindre le correctif à un bogue dans le système de gestion
des bogues avant le téléchargement</q>. Les phrases suivantes sont des
exemples corrects : <q>Contacter [EMAIL PROTECTED]
et attendre au moins 4 jours</q> ; <q>Mises à jour
indépendantes autorisées pour les bogue de sévérité normale ou
supérieure</q> ; <q>Mises à jour indépendantes autorisées pour les
bogues critiques pour la publication</q> ; <q>Pas de mise à jour
indépendante pour les bogues de sévérité souhait</q> ;
</li>
<li>
les paquets avec le champ NMUFriendly positionné à non et sans champ
NMUNotes devraient être traités comme si les deux champs n'étaient pas
employés.
</li>
</ul>
<p>
La charte de Debian et le guide du nouveau responsable (au moins) devront
être mis à jour pour documenter l'utilisation du fichier <q>nmupolicy</q>.
le code de dh_make devra être mis à jour pour créer un modèle
debian/nmupolicy. Les codes du système de gestion des paquets, de
bugscanner, de lintian et de linda devront également être mis à jour pour
employer ces champs.
</p>
</li>
</ul>
<p>
Je me ferai également tatouer un tourbillon à la fin de mon mandat.
— stratus
</p>
<h2>
Réfutations
</h2>
<h3>
Wouter Verhelst
</h3>
<p>
Je suis sûr qu'il a quelques idées générales sur la façon de résoudre quelques
problèmes de Debian et d'améliorer la situation, mon problème avec son
programme, c'est qu'il n'explique pas clairement ce qu'il va faire. Je veux une
atmosphère plus communicative et plus transparente et Wouter échoue déjà en
tant que meneur dans son programme. Il est cependant un contributeur important.
</p>
<h3>
Aigars Mahinovs
</h3>
<p>
Debian vise à être un système d'exploitation universel. Un système
d'exploitation universel sans publications n'a aucun sens de mon point de vue,
mais Aigars veut que Debian ne soit jamais publiée <q>telle quelle</q> et ne
reste qu'un tronc<!-- pas vraiment sûr de ça, l anglais ne me semble pas clair
du tout-->. Il est libre d'employer et de préconiser la distribution instable
(Sid). Il n'est pas nécessaire d'être responsable du projet Debian et de ne
rien changer.
</p>
<h3>
Sven Luther
</h3>
<p>
Réfutation bientôt disponible
<p>
<h3>
Sam Hocevar
</h3>
<p>
Sam a un programme intéressant, avec quelques points positifs. Il semble que
nous nous soyons assis et ayons écrit nos programmes ensemble, mais ce n'est
pas le cas. Je ne le connais pas, vraiment. Je ne pense pas que plaisanter de
ses propres idées nous apportera une meilleure atmosphère. J'espère qu'il fera
beaucoup des choses qu'il a proposées dans son programme s'il n'est pas élu. Il
semble que sa décision de ne changer aucune délégation le mettra en froid s'il
est élu.
</p>
<h3>
Steve McIntyre
</h3>
<p>
Steve semble être une personne intéressante, et j'ai eu le plaisir de
travailler avec lui lors de la correction de Simple-CDD pour que ça fonctionne
avec le nouveau debian-cd. Malheureusement, je ne vois pas où, en tant que 2IC
pendant le dernier mandat, il a fait avancer ce qui était dans son programme
et/ou celui d'Anthony en 2006. Je ne peux donc pas avoir confiance en sa
motivation et son engagement pour son programme actuel.
</p>
<h3>
Raphaël Hertzog
</h3>
<p>
De ce que j'ai vu, Raphaël a habituellement de bonnes idées. L'équipe de
direction du projet Debian n'est pas une mauvaise idée et je ne m'attendais pas
à ce qu'il déclare qu'un conseil de 8 personnes ferait 8 fois mieux
qu'un seul responsable du projet Debian. Mon problème avec son programme, c'est
qu'il n'y a que quelques idées qui viennent de lui, et rien des 8 autres.
Vont-ils vraiment faire quelque chose ? Pourquoi ne pas apporter plus de
visibilité au comité technique et ne pas demander de conseils aux membres,
comme je l'ai proposé ? Il y a 3 candidats indiqués en tant que
membres potentiels de l'équipe. Pourquoi ces trois-là n'écrivent-ils pas au
sujet de cette équipe de direction du projet dans leurs programmes ?
Est-ce un piège ? J'espère que non.
</p>
<h3>
Anthony Towns
</h3>
<p>
Je pense que s'il se concentrait plus sur son programme de l'année dernière il
serait un meilleur responsable du projet Debian. Je me sens désolé pour toutes
les critiques qu'il a reçues à cause de son legs<!-- ? --> et de ses
compétences dans le projet, sincèrement. Malheureusement, il semble qu'il ait
encore échoué en utilisant son programme actuel pour publier une sorte de
calendrier de l'année passée contenant des excuses pour ses erreurs,
considérant ce qu'il a fait et qui n'a pas encore été évalué et justifiant
pourquoi il n'a pas avancé sur les changements proposés dans son programme
de 2006.
</p>
<h3>
Simon Richter
</h3>
<p>
Comme pour Wouter, en ajoutant le fait que Simon en a écrit encore moins.
</p>
signature.asc
Description: Digital signature
