+<p>
+La maintenance collective peut souvent être facilitée par l'utilisation
+d'outils sur Alioth (voir <ref id="alioth">).
+ </sect>
+
+ <sect id="testing">
+ <heading>La distribution <em>testing</em></heading>
+ <p>
+ <sect1 id="testing-basics">
+ <heading>Bases</heading>
+ <p>
+Les paquets sont habituellement installés dans la distribution <em>testing</em>
+après avoir atteint un certain degré de test dans <em>unstable</em>.
+ <p>
+Ils doivent être en synchronisation pour toutes les architectures et ne doivent
+pas avoir de dépendances qui les rendraient ininstallables ; ils doivent
+également n'avoir aucun bogue bloquant l'inclusion du paquet dans une version
+stable (« release-critical ») au moment où ils sont installés dans
+<em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête pour être
+une version candidate stable. Veuillez voir ci-dessous pour les détails.
+
+ <sect1 id="testing-unstable">
+ <heading>Mises à jour depuis <em>unstable</em></heading>
+ <p>
+Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
+ chaque jour après l'installation des paquets mis à jour. Ils fabriquent les
+ fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
+ le font d'une manière intelligente pour éviter toute incohérence et essayer de
+ n'utiliser que des paquets sans bogue.
+ <p>
+L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
+suivantes :
+<list>
+ <item>
+Le paquet doit avoir été disponible dans <em>unstable</em> depuis 2, 5 ou
+10 jours selon le champ d'urgence de l'envoi (élevée, moyenne ou basse).
+Veuillez noter que cette urgence est « collante » (« sticky »), ce qui
+veut dire que l'envoi avec l'urgence la plus élevée depuis la précédente
+transition dans <em>testing</em> est prise en compte. Ces délais peuvent être
+doublés lors d'un gel de distribution, ou les transitions dans <em>testing</em>
+peuvent être complètement désactivées ;
+ <item>
+Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
+version actuellement disponible dans <em>testing</em> ;
+ <item>
+Il doit être disponible pour toutes les architectures pour lesquelles
+il a été auparavant construit. <ref id="madison"> peut être
+intéressant pour vérifier cette information ;
+ <item>
+Il ne doit pas casser les dépendances d'un paquet qui est déjà
+disponible dans <em>testing</em> ;
+ <item>
+Les paquets dont il dépend doivent soit être déjà disponibles dans
+<em>testing</em> soit être acceptés dans <em>testing</em> au
+même moment (et ils doivent remplire tous les critères nécessaires).
+</list>
+ <p>
+Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
+sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
+id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
+inclus dans le paquet <package>devscripts</package>. Si vous voulez rester
+informé de la progression de vos paquets dans <em>testing</em>, vous pouvez
+facilement le mettre dans la <manref section="5" name="crontab">.
+ <p>
+Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
+ pour laquelle un paquet est refusé ; on peut avoir à la chercher soi-même en
+ regardant ce qui serait cassé avec l'inclusion du paquet. La <url
+ id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
+ d'informations à propos des problèmes courants qui peuvent occasionner cela.
+ <p>
+Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
+ jeu des inter-relations est trop compliqué et ne peut être résolu par le
+ script. Voir ci-dessous pour des détails.
+ <p>
+Des analyses de dépendances plus avancées sont présentées sur
+<url id="http://bjorn.haxx.se/debian/"> — mais, attention, cette page affiche
+également les dépendances de construction qui ne sont pas considérées par
+britney.
+
+ <sect2 id="outdated">
+ <heading>Désynchronisation</heading>
+ <p>
+<!-- FIXME: better rename this file than document rampant professionalism? -->
+Pour le script de migration dans <em>testing</em>, « désynchronisé »
+(<em>outdated</em> veut dire ceci : il y a différentes versions dans
+<em>unstable</em> pour les architectures de version (à l'exception des
+architectures dans fuckedarches ; fuckedarches est une liste des
+architectures qui ne suivent pas le rythme (dans update_out.py), mais
+actuellement cette liste est vide). « Désynchronisé » n'a rien à voir
+avec les architectures que le paquet fournit pour <em>testing</em>.
+ <p>
+Considérons cet exemple :
+ <p>
+ <example>
+foo | alpha | arm
+---------+-------+----
+testing | 1 | -
+unstable | 1 | 2
+</example>
+ <p>
+Le paquet est désynchronisé pour alpha dans <em>unstable</em> et n'entrera pas
+dans <em>testing</em>. Supprimer foo de <em>testing</em> n'aiderait en rien, le
+paquet serait toujours désynchronisé pour alpha et ne se propagerait pas dans
+<em>testing</em>.
+ <p>
+Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici pour arm) :
+ <p>
+ <example>
+foo | alpha | arm | hurd-i386
+---------+-------+-----+----------
+testing | 1 | 1 | -
+unstable | 2 | - | 1
+ </example>
+ <p>
+Dans ce cas, le paquet est synchronisé pour toutes les architectures de version
+dans <em>unstable</em> (et l'architecture supplémentaire hurd-i386 ne compte pas
+car ce n'est pas une architecture de version).
+ <p>
+Quelquefois, la question est soulevée pour savoir s'il est possible de permettre
+à des paquets de passer dans <em>testing</em> qui ne sont pas encore construits
+pour toutes les architectures : non. Simplement non. (Excepté si vous êtes
+responsable de glibc ou équivalent).
+
+ <sect2 id="removals">
+ <heading>Suppressions de <em>testing</em></heading>
+ <p>
+Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
+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>b</em> alors <em>a</em> peut être supprimé pour permettre l'entrée de <em>b</em>.
+ <p>
+Bien sûr, il existe une autre raison pour supprimer un paquet de
+<em>testing</em> : le paquet est trop bogué (et avoir un seul bogue RC est
+suffisant pour être dans cet état).
+
+ <sect2 id="circular">
+ <heading>Dépendances circulaires</heading>
+ <p>
+Une situation qui n'est pas très bien gérée par britney est si un paquet <em>a</em>
+dépend de la nouvelle version d'un paquet <em>b</em> et vice versa.
+ <p>
+Voici un exemple :
+ <p>
+ <example>
+ | testing | unstable
+--+-----------------+------------
+a | 1; dépend: b=1 | 2; dépend: b=2
+b | 1; dépend: a=1 | 2; dépend: a=2
+ </example>
+ <p>
+Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour mise à jour.
+ <p>
+Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
+diffusion. Veuillez les contacter en envoyant un courrier électronique à
+debian-release@lists.debian.org si cela se produit pour l'un de vos paquets.
+
+
+ <sect2>
+ <heading>Influence de paquet dans <em>testing</em></heading>
+ <p>
+Généralement, l'état d'un paquet dans <em>testing</em> ne change rien pour la
+transition de la prochaine version d'<em>unstable</em> vers <em>testing</em>,
+avec deux exceptions : si le nombre de bogues RC du paquet est réduit, le
+paquet peut migrer même s'il a encore des bogues RC. La seconde exception est
+que si la version du paquet dans <em>testing</em> est désynchronisée entre les
+différentes architectures, alors toute architecture peut être mise à jour vers
+la version du paquet source ; cependant, cela ne peut se produire que si le
+paquet a été précédemment forcé, si l'architecture est dans fuckedarches ou s'il
+n'y avait pas du tout de paquet binaire de cette architecture présent dans
+<em>unstable</em> lors de la migration dans <em>testing</em>.
+ <p>
+En résumé, cela veut dire : la seule influence qu'un paquet de
+<em>testing</em> a sur la nouvelle version du même paquet est que la nouvelle
+version peut rentrer plus facilement.
+
+ <sect2 id="details">
+ <heading>Détails</heading>
+ <p>
+Si vous êtes intéressé par les détails, voici comment fonctionne britney :
+ <p>
+Les paquets sont examinés pour savoir si ce sont des candidats 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, 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 semblable pour les mises à jour
+binaires pures, mais cela n'est pas décrit ici. Si vous êtes intéressé par cela,
+veuillez étudier attentivement le code.)
+ <p>
+Maintenant, la partie la plus complexe se produit : britney tente de mettre
+à jour <em>testing</em> avec des candidats valides ; en premier, chaque
+paquet individuellement, puis des groupes de plus en plus larges de paquets
+ensemble. Chaque tentative est acceptée si <em>unstable</em> n'est pas moins
+ininstallable après la mise à jour qu'avant celle-ci. (Avant et après cette
+partie, certains coups de pouce sont traités ; mais, comme seuls les
+responsables de version peuvent positionner des coups de pouce, cela n'est
+probablement pas très important pour vous.)
+ <p>
+Si vous voulez voir plus de détails, vous pouvez le voir dans
+merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
+~aba/testing/update_out pour voir une configuration avec un fichier de paquets
+plus petit). Par le web, c'est à <url
+id="http://ftp-master.debian.org/testing/update_out_code/">.
+ <p>
+Les coups de pouce sont visibles sur <url
+id="http://ftp-master.debian.org/testing/hints/">.
+
+
+ <sect1 id="t-p-u">
+ <heading>Mises à jour directes dans <em>testing</em></heading>
+ <p>
+La distribution <em>testing</em> est peuplée avec des paquets en provenance
+d'<em>unstable</em> selon des règles expliquées ci-dessus. Cependant, dans
+certains cas, il est nécessaire d'envoyer des paquets construits seulement pour
+<em>testing</em>. Pour cela, vous pouvez envoyer vos paquets vers
+<em>testing-proposed-updates</em>.
+ <p>
+Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
+ils doivent passer entre les mains du responsable de distribution. Vous devez
+donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
+représente une bonne raison aux yeux des responsables de distribution, vous
+devriez lire les instructions données qu'ils envoient régulièrement sur
+&email-debian-devel-announce;.
+ <p>
+Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
+vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
+autrement (par exemple, parce que vous avez une nouvelle version de
+développement dans <em>unstable</em>), vous pouvez utiliser cette facilité, mais il est
+recommandé de demander l'autorisation du responsable de distribution auparavant.
+Même si un paquet est gelé, des mises à jour par <em>unstable</em> sont possibles
+si l'envoi dans <em>unstable</em> ne tire pas de nouvelles dépendances.
+ <p>
+Les numéros de version sont habituellement choisis en ajoutant le nom de
+code de la distribution <em>testing</em> et un numéro incrémenté, comme
+1.2sarge1 pour le premier envoi dans <em>testing-proposed-updates</em> du paquet
+en version 1.2.
+ <p>
+Veuillez vous assurer que vous n'oubliez aucun des éléments suivants lors de
+votre envoi :
+<list>
+<item> vérifiez que votre paquet doit vraiment aller dans
+<em>testing-proposed-updates</em> et ne peut pas passer par
+<em>unstable</em> ;
+<item> vérifiez que vous n'incluez que le minimum de changements ;
+<item> vérifiez que vous incluez une explication appropriée dans le
+changelog ;
+<item> vérifiez que vous avez bien indiqué <em>testing</em> ou
+<em>testing-proposed-updates</em> comme votre distribution cible ;
+<item> vérifiez que vous avez construit et testé votre paquet dans
+<em>testing</em> et non dans <em>unstable</em> ;
+<item> vérifiez que votre numéro de version est plus élevé que les versions de
+<em>testing</em> et de <em>testing-proposed-updates</em> et moins élevé que
+celle de <em>unstable</em> ;
+<item> après l'envoi et la construction réussie sur toutes les plates-formes,
+contactez l'équipe de diffusion à &email-debian-release; et demandez-leur
+d'approuver votre envoi.
+</list>
+
+
+ <sect1 id="faq">
+ <heading>Questions fréquemment posées</heading>
+ <p>
+
+ <sect2 id="rc">
+ <heading>Qu'est-ce que sont les bogues bloquant l'intégration dans la
+ version stable et comment sont-ils comptés ?</heading>
+ <p>
+Tous les bogues de gravité assez élevée sont par défaut considérés
+comme bloquant l'intégration du paquet dans la version stable ;
+actuellement, ce sont les bogues critiques, graves et sérieux.
+ <p>
+Certains bogues sont supposés avoir un impact sur les chances que le paquet a
+d'être diffusé dans la version stable de Debian : en général, si un paquet
+a des bogues bloquants, il n'ira pas dans <em>testing</em> et par conséquent,
+ne pourra pas être diffusé dans <em>stable</em>.
+ <p>
+Le compte des bogues d'<em>unstable</em> est effectué avec tous les bogues
+bloquants sans étiquette de version (comme <em>potato</em>, <em>woody</em>) ou
+avec une étiquette <em>sid</em> et également s'ils ne sont ni corrigés ou
+marqués avec <em>sarge-ignore</em>.
+Le compte des bogues de <em>testing</em> pour un paquet est condiséré comme à
+peu près le nombre de bogues d'<em>unstable</em> lors du dernier pointage quand
+la version <em>testing</em> a été égale à la version <em>unstable</em>.
+ <p>
+Cela changera après la sortie de <em>Sarge</em> dès que nous aurons des versions
+dans le système de suivi des bogues.
+
+ <sect2>
+ <heading>Comment est-ce que l'installation d'un paquet dans
+ <em>testing</em> peut casser d'autres paquets ?</heading>
+ <p>
+La structure des archives de la distribution est faite de telle façon qu'elles
+ne peuvent contenir qu'une version d'un paquet ; un paquet est défini par
+son nom. Donc, quand le paquet source acmefoo est installé dans
+<em>testing</em> avec ses paquets binaires acme-foo-bin, acme-bar-bin,
+libacme-foo1 et libacme-foo-dev, l'ancienne version est supprimée.
+ <p>
+
+Cependant, l'ancienne version pouvait fournir à un paquet binaire un vieux
+soname d'une bibliothèque, comme libacme-foo0. Supprimer l'ancien acmefoo va
+supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.
+ <p>
+Évidemment, cela touche principalement des paquets qui fournissent des jeux
+changeants de paquets binaires dans différentes version (par suite,
+principalement des bibliothèques). Cependant, cela va aussi toucher des paquets
+sur lesquels une dépendance versionnée a été déclarée du type ==, <= ou <<.
+ <p>
+Quand le jeu de paquets binaires fournis par un paquet source change de cette
+façon, tous les paquets qui dépendent des anciens binaires doivent être mis à
+jour pour dépendre de la nouvelle version à la place. Comme l'installation d'un
+tel paquet source dans <em>testing</em> casse tous les paquets qui en dépendent
+dans <em>testing</em>, une certaine attention doit y être portée : tous les
+paquets en dépendant doivent être mis à jour et prêts à être installés eux-même
+pour qu'ils ne cassent pas et, une fois que tout est prêt, une intervention
+manuelle du responsable de version ou d'un de ses assistants est normalement
+requise.
+ <p>
+Si vous avez des problèmes avec des groupes compliqués de paquets comme ceci,
+contactez debian-devel ou debian-release en demandant de l'aide.
+ </sect>
+