<!ENTITY % dynamicdata SYSTEM "dynamic.ent"> %dynamicdata;
- <!ENTITY cvs-rev "$Revision: 1.62 $">
+ <!ENTITY cvs-rev "$Revision: 1.63 $">
<author>
<name>Ian Jackson </name>
</author>
-<!-- <!ENTITY cvs-en-rev "1.288"> -->
+<!-- <!ENTITY cvs-en-rev "1.315"> -->
<translator>
version française par Frédéric Bothamy (traducteur actuel)
</translator>
</version>
<copyright>
<copyrightsummary>
- Copyright © 2004—2005 Andreas Barth
+ Copyright © 2004—2006 Andreas Barth
</copyrightsummary>
<copyrightsummary>
Copyright © 1998—2003 Adam Di Carlo
travaillent déjà sur ces tâches et proposer des correctifs et des
améliorations.
</p>
+ <p>
+ Un écueil à éviter est d'avoir la partie locale de votre adresse
+ électronique trop générique : des termes comme mail, admin, root ou
+ master devraient être évitées. Veuillez consulter <url
+ id="http://www.debian.org/MailingLists/"> pour plus de détails.
+ </p>
</sect>
<sect id="mentors">
<heading>
<p>
Avant de décider de devenir responsable Debian, il vous faudra lire
toute la documentation disponible dans le <url id="&url-newmaint;"
- name="coin du nouveau responsable">. Elle décrit toutes les étapes
- préparatoires qu'il vous faudra franchir avant de déposer votre
+ name="coin du nouveau responsable">. Elle décrit en détail toutes les
+ étapes préparatoires qu'il vous faudra franchir avant de déposer votre
candidature. Par exemple, avant d'être candidat, il vous faudra lire le
<url id="&url-social-contract;" name="contrat social Debian">. Devenir
responsable Debian implique que vous adhériez à ce contrat social et
Pour devenir responsable, il faudra montrer que vous pouvez faire du
bon travail et que vous serez un bon contributeur. Pour cela, vous
pourrez proposer des correctifs par le système de suivi des bogues
- (BTS) et maintenir un paquet parrainé pendant un temps. Nous attendons
+ (BTS) et maintenir un paquet parrainé par un responsable Debian pendant
+ un temps. Nous attendons
aussi des contributeurs qu'ils soient intéressés par le projet dans son
ensemble et pas uniquement par leurs propres paquets. Si vous pouvez
aider d'autres responsables en fournissant des informations sur un
</p>
<p>
Si votre clé publique n'est pas sur un serveur public tel que
- &pgp-keyserv;, reportez-vous à la documentation disponible localement
- dans &file-keyservs;. Cette documentation explique comment mettre votre
+ &pgp-keyserv;, reportez-vous à la documentation disponible à
+ <url id="&url-newmaint-id;" name="Étape 2 : Vérification d'identité">.
+ Cette documentation explique comment mettre votre
clé publique sur un serveur. L'équipe <em>New maintainer</em> mettra
votre clé publique sur les serveurs de clés si elle n'y est pas déjà.
</p>
</p>
<p>
Pour faire acte de candidature, il vous faut un responsable Debian qui
- vérifiera votre candidature (un <em>avocat</em>). Après avoir contribué
+ soutiendra votre candidature (un <em>avocat</em>). Après avoir contribué
au projet Debian pendant un temps, quand vous choisissez de devenir un
responsable Debian officiel, un responsable déjà enregistré avec qui
vous aurez travaillé dans les derniers mois devra exprimer que, d'après
<p>
Habituellement, cela veut dire que les autres développeurs peuvent
faire des NMU (voir <ref id="nmu">) sur votre paquet si un gros
- problème (bogues empêchant l'intégration dans la distribution, mise à
+ problème (bogue empêchant l'intégration dans la distribution, mise à
jour de sécurité, etc.) se produit pendant que vous êtes en
vacances. Parfois, ce n'est pas très important, mais il est de toute
façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
<em>grave</em> et <em>serious</em> en anglais</p></footnote> sont
considérés comme ayant un impact sur la présence du paquet dans la
prochaine version stable de Debian. Ces bogues peuvent retarder la
- diffusion d'une distribution Debian ou peuvent justifier la suppression
+ publication d'une distribution Debian ou peuvent justifier la suppression
d'un paquet d'une distribution gelée. C'est pourquoi ces bogues doivent
être corrigés au plus vite.
</p>
</heading>
<p>
Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
- principalement hébergés sur le réseau <url id="&url-openprojects;"
- name="freenode"> (anciennement connu sous le nom de Open Projects
- Network). L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias
- vers <tt>irc.freenode.net</tt>.
+ principalement hébergés sur le réseau <url id="&url-oftc;"
+ name="Open and free technology community (OFTC)">. L'entrée DNS
+ <tt>irc.debian.org</tt> est simplement un alias vers
+ <tt>irc.oftc.net</tt>.
</p>
<p>
Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
</p>
<p>
Il existe également des canaux dédiés pour Debian sur d'autres réseaux
- IRC, notamment sur le réseau IRC <url id="http://www.oftc.net/"
- name="Open and free technology community (OFTC)">.
+ IRC, notamment sur le réseau IRC <url id="&url-openprojects;"
+ name="Freenode">, sur lequel pointait l'alias <tt>irc.debian.org</tt>
+ jusqu'au 4 juin 2006.
</p>
<p>
Pour obtenir un uniforme (« cloak ») sur freenode, vous devez
Debian 2.0, « Hamm » ; Debian 2.1,
« Slink »; Debian 2.2, « Potato » ;
Debian 3.0, « Woody » ; Debian 3.1,
- « Sarge » ; Debian (nombre à déterminer)
+ « Sarge » ; Debian 4.0,
« Etch ». Il y a aussi une pseudo-distribution nommée
« Sid », il s'agit de la distribution
<em>unstable</em> ; comme les paquets vont d'<em>unstable</em> à
serveurs HTTP et FTP de Debian. Si nous avions nommé le répertoire qui
contient la prochaine distribution à diffuser « testing »,
il aurait fallu changer son nom en « stable » au moment de
- la diffusion, ce qui aurait forcé les miroirs FTP à télécharger à
+ la publication, ce qui aurait forcé les miroirs FTP à télécharger à
nouveau la distribution complète (qui est plutôt volumineuse).
</p>
<p>
<p>
<prgn>madison</prgn> est un outil en ligne de commande qui est
disponible sur <tt>&ftp-master-host;</tt> et sur le miroir
- <tt>&ftp-master-mirror;</tt>. Il utilise un seul argument qui
+ <tt>&ftp-master-mirror;</tt>. Il utilise un seul paramètre qui
correspond au nom du paquet. Il affiche comme résultat quelle version
du paquet est disponible pour chaque combinaison d'architecture et de
distribution. Un exemple l'expliquera mieux.
</tag>
<item>
<p>
- (Ceci est une extension prévue). Les courriers de résumé réguliers
- sur l'état du paquet (statistiques sur les bogues, vue générale du
- portage, progression dans <em>testing</em>, etc.).
+ Des courriers de résumé réguliers sur l'état du paquet. Actuellement,
+ seule la progression du paquet dans <em>testing</em> est envoyée.
</p>
</item>
</taglist>
DDTP</em></p></footnote>.
</p>
</item>
+ <tag>
+ <tt>derivatives</tt>
+ </tag>
+ <item>
+ <p>
+ Des informations sur les changements effectués sur le paquet dans les
+ distributions dérivées (par exemple, Ubuntu).
+ </p>
+ </item>
</taglist>
</p>
<sect1 id="pts-commands">
<p>
Inscrit <var>adresse</var> aux communications liées au paquet
source <var>paquet source</var>. L'adresse de l'expéditeur est
- utilisée si le second argument n'est pas présent. Si <var>paquet
+ utilisée si le second paramètre n'est pas présent. Si <var>paquet
source</var> n'est pas un paquet source valide, vous obtiendrez un
avertissement. Cependant, s'il s'agit d'un paquet binaire valide,
le PTS vous inscrira pour le paquet source correspondant.
<p>
Supprime une inscription précédente au paquet source <var>paquet
source</var> en utilisant l'adresse spécifiée ou l'adresse de
- l'expéditeur si le second argument n'est pas rempli.
+ l'expéditeur si le second paramètre n'est pas rempli.
+ </p>
+ </item>
+ <tag>
+ <tt>unsubscribeall [<adresse>]</tt>
+ </tag>
+ <item>
+ <p>
+ Supprime toutes les inscriptions précédentes de l'adresse spécifiée
+ ou de l'adresse de l'expéditeur si le second paramètre n'est pas
+ rempli.
</p>
</item>
<tag>
questionnaires debconf
</p>
</item>
+ <item>
+ <p>
+ <tt>derivatives</tt> : changements effectués sur le paquet
+ dans des distributions dérivées
+ </p>
+ </item>
<item>
<p>
<tt>upload-source</tt> : annonce d'un nouvel envoi de
<item>
<p>
Accepte (+) ou refuse (-) les courriers classés sous le(s)
- mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés.
+ mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
+ change l'ensemble par défaut des mots-clés acceptés par un
+ utilisateur.
+ </p>
+ </item>
+ <tag>
+ <tt>keywordall [<adresse>] {+|-|=} <liste de
+ mots-clés></tt>
+ </tag>
+ <item>
+ <p>
+ Accepte (+) ou refuse (-) les courriers classés sous le(s)
+ mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
+ change les mots-clés de toutes les inscriptions actuellement en cours
+ d'un utilisateur.
</p>
</item>
<tag>
</item>
</taglist>
</p>
+ <p>
+ L'utilitaire en ligne de commande <prgn>pts-subscribe</prgn> (du paquet
+ <package>devscripts</package>) peut être pratique pour s'inscrire
+ temporairement à certains paquets, par exemple après avoir fait une mise
+ à jour indépendante (NMU).
+ </p>
+
</sect1>
<sect1 id="pts-mail-filtering">
<heading>
bogue à l'installation du nouveau paquet sur les serveurs d'archivage
(voir <ref id="upload-bugfix">).
</p>
+ <p>
+ Lors de la fermeture de bogues de sécurité, incluez les numéros CVS ainsi
+ que « Closes: #nnnnn ». Ceci est utile l'équipe de sécurité
+ pour suivre les failles de sécurité. Si un envoi est effectué pour
+ corriger le bogue avant que l'identifiant de l'alerte soit connu, il est
+ conseillé de modifier l'entrée de changelog historique lors du prochain
+ envoi. Même dans ce cas, veuillez inclure tous les pointeurs disponibles
+ vers les informations de contexte dans l'entrée de changelog d'origine.
+ </p>
<p>
Plusieurs raisons nous poussent à demander aux responsables d'annoncer
leur intention :
</item>
</list>
</p>
+ <p>
+ Veuillez consulter <url
+ id="http://ftp-master.debian.org/REJECT-FAQ.html"> pour les raisons
+ courantes de rejet des nouveaux paquets.
+ </p>
</sect>
<sect id="changelog-entries">
<heading>
Les envois différés sont pour le moment réalisés <em>via</em> la file
différée sur gluck. Le répertoire d'envoi est
<ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>. 0-day est
- envoyé approximativement une heure avant l'exécution de dinstall.
+ envoyé approximativement plusieurs fois par jour vers ftp-master.
</p>
<p>
Avec une version assez récente de dput, cette section
Envois de sécurité
</heading>
<p>
- N'envoyez PAS un paquet vers la file d'envoi de sécurité
+ N'envoyez <strong>PAS</strong> un paquet vers la file d'envoi de sécurité
(<em>oldstable-security</em>, <em>stable-security</em>, etc.) sans
avoir obtenu au préalable l'autorisation de l'équipe de sécurité. Si
le paquet ne correspond pas tout à fait aux besoins de cette équipe,
l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore les
rapports dans le système de suivi des bogues une fois que vous avez
reçu l'avis indiquant que votre nouveau paquet a été installé dans
- l'archive.
+ l'archive. Le bogue devrait être fermé avec la bonne version.
</p>
<p>
Cependant, il est possible d'éviter d'avoir à fermer manuellement les
fichier <file>changelog</file>.
</p>
<p>
- Si un envoi est identifié comme une <qref id="nmu">mise à jour
- indépendante (NMU)</qref> (et c'est le cas si le nom de la personne
- qui a réalisé ce changement n'est pas exactement le même que celui de
- l'un des responsables ou expéditeurs, sauf si le responsable est le
- groupe d'Assurance Qualité), le bogue est alors marqué <tt>fixed</tt>
- (corrigé) au lieu d'être fermé. Si un envoi de responsable a pour
- cible <em>experimental</em>, l'étiquette
- <tt>fixed-in-experimental</tt> est alors ajoutée au bogue ; pour
- les mises à jour indépendantes, l'étiquette <tt>fixed</tt> (corrigé)
- est utilisée (il est attendu que la règle spéciale pour
- <em>experimental</em> sera modifiée dès que le suivi des versions sera
- ajouté au système de suivi des bogues).
+ À moins que cela soit spécifié différemment par l'option <var>-v</var> de
+ <prgn>dpkg-buildpackage</prgn>, seuls les bogues fermés dans l'entrée de
+ changelog la plus récente sont fermés (fondamentalement, seuls les
+ bogues mentionnés dans la partie de changelog du fichier
+ <file>.changes</file> sont fermés).
+ </p>
+ <p>
+ <!-- les bogues des envois ... ? -->
+ Historiquement, les envois identifiés comme <qref id="nmu">Mise à jour
+ indépendante</qref> (« Non-maintainer upload » ou NMU) étaient
+ marqués comme <tt>fixed</tt> au lieu d'être fermés, mais cette pratique
+ a cassé avec l'ajout du suivi des versions. Le même raisonnement
+ s'applique à l'étiquette <tt>fixed-in-experimental</tt>.
</p>
<p>
Si vous entrez un numéro de bogue incorrect ou si vous oubliez un
bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
ont été corrigés par votre envoi, envoyez le fichier
<file>.changes</file> à <email>XXX-done@&bugs-host;</email> où
- <var>XXX</var> est le numéro du bogue.
+ <var>XXX</var> est le numéro du bogue et placez « Version:
+ YYY » et une ligne vide dans les deux premières lignes du corps du
+ courrier où <var>YYY</var> est la première version dans laquelle le
+ bogue a été corrigé.
</p>
<p>
Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en
<p>
si le problème est grave, il est préférable de partager cette
information avec d'autres vendeurs et de coordonner une
- diffusion. L'équipe de sécurité garde des contacts avec les
+ publication. L'équipe de sécurité reste en contact avec les
différentes organisations et individus et peut prendre soin des
actions à mener.
</p>
</p>
<p>
Si une personne de l'équipe de sécurité accepte un paquet, il sera
- installé sur security.debian.org ainsi que dans le répertoire
- <var>distribution</var>-proposed-updates qui convient sur ftp-master
- ou dans l'archive non-US.
+ installé sur security.debian.org et proposé pour le répertoire
+ <var>distribution</var>-proposed-updates qui convient sur ftp-master.
</p>
</sect2>
</sect1>
modifiez les informations de contrôle du paquet pour le placer dans la
section désirée et téléchargez à nouveau votre paquet dans
l'archive. Reportez-vous à la <url id="&url-debian-policy;"
- name="charte Debian"> pour en savoir plus. Si votre nouvelle section
+ name="charte Debian"> pour en savoir plus. Vous devez vous assurer
+ d'inclure le fichier <file>.orig.tar.gz</file> dans votre envoi (même si
+ vous n'envoyez pas de nouvelle version amon) ou il n'apparaîtra pas dans
+ la nouvelle section avec le reste du paquet. Si votre nouvelle section
est valide, il sera déplacé automatiquement. Si ce n'est pas le cas,
contactez les responsables ftp pour comprendre ce qui s'est passé.
</p>
<em>testing</em> n'en dépend.
</p>
<p>
- Vous devez également détailler les raisons justifiant cette
+ Il existe une exception pour laquelle il n'est pas nécessaire de faire
+ une demande explicite de suppression : si un paquet (source ou
+ binaire) est orphelin, il sera supprimé de façon semi-automatique. Pour
+ un paquet binaire, cela veut dire s'il n'y a plus de paquet source
+ produisant le paquet binaire ; si le paquet binaire n'est
+ simplement plus produit pour certaines architectures, une demande de
+ suppression est toujours nécessaire. Pour un paquet source, cela veut
+ dire que tous les paquets binaires auxquels il se réfère ont été
+ récupérés par un autre paquet source.
+ </p>
+ <p>
+ Vous devez détailler dans votre demande de suppressions les raisons
+ justifiant cette
demande. Ceci a pour but d'éviter les suppressions non désirées et de
garder une trace de la raison pour laquelle un paquet a été
supprimé. Par exemple, vous pouvez fournir le nom du paquet qui
programme <prgn>apt-cache</prgn> du paquet <package>apt</package>
pourra aussi vous être utile. La commande <tt>apt-cache showpkg
<var>paquet</var> </tt> vous indiquera, entre autres, les paquets qui
- dépendent de <var>paquet</var>. Le retrait de paquets orphelins est
- discuté sur &email-debian-qa;.
+ dépendent de <var>paquet</var>.
+ Parmi d'autres programmes utiles, citons <tt>apt-cache rdepends</tt>,
+ <prgn>apt-rdepends</prgn> et <prgn>grep-dctrl</prgn>.
+ Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
</p>
<p>
Une fois que le paquet a été supprimé, les bogues du paquet doivent
les porteurs doivent manipuler un grand nombre de paquets. À nouveau,
la situation diffère selon la distribution visée. Elle varie
également selon que l'architecture est candidate pour inclusion dans
- la prochaine version stable ; les responsables de diffusion
+ la prochaine version stable ; les responsables de publication
décident et annoncent quelles architectures sont candidates.
</p>
<p>
de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
recommandations communément acceptées). Pour les envois de
<em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous
- coordonner avec l'équipe de diffusion appropriée.
+ coordonner avec l'équipe de publication appropriée.
</p>
<p>
Deuxième différence, les porteurs qui font des mises à jour
</p>
<p>
La raison principale pour laquelle une mise à jour indépendante est
- réalisée est quand un développeur a besoin de corriger des paquets d'un
+ réalisée est quand un développeur a besoin de corriger le paquet d'un
autre développeur pour résoudre des problèmes sérieux ou des bogues
paralysants ou quand le responsable d'un paquet ne peut pas fournir une
correction dans un délai raisonnable.
</p>
<p>
Pour la distribution <em>testing</em>, les règles peuvent être
- changées par les responsables de diffusion. Veuillez porter une
+ changées par les responsables de publication. Veuillez porter une
attention spéciale au fait que le moyen habituel pour un paquet
d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
</p>
une entrée dans le fichier <file>changelog</file> qui indique les
bogues corrigés et qui précise pourquoi cette mise à jour était
nécessaire. Cette entrée comportera l'adresse de la personne ayant
- fait la mise à jour ainsi que la version livrée.
+ fait l'envoi ainsi que la version livrée.
</p>
<p>
Par convention, dans le cas d'une mise à jour indépendante source
</p>
<p>
Après avoir fait une mise à jour indépendante, il vous faudra aussi
- envoyer cette information aux bogues existants que vous avez corrigés
- par votre NMU en incluant le diff unifié. Sinon, vous pouvez créer un
+ envoyer l'information aux bogues existants que vous avez corrigés
+ par votre NMU en incluant le diff unifié. Historiquement, c'était une
+ habitude de créer un
nouveau rapport de bogue et inclure un correctif comprenant toutes les
modifications que vous avez réalisées. Le responsable officiel pourra
choisir d'appliquer le correctif, il pourra aussi employer une autre
Les paquets faisant l'objet d'une mise à jour indépendante source sont
construits comme les autres. Sélectionnez une distribution en
utilisant les règles décrites dans la section <ref id="distribution">
- en suivant toutes les prescriptions de la section <ref id="upload">.
+ en suivant toutes les instructions de la section <ref id="upload">.
</p>
<p>
Vérifiez que vous n'avez pas modifié la valeur du champ
id="&url-debian-qa-orphaned;">. Si vous effectuez une mise à jour
indépendante sur un paquet incorrectement orphelin, veuillez
positionner le responsable à « Debian QA Group
- <packages@qa.debian.org> ». Dans ce cas, les bogues du
- paquet sont fermés et pas simplement marqués comme corrigés.
+ <packages@qa.debian.org> ».
</p>
</sect1>
<sect1 id="nmu-who">
toujours les correctifs et les rapports de bogue soignés.
</p>
</sect1>
- <sect1 id="nmu-katie">
- <heading>
- Comment dak détecte les mises à jour indépendantes
- </heading>
- <p>
- Le fait qu'un envoi soit traité par les scripts d'archive et par le
- système de suivi des bogues (voir <ref id="nmu-patch">) comme une mise
- à jour indépendante ou comme un envoi par le responsable <em>n'est
- pas</em> décidé en regardant le numéro de version (voir <ref
- id="nmu-version">). Au lieu de cela, un envoi est géré comme une mise
- à jour indépendante si l'adresse du responsable dans le fichier
- <tt>.changes</tt> n'est pas la même binairement que l'adresse du champ
- <tt>Maintainer</tt> ou que l'une des adresses du champ
- <tt>Uploaders</tt> du fichier <tt>dsc</tt> et également si l'adresse
- du responsable n'est pas spéciale (c.-à-d. elle n'est pas positionnée
- à l'adresse du groupe d'Assurance Qualité).
- </p>
- </sect1>
<sect1 id="nmu-terms">
<heading>
Terminologie
paquet : ceci ne se produit que pour permettre à un
<em>autre</em> paquet d'entrer, ce dernier doit être prêt pour tous
les autres critères. Considérons, par exemple, qu'un paquet
- <em>a</em> est en conflit avec la nouvelle version de
+ <em>a</em> ne peut pas être installé avec la nouvelle version de
<em>b</em> alors <em>a</em> peut être supprimé pour permettre
l'entrée de <em>b</em>.
</p>
<em>testing</em> : le paquet est trop bogué (et avoir un seul
bogue RC est suffisant pour être dans cet état).
</p>
+ <p>
+ De plus, si un paquet a été supprimé d'<em>unstable</em> et qu'aucun
+ paquet de <em>testing</em> n'en dépend plus, il sera alors
+ automatiquement supprimé.
+ </p>
+
</sect2>
<sect2 id="circular">
<heading>
</p>
<p>
Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
- diffusion. Veuillez les contacter en envoyant un courrier
+ publication. Veuillez les contacter en envoyant un courrier
électronique à debian-release@lists.debian.org si cela se produit
pour l'un de vos paquets.
</p>
valides. Cela donne le fichier « update excuses ». Les
raisons les plus communes pour lesquelles un paquet n'est pas
considéré sont la jeunesse du paquet, le nombre de bogues RC et la
- désynchronisation pour certaines architectures. Pour cette partie,
+ désynchronisation pour certaines architectures. Pour cette partie de britney,
les responsables de version ont des marteaux de toute taille pour
forcer britney à considérer un paquet. (Le gel de la base est
également codé dans cette partie de britney.) (Il y a une chose
<item>
<p>
après l'envoi et la construction réussie sur toutes les
- plates-formes, contactez l'équipe de diffusion à
+ plates-formes, contactez l'équipe de publication à
&email-debian-release; et demandez-leur d'approuver votre envoi.
</p>
</item>
paquets binaires différents, que ce soit pour fournir plusieurs
saveurs du même paquet (par exemple, le paquet source
<package>vim</package>) ou pour créer plusieurs petits paquets au lieu
- d'un seul gros (par exemple, si l'utilisateur peut n'installer que la
- partie nécessaire et ainsi économiser de l'espace disque).
+ d'un seul gros (afin, par exemple, que l'utilisateur puisse n'installer
+ que la partie nécessaire et ainsi économiser de l'espace disque).
</p>
<p>
Le second cas peut facilement être géré dans le fichier
<p>
C'est une vieille tradition de valider les bogues fixés par une mise à
jour indépendante dans la première entrée du changelog de l'envoi du
- vrai responsable. Veuillez utiliser l'option <tt>-v</tt> de
- <prgn>dpkg-buildpackage</prgn> pour fermer les rapports de bogue
- correspondants.
+ vrai responsable. Comme nous avons maintenant le suivi des versions, il
+ est suffisant de garder les entrées de changelog des mises à jour
+ indépendantes et de simplement mentionner ce fait dans votre propre
+ entrée de changelog.
</p>
</sect1>
<sect1 id="bpp-changelog-errors">
script de maintenance, la fonction de shell suivante conforme à POSIX
peut vous aider : &example-pathfind; Vous pouvez utiliser cette
fonction pour rechercher le <tt>$PATH</tt> pour un nom de commande
- passé en argument. Il renvoie vrai (zéro) si la commande a été trouvée
+ passé en paramètre. Il renvoie vrai (zéro) si la commande a été trouvée
et faux sinon. Il s'agit réellement de la façon la plus portable de
faire car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn>
ne sont pas POSIX.
boolean: (booléen)
</heading>
<p>
- Un choix vrai/faux. Rappelez-vous : vrai/faux, PAS OUI/NON...
+ Un choix vrai/faux. Rappelez-vous : vrai/faux, <strong>pas oui/non</strong>...
</p>
</sect3>
<sect3>
utilisez plutôt un autre paragraphe.
</p>
<p>
- Ne soyez pas trop verbeux. Certaines interfaces debconf ne gèrent pas
- très bien les descriptions de plus de 20 lignes, essayez donc de
- les conserver sous cette limite.
+ Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ignorer les
+ écrans trop longs. Par expérience, 20 lignes est la limite à
+ éviter de dépasser car cela veut dire sinon que, dans l'interface dialogue
+ classique, les utilisateurs devront faire défiler le texte et un grand
+ nombre de personnes ne le font simplement pas.
</p>
<p>
Pour des règles spécifiques selon le type de questionnaire (chaîne de
<list>
<item>
<p>
- La description courte est une invite et NON un titre. Évitez des
- invites de style question (« IP Address? ») en faveur
- d'invites « ouvertes »à (« IP
- address: »). L'utilisation des deux-points est recommandée.
+ La description courte est une invite et <strong>non</strong> un
+ titre. Évitez des invites de style question (« IP
+ Address? ») en faveur d'invites « ouvertes »à
+ (« IP address: »). L'utilisation des deux-points est
+ recommandée.
</p>
</item>
<item>
</item>
<item>
<p>
- La description étendue ne devrait PAS inclure de question.
+ La description étendue ne devrait <strong>pas</strong> inclure de
+ question.
</p>
</item>
<item>
<list>
<item>
<p>
- La description courte est une invite et NON un titre. N'utilisez
- PAS des constructions inutiles du type « Please
- choose... ». Les utilisateurs sont assez intelligents pour
- réaliser qu'ils doivent choisir quelque chose...:)
+ La description courte est une invite et <strong>non</strong> un
+ titre. N'utilisez <strong>pas</strong> des constructions inutiles
+ du type « Please choose... ». Les utilisateurs sont assez
+ intelligents pour réaliser qu'ils doivent choisir quelque chose...:)
</p>
</item>
<item>
</item>
<item>
<p>
- N'ABUSEZ PAS DE DEBCONF. Les notes sont le moyen le plus courant
+ <strong>N'abusez pas de debconf.</strong> Les notes sont le moyen le plus courant
d'abus de debconf. Comme il est écrit dans la page de manuel de
debconf-devel : il est préférable de ne les utiliser que
pour des avertissements à propos de problèmes très sérieux. Les
Default.
</p>
<p>
- Si vous utilisez po-debconf (et vous DEVRIEZ le faire, voir 2.2),
+ Si vous utilisez po-debconf (et vous <strong>devriez</strong> le faire, voir 2.2),
veuillez considérer de rendre ce champ traduisible, si vous pensez
qu'il peut être traduit.
</p>
quels paquets peuvent être enlevés sans problème du système, i.e. ceux
dont aucun paquet ne dépend. L'opération par défaut est de chercher
seulement parmi les sections libs et oldlibs pour débusquer les
- bibliothèques inutilisées. Mais si l'on passe le bon argument, il
+ bibliothèques inutilisées. Mais si l'on passe le bon paramètre, il
tente d'attraper d'autres paquets inutiles.
</p>
<p>
<p>
Il décompacte l'archive tar dans un répertoire temporaire vide par
<example>
-zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -</example>
+zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -
+ </example>
</p>
</item>
<item>
semblable) <footnote><p>Le fichier devrait avoir un nom qui indique
clairement quel fichier binaire il encode. Habituellement, un
postfixe indiquant le codage devrait être ajouté au nom du fichier
- d'origine.</p></footnote>. Le fichier sera ensuite décodé et copié à
+ d'origine. Notez que vous n'avez pas besoin de dépendre de
+ <package>sharutils</package> pour avoir le programme
+ <prgn>uudecode</prgn> si vous utilisez la fonction <tt>pack</tt> de
+ <prgn>perl</prgn>. Le code pourrait ressembler à ceci :
+ <example>
+uuencode-file:
+ perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
+
+uudecode-file:
+ perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
+ </example>
+ </p></footnote>. Le fichier sera ensuite décodé et copié à
son emplacement pendant l'étape de construction. Le changement sera
donc visible assez facilement.
</p>
d'éviter que plusieurs responsables ne rédigent les mêmes rapports de
bogue simultanément.
</p>
+ <p>
+ Veuillez utiliser les programmes <prgn>dd-list</prgn> et si nécessaire,
+ <prgn>whodepends</prgn> (du paquet <package>devscripts</package>) pour
+ générer une liste de tous les paquets concernés et incluez la sortie
+ dans votre courrier à &email-debian-devel;.
+ </p>
<p>
Quand vous envoyez un grand nombre de rapports sur le même sujet, vous
devriez les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils
QA contacte un responsable inactif ou trouve plus d'informations sur
celui-ci, c'est enregistré dans la base de données MIA. Ce système est
disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut
- être interrogé avec un outil de nom <prgn>mia-history</prgn>. Par
- défaut, <prgn>mia-history</prgn> affiche des informations sur toutes
- les personnes qu'il connaît, mais il accepte des expressions
- rationnelles comme paramètre qu'il utilise comme correspondance de noms
- d'utilisateur.
- <example>mia-history --help</example>
- affiche quels paramètres sont acceptés. Si vous déterminez qu'aucune
+ être interrogé avec un outil de nom <prgn>mia-query</prgn>.
+ Utilisez <example>mia-query --help</example> pour voir comment interroger
+ la base de données. Si vous déterminez qu'aucune
information n'a encore été enregistrée pour un responsable inactif ou
si vous voulez ajouter plus d'informations, vous deviez utiliser la
procédure suivante.
</list>
</p>
<p>
- Un gros problème est représenté par les paquets parrainés
+ Un problème particulier est représenté par les paquets parrainés
— le responsable n'est pas un développeur Debian
officiel. Les informations « echelon » ne sont pas
disponibles pour les personnes parrainées, par exemple, vous devez donc
trouver et contacter le responsable Debian qui a réellement envoyé le
paquet. Étant donné qu'il a signé le paquet, il est responsable de
- l'envoi de toute façon et il devrait savoir ce qui s'est passé avec la
- personne qu'il parraine.
+ l'envoi de toute façon et il est probable qu'il sait ce qui s'est passé
+ avec la personne qu'il parraine.
</p>
<p>
Il est également permis d'envoyer une demande à &email-debian-devel;
demandant si quelqu'un est au courant d'information sur le responsable
- manquant.
+ manquant. Veuillez mettre en CC: la personne en question.
</p>
<p>
Une fois que vous avez réuni toutes ces informations, vous pouvez
l'envie, il devrait « laisser filer » et donner le paquet à
quelqu'un ayant plus de temps.
</p>
+ <p>
+ Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez
+ étudier le fichier README dans /org/qa.debian.org/mia sur qa.debian.org
+ où les détails techniques et les procédures MIA sont documentées et
+ contactez &email-mia;.
+ </p>
</sect>
<sect id="newmaint">
<heading>
~ianmdlvl / developers-reference.git / commitdiff