<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.19 $">
+ <!entity cvs-rev "$Revision: 1.20 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
<book>
-<title>Manuel de référence du développeur Debian
+<title>Référence du développeur Debian
<author>Adam Di Carlo, responsable actuel <email>aph@debian.org</email>
<author>Christian Schwarz <email>schwarz@debian.org</email>
<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
<author>
-<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.fr</email>
-<author>avec la participation de Alain Meessen
-<author>et des membres de la liste
+<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email>
+<author>et les membres de la liste
<email>debian-l10n-french@lists.debian.org</email>
<version>version &version;, &date-fr;
corrigés dans les prochaines versions. Il n'est pas de votre responsabilité
de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois,
si vous êtes capable de le faire, nous vous encourageons à contribuer au
-développement amont en proposant un <em>patch</em> qui corrige ce bogue.
-Les utilisateurs et responsables Debian proposent souvent des <em>patches</em>
-pour corriger des bogues amonts, il vous faudra alors évaluer ce
-<em>patch</em> puis le transmettre aux développeurs amonts.
+développement amont en proposant une rustine qui corrige ce bogue.
+Les utilisateurs et responsables Debian proposent souvent des rustines
+pour corriger des bogues amonts, il vous faudra alors évaluer cette
+rustine puis la transmettre aux développeurs amonts.
<p>
Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
-paquet conforme à la charte Debian, alors vous devriez proposer un
-<em>patch</em> aux développeurs amonts pour qu'il soit inclus dans leur
+paquet conforme à la charte Debian, alors vous devriez proposer une
+rustine aux développeurs amonts pour qu'elle soit incluse dans leur
version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des
mises à jour amonts suivantes. Quels que soient les changements dont vous
avez besoin, il faut toujours essayer de rester dans la lignée des sources
important car même une modification triviale peut causer un bogue plus
tard. Livrer une nouvelle version amont d'un logiciel pour corriger un
problème de sécurité est désapprouvé ; dans la plupart des cas la
-bonne solution consiste à prendre le <em>patch</em> correspondant de la
+bonne solution consiste à prendre la rustine correspondante de la
nouvelle version amont et à l'appliquer à l'ancienne (faire un
-<em>backport</em> du <em>patch</em>).
+portage (<em>backport</em>) de la rustine.
<p>
Les paquets livrés pour <em>stable</em> doivent être compilés avec la
indépendantes. Un responsable officiel est une personne dont la clé est dans
le porte-clés Debian. Toute personne est invitée à télécharger les paquets
sources pour corriger des bogues ; au lieu de faire des mises à jour
-indépendantes, ils pourront soumettre les <em>patch</em> qui le méritent au
+indépendantes, ils pourront soumettre les rustines qui le méritent au
système de suivi des bogues. Les responsables apprécient presque toujours les
-<em>patch</em> et les rapports de bogue soignés.
+rustines et les rapports de bogue soignés.
<sect id="nmu-when">Quand faire une mise à jour indépendante source ?
pour corriger le bogue. Donnez-lui quelques jours.
<item>
- Lancez-vous. Corrigez le bogue et envoyez votre <em>patch</em> au système de
+ Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de
suivi des bogues. Construisez le paquet et testez-le comme décrit dans
la section <ref id="upload-checking">. Utilisez le paquet chez vous.
Tout d'abord il est capital que ces mises à jour indépendantes soient aussi peu
intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
modules ou des fichiers, ne déplacez pas les répertoires ; plus généralement ne
-corrigez pas ce qui n'est pas cassé. Faites un <em>patch</em> aussi petit que
+corrigez pas ce qui n'est pas cassé. Faites une rustine aussi petite que
possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en
au responsable du paquet, au responsable amont ou soumettez un rapport de
bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent pas</em>
à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que
le responsable du paquet incorpore les modifications de cette mise à jour dans
la version officielle du paquet. Si nécessaire, ouvrez des rapports de bogue
-avec les <em>patch</em> correspondants ou assurez-vous que l'un des rapports de
-bogue déjà ouverts comporte ces <em>patch</em>.
+avec les rustines correspondantes ou assurez-vous que l'un des rapports de
+bogue déjà ouverts comporte ces rustines.
<p>
-Le responsable officiel pourra choisir d'appliquer le <em>patch</em>, il pourra aussi
+Le responsable officiel pourra choisir d'appliquer la rustine, il pourra aussi
employer une autre méthode pour régler le problème. Certains bogues sont
corrigés dans la version amont, ce qui est une bonne raison pour annuler les
modifications d'une mise à jour indépendante. Si le responsable choisit de
-mettre à jour le paquet sans utiliser les <em>patch</em> de la mise à jour
+mettre à jour le paquet sans utiliser les rustines de la mise à jour
indépendante, il devra s'assurer que cette nouvelle version corrige
effectivement chacun des bogues corrigés dans la mise à jour indépendante.