diff options
Diffstat (limited to 'fr_FR.ISO8859-1/htdocs/gnome/docs/bugging.xml')
| -rw-r--r-- | fr_FR.ISO8859-1/htdocs/gnome/docs/bugging.xml | 149 |
1 files changed, 149 insertions, 0 deletions
diff --git a/fr_FR.ISO8859-1/htdocs/gnome/docs/bugging.xml b/fr_FR.ISO8859-1/htdocs/gnome/docs/bugging.xml new file mode 100644 index 0000000000..41c1dd1294 --- /dev/null +++ b/fr_FR.ISO8859-1/htdocs/gnome/docs/bugging.xml @@ -0,0 +1,149 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN" +"http://www.FreeBSD.org/XML/doc/share/sgml/xhtml10-freebsd.dtd" [ +<!ENTITY title "Projet GNOME pour FreeBSD : rapporter un bug"> +]> + +<!-- + The FreeBSD French Documentation Project + Original revision: 1.11 + + Version francaise : Stephane Legrand <stephane@freebsd-fr.org> + Version francaise (mise a jour) : Vincent Tougait <viny@FreeBSD-FR.org> +--> + +<html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <title>&title;</title> + + <cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword> + </head> + + <body class="navinclude.developers"> + + <h2>1. Quoi rapporter ?</h2> + + <p>La première règle est : rapportez autant d'informations que vous + pouvez. Même s'il y a des informations inutiles les + développeurs pourront facilement les éliminer. Au contraire, la + situation est bien pire lorsqu'il n'y a pas assez d'informations + pour découvrir ou reproduire le problème - dans ce cas, les développeurs + devront perdre du temps à deviner et/ou demander des précisions à + l'auteur du rapport de bug.</p> + + <p>Il y a plein d'exemples de rapports de bugs totalement inutiles, du + genre <i>"Hé, le port de gnomebidule est cassé. J'utilise FreeBSD-X.Y. + Corrigez svp."</i> Inutile de dire que de tels rapports sont juste un gaspillage + de votre temps, du temps du développeur concerné et de bande passante. + Au strict minimum, le rapport doit inclure les informations + suivantes :</p> + + <ul> + <li><p>La version exacte du système d'exploitation (habituellement le résultat de + <tt>uname -a</tt>).</p></li> + <li><p>La liste de tous les paquetages installés sur votre système.</p></li> + <li><p>Votre environnement (le résultat de <tt>/usr/bin/env</tt>).</p></li> + <li><p>Si vous faites une compilation à partir des ports, la date approximative où vous avez + mis à jour les ports.</p></li> + <li><p>Des informations spécifiques à chaque type d'erreur : le log complet de + la compilation dans le cas où la compilation d'un port est cassé, + le contenu de la pile dans le cas d'un core dump, une description détaillée + du problème lorsque cela concerne une application, etc. Essayez de vous + mettre à la place du développeur et, pour chaque cas particulier, + évaluez quelles informations peuvent être nécessaires pour qu'il puisse trouver + la source du problème. Ne pensez pas que les développeurs connaissent déjà tout du + problème et qu'ils sont juste trop paresseux pour le corriger.</p></li> + </ul> + + <p>Par ailleurs, essayez de répondre aux questions + suivantes :</p> + + <ul> + <li><b>Quel est exactement le problème ?</b> : + Expliquez le problème aussi clairement et + précisément que possible. Essayez de + limiter la description du problème à une + ou deux phrases clés.</li> + <li><b>Où survient le problème ?</b> : Dites + si le problème intervient lors de la compilation, + de l'installation, ou de l'exécution. + Décrivez également la machine sur laquelle + survient le problème (peut-être en + avez-vous plusieurs) et avec quelle locale (i.e. quelle + valeur de la valeur d'environnement <b>LANG</b>).</li> + <li><b>Quand le problème est-il survenu pour la + première fois ?</b> : Essayez de + déterminer quand le problème a + commencé à apparaître. Si ça + n'a jamais marché ou que vous avez toujours eu un + problème, dites le également. Dites aussi + quand le problème a été + observé pour la dernière fois, et, le cas + échéant, quand les choses ont bien + marché pour la dernière fois.</li> + <li><b>Quelle est l'importance du problème ?</b> : + Expliquez si les choses empirent, si elles + s'améliorent, ou si elles restent les + mêmes. Nous avons conscience que beaucoup de + problèmes ne sont que des problèmes, mais + ce genre d'information peut s'avérer utile dans + certains cas.</li> + </ul> + + <p>Tenez vous prêt à répondre à + des questions supplémentaires. Bien souvent, les + développeurs ne peuvent résoudre un + problème ou même en faire le diagnostique + tout de suite. Donc, montrez vous compréhensif + lorsqu'on vous demandera de fournir d'autres + informations.</p> + + <p>Si vous avez une solution ou un moyen de contourner le problème, mettez le + également dans votre rapport, même si vous n'êtes pas certain que cette + solution est correcte. Si elle ne l'est pas, elle peut tout de même + donner au développeur des idées et lui faire gagner du temps.</p> + + <h2>2. Où envoyer le rapport ?</h2> + + <p>Avant de rapporter un bug, ou même d'envoyer un message sur la liste, + <a href="http://www.freebsd.org/search/search.html">faites une recherche</a> + dans les archives de la liste de diffusion GNOME pour FreeBSD pour voir s'il n'a pas + déjà été rapporté. La plupart des problèmes rapportés sur + les listes de diffusion sont déjà connus et, en faisant une recherche, vous pouvez trouver + la solution à votre problème beaucoup plus rapidement. + </p> + + <p>Une fois que vous êtes certain qu'il s'agit d'un problème nouveau, il y a plusieurs manières + de rapporter un bug concernant GNOME sous FreeBSD : vous pouvez + envoyer un rapport sur la + <a href="mailto:&email;@FreeBSD.org">liste de diffusion + freebsd-gnome</a>, remplir un rapport de problème avec + <a href="http://www.freebsd.org/support.html#gnats">le système de rapport + de bug FreeBSD</a>, envoyer votre rapport aux développeurs GNOME + concernés via leur + <a href="http://bugzilla.gnome.org/">système de gestion de bug</a> ou utiliser + une combinaison de ces différentes méthodes.</p> + + <p>Il est impossible de définir des règles qui vous indiqueront clairement + dans tous les cas où envoyer votre rapport - utilisez votre bon + sens. Voici cependant quelques principes généraux :</p> + + <ul> + <li><p>Si le problème est spécifique à FreeBSD et temporaire (e.g. un checksum + incorrect, un patch qui échoue, une erreur de syntaxe dans le Makefile du port, etc.) alors + envoyez le rapport à la <a href="mailto:&email;@FreeBSD.org"> + liste de diffusion freebsd-gnome</a>.</p></li> + <li><p>Si le problème est clairement non spécifique à FreeBSD et que vous n'avez pas + de solution disponible alors envoyez le rapport directement aux développeurs + du logiciel (pour la plupart des composants du noyau de GNOME cela signifie que + vous devrez utiliser leur système de gestion de bug "Bugzilla").</p></li> + <li><p>Si le problème n'est pas spécifique à FreeBSD mais assez sérieux et que + vous avez une solution disponible alors envoyez le rapport à la fois à FreeBSD et au + système de gestion de bug des auteurs, de façon à ce que le port concerné + soit corrigé et que les autres utilisateurs FreeBSD puissent béneficier de + votre solution sans avoir à attendre la sortie d'une nouvelle version du + logiciel.</p></li> + </ul> + + </body> +</html> |