5305bb945d
- Move includes.nav*.sgml to share/sgml/navibar.ent and
<lang>/share/sgml/navibar.l10n.ent.
- Move includes.sgml and includes.xsl to
share/sgml/common.ent, share/sgml/header.ent, <lang>/share/sgml/l10n.ent,
and <lang>/share/sgml/header.l10n.ent.
- Move most of XSLT libraries to share/sgml/*.xsl and
<lang>/share/sgml/*.xsl.
- Move news.xml and other *.xml files for the similar purpose
to share/sgml/*.xml and <lang>/share/sgml/*.xml.
- Switch to use a custom DTD for HTML document. Now we use
"-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension", which is
HTML 4.01 + some entities previously pulled via
"<!ENTITY % includes SYSTEM "includes.sgml"> %includes;" line.
The location of entity file will be resolved by using catalog file.
- Add DOCTYPE declearation to XML documents. This makes the followings
possible:
* Use of &foo; entities for SGML in an XML file instead of defining
{$foo} as the same content.
* &symbolic; entities for Latin characters.
- Duplicated information between SGML and XML, or English and
translated doc, has been removed as much as possible.
145 lines
8.1 KiB
Text
145 lines
8.1 KiB
Text
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
|
|
<!ENTITY base CDATA "../..">
|
|
<!ENTITY date "$FreeBSD: www/fr/gnome/docs/bugging.sgml,v 1.6 2005/10/06 12:56:03 blackend Exp $">
|
|
<!ENTITY title "Projet GNOME pour FreeBSD : rapporter un bug">
|
|
<!ENTITY % navinclude.developers "INCLUDE">
|
|
]>
|
|
|
|
<!--
|
|
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>
|
|
&header;
|
|
|
|
<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>).
|
|
<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>
|
|
|
|
&footer;
|
|
</body>
|
|
</html>
|