<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.59 $">
+ <!ENTITY cvs-rev "$Revision: 1.60 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!-- <!ENTITY cvs-en-rev "1.282"> -->
<p>
Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple, par
courriels privés) devraient également envoyer des messages à cette liste
-et un développeur expériementé se proposera de les aider.
+et un développeur expérimenté se proposera de les aider.
<p>
De plus, si vous avez des paquets prêts à être inclus dans Debian, mais que
vous attendez que votre demande pour devenir responsable soit acceptée,
distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui
contient les sources du programme. Si un paquet est distribué ailleurs, le
fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source
- amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur
+ amont</em>, c'est-à-dire, le code source distribué par le <em>responsable
amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier
<file>.diff.gz</file> contient les modifications faites par le responsable
Debian.
<item>Tout courrier non automatique envoyé au PTS par les personnes qui
veulent contacter les inscrits au paquet. Ceci peut être fait en
envoyant un courrier à <tt><var>paquet-source</var>@&pts-host;</tt>. Pour
- prévenir l'envoi de spam, tous les courriers envoyés à ces adresses doivent
+ prévenir l'envoi de pourriels, tous les courriers envoyés à ces adresses doivent
contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
<tag><tt>summary</tt>
que dans les cas suivants :
<list>
<item>un problème fonctionnel vraiment critique,
-<item>un paquet devenu ininstallable,
+<item>un paquet devenu non installable,
<item>un paquet indisponible pour une architecture.
</list>
<p>
bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
Modifier les dépendances d'autres paquets (en manipulant le champ
<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
- ininstallables, est fortement déconseillé.
+ non installables, est fortement déconseillé.
<p>
L'équipe responsable de la distribution<footnote><em>the Release
team</em></footnote> (joignable à l'adresse &email-debian-release;)
paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
fasse une livraison basée sur une nouvelle version amont, cette personne doit
- choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
+ choisir « 0.1 » comme numéro de révision Debian. Le responsable du
paquet doit, lui, démarrer sa numérotation à « 1 ».
<p>
Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, vous devrez
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
+pas avoir de dépendances qui les rendraient non installables ; 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
à 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
+non installable 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.)
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 à
+Le compte des bogues de <em>testing</em> pour un paquet est considé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>
<p>
<list>
<item> La description courte devrait être rédigée sous la forme d'une question
- qui devrait être gardée courte et devrait généralement se termier par un
+ qui devrait être gardée courte et devrait généralement se terminer par un
point d'interrogation. Un style d'écriture concis est permis et même
encouragé si la question est plutôt longue (rappelez-vous que les
traductions sont souvent plus longue que les versions d'origine)
référer aux choix disponibles. Elle peut également mentionner que
l'utilisateur peut choisir plus d'un des choix disponibles si le
questionnaire est du type sélection multiple (bien que l'interface rende
- soivent cela clair).
+ souvent cela clair).
</list>
<sect3>Notes
le paquet source <package>camlzip</package>.
</item>
<item>
- Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
+ Les paquets fournissant des DTD XML ou SGML devraient se conformer aux
recommandations que l'on peut trouver dans le paquet
<package>sgml-base-doc</package>
<item>
</p>
</sect2>
<sect2 id="repackaged origtargz">
- <heading>Réempaquetage des sources amonts</heading>
+ <heading>Réempaquetage des sources amont</heading>
<p>
Vous <strong>devriez</strong> envoyer des paquets sources avec une
archive tar vierge si possible, mais il peut y avoir diverses raisons
</p>
<p>
Dans tous ces cas, le développeur doit construire un fichier
-.orig.tar.gz convenable lui-même. Nous nous référérons à une telle
+.orig.tar.gz convenable lui-même. Nous nous référerons à une telle
archive tar comme un « source amont réempaqueté ». Notez qu'un
« source amont réempaqueté » est différent d'un paquet natif
Debian. Un source réempaqueté est toujours fourni avec des changements
comme en vacances dans la base de données.
<item>Le nombre de paquets de ce responsable et les conditions de ces
- paquets. En particulier, restent-ils des bogues empêchant
+ paquets. En particulier, reste-t-il des bogues empêchant
l'intégration du paquet dans la distribution qui sont ouverts
depuis des lustres ? De plus, combien de bogues y a-t-il en
général ? Un autre point d'information important est si les
~ianmdlvl / developers-reference.git / commitdiff