SUBDIR+= problem-reports

# $FreeBSD: doc/en_US.ISO8859-1/articles/problem-reports/Makefile,v 1.1 2001/11/23 01:01:51 des Exp $

# $Id$

# Original revision: 1.1

DOC?= article

FORMATS?= html

INSTALL_COMPRESSED?=gz

INSTALL_ONLY_COMPRESSED?=

JADEFLAGS+=	-V %generate-article-toc%

SRCS= article.sgml

DOC_PREFIX?= ${.CURDIR}/../../..

.include "${DOC_PREFIX}/share/mk/doc.project.mk"

<!--                                                                     

    The FreeBSD Documentation Project                                    

    The FreeBSD French Documentation Project                             

    $FreeBSD$

    $Id$

    Original revision: 1.10

-->

<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [

<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">

%man;

<!ENTITY % abstract PUBLIC "-//FreeBSD//ENTITIES DocBook Abstract Entities//FR"> %abstract;

<!ENTITY % artheader PUBLIC "-//FreeBSD//ENTITIES DocBook ArtHeader Entities//FR"> %artheader;

<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//FR"> %translators;

<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> %man;

]>

<article lang="fr">

  <articleinfo>

    <title>Ecrire des rapports de bogue pour FreeBSD</title>

    <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/problem-reports/article.sgml,v 1.10 2002/05/24 08:20:38 ceri Exp $</pubdate>

    <abstract>

      <para>Cet article d&eacute;crit comment formuler et soumettre au mieux un 

	rapport	de bogue au projet FreeBSD.</para>

	&abstract.license;

	&abstract.disclaimer;

	&trans.a.fonvieille;

    </abstract>

    <authorgroup>

      <author>

	<firstname>Dag-Erling</firstname>

	<surname>Sm&oslash;rgrav</surname>

	<contrib>Contributed by </contrib>

      </author>

    </authorgroup>

  </articleinfo>

  <indexterm><primary>rapports de bogue</primary></indexterm>

  <sect1 id="pr-intro">

    <title>Introduction</title>

    <para>Une des exp&eacute;riences la plus frustrante que peut vivre un

      utilisateur de logiciel est de soumettre un rapport de bogue et de

      le voir être fermé sommairement avec une explication 

      laconique et sans aide du type “ce n'est pas un bogue” ou

      “PR bogué”.  De même une des 

      expériences la plus frustrante pour un programmeur est 

      d'être submergé de rapports de

      bogue qui ne sont pas vraiment des rapports de bogue mais plutôt

      des demandes d'aide, ou qui contiennent peu ou pas d'information

      au sujet du probl&egrave;me et sur comment le reproduire.</para>

    <para>Ce document essaye de d&eacute;crire comment &eacute;crire de 

      bons rapports de bogue.  Qu'est-ce qu'un bon rapport de bogue, 

      allez-vous demander?  Bien, pour aller directement au but, un bon 

      rapport de bogue est celui qui peut être analysé et 

      traité rapidement, pour la satisfaction mutuelle de 

      l'utilisateur et du d&eacute;veloppeur.</para>

    <para>Bien que l'objectif principal de cet article est les rapports

      de bogue pour FreeBSD, sa majeure partie devrait s'appliquer

      relativement bien &agrave; d'autres projets de logiciels.</para>

    <para>Notez que cet article est organis&eacute; th&eacute;matiquement, 

      et non pas de façon chronologique, ainsi vous devriez lire 

      entièrement ce document avant de soumettre un rapport de 

      bogue, plutôt que de le traiter comme un guide 

      pas-&agrave;-pas.</para>

  </sect1>

  <sect1 id="pr-when">

    <title>Quand soumettre un rapport de bogue</title>

    <para>Il existe beaucoup de types de probl&egrave;mes, et tous ne 

      devraient pas être à l'origine d'un rapport de bogue.  

      Naturellement, personne n'est parfait, et il y aura des moments 

      où vous serez convaincus d'avoir trouvé un bogue 

      dans un programme alors qu'en fait vous avez mal compris la 

      syntaxe d'une commande ou fait une erreur dans un fichier de 

      configuration (cependant cela peut en soi être significatif 

      d'une documentation sommaire ou d'une mauvaise gestion des erreurs 

      dans l'application).  Il reste beaucoup de cas où la 

      soumission d'un rapport de bogue n'est clairement pas la bonne 

      ligne de conduite, et ne servira qu'à frustrer les 

      développeurs et vous-même.  Réciproquement, il y a

      des cas où il peut être approprié de 

      soumettre un rapport de bogue à propos de quelque chose 

      d'autre qu'un bogue—une amélioration ou une demande 

      de fonctionnalit&eacute;, par exemple.</para>

    <para>Aussi comment d&eacute;terminer ce qui est un bogue et ce qui ne

      l'est pas?  Un principe de base simple est que votre problème

      n'est <emphasis>pas</emphasis> un bogue s'il peut &ecirc;tre 

      exprimé sous la forme d'une question (habituellement de la 

      forme “Comment puis-je faire X?” ou “Où 

      puis-je trouver Y?”).  Ce n'est pas toujours aussi simple 

      que cela, mais la règle de la question couvre une 

      majorit&eacute; de cas.</para>

    <para>Les quelques cas o&ugrave; il peut &ecirc;tre appropri&eacute; 

      de soumettre un rapport de bogue au sujet de quelque chose qui 

      n'est pas un bogue sont:</para>

    <itemizedlist>

      <listitem>

        <para>demandes d'am&eacute;lioration de caract&eacute;ristiques.  

	  C'est généralement une bonne idée de 

	  discuter de cela sur les listes de diffusion avant de 

	  soumettre un rapport de bogue.</para>

      </listitem>

      <listitem>

        <para>Avis de mise &agrave; jour de logiciels maintenus &agrave; 

	  l'extérieur (principalement des logiciels portés, 

	  mais également des composants du système de base 

	  maintenus à l'extérieur comme BIND ou divers 

	  utilitaires GNU).</para>

      </listitem>

    </itemizedlist>

    <para>Une autre chose est que si le syst&egrave;me sur lequel vous

      expérimentez le bogue n'est pas suffisamment à jour, 

      vous devriez considérer sérieusement de mettre 

      à jour et d'essayer de reproduire le problème sur 

      un système à jour avant de soumettre le

      rapport de bogue.  Il y peu de choses qui ennuieront plus un

      développeur que de recevoir un rapport de bogue au sujet

      d'un probl&egrave;me d&eacute;j&agrave; corrig&eacute;.</para>

    <para>Et finalement, un bogue qui ne peut &ecirc;tre reproduit peut

      rarement être corrigé.  Si le bogue se produit une 

      seule fois et que vous ne pouvez pas le reproduire, et qu'il ne 

      semble pas faire une autre victime, il y des chances qu'aucun des

      développeurs ne sera en mesure de le reproduire ou de comprendre

      ce qui ne va pas.  Cela ne signifie pas que rien ne s'est produit,

      mais plutôt que les chances que votre rapport de bogue 

      mène à un correctif sont très minces, et que 

      vous devriez envisager de laisser tomber.</para>

  </sect1>

  <sect1 id="pr-prep">

    <title>Pr&eacute;parations</title>

    <para>Une bonne r&egrave;gle &agrave; suivre est de toujours 

      effectuer une recherche avant de soumettre un rapport de bogue.  

      Peut-être que votre problème a déjà 

      été signalé; peut-être même qu'on en

      discute actuellement sur les listes de diffusion, ou l'était

      récemment; il se peut qu'il soit même déjà 

      corrigé dans une nouvelle version de ce que vous utilisez.  

      Vous devriez donc vérifier tous les lieux d'information 

      avant de soumettre votre rapport de bogue.  Pour FreeBSD, cela 

      signifie:</para>

    <itemizedlist>

      <listitem>

        <para>La FAQ.</para>

      </listitem>

      <listitem>

        <para>Les listes de diffusion&mdash;si vous n'&ecirc;tes pas inscrit,

	  utilisez l'outil de recherche des archives sur le site de

	  FreeBSD.  Si votre problème n'a pas été 

	  abordé sur les listes, vous pourriez essayer de poster 

	  un message à ce sujet et attendre quelques jours pour 

	  voir si quelqu'un peut déceler quelque chose que vous 

	  avez n'avez pas remarqu&eacute;.</para>

      </listitem>

      <listitem>

        <para>Eventuellement, l'int&eacute;gralit&eacute; du 

	  web—utilisez votre moteur de recherche favoris pour 

	  chercher toutes les références à votre 

	  problème.  Vous pouvez même obtenir des

	  résultats des archives des listes de diffusion ou des forums

	  de discussion que vous ne connaissiez pas ou parmi lesquels

	  vous n'aviez pas pens&eacute; chercher.</para>

      </listitem>

      <listitem>

        <para>Et finalement, la base de donn&eacute;es des PRs.  A 

	  moins que votre problème ne soit récent ou 

	  obscure, il y a assez de chance pour qu'il soit 

	  d&eacute;j&agrave; signal&eacute;.</para>

      </listitem>

    </itemizedlist>

    <para>Ensuite, vous devez &ecirc;tre s&ucirc;r que le rapport de 

      bogue est envoy&eacute; aux bonnes personnes.</para>

    <para>Le premier point ici est que si un probl&egrave;me est un 

      bogue dans un logiciel tiers (un logiciel porté ou 

      pré-compilé que vous avez installé), vous 

      devrez rapporter le bogue à l'auteur originel, et

      pas au projet FreeBSD.  Il y a deux exceptions à cette 

      règle: la première est que si le bogue 

      n'apparaît pas sur d'autres plateformes, dans quel cas le 

      problème peut venir le façon dont le logiciel a 

      été porté sous FreeBSD; la seconde est si 

      l'auteur original a déjà corrigé le 

      problème et sorti un correctif ou une nouvelle version de 

      son logiciel, et que le logiciel porté de

      FreeBSD n'a pas encore &eacute;t&eacute; mis &agrave; jour.</para>

    <para>Le second point est que le syst&egrave;me de suivi des bogue de

      FreeBSD classe les rapports de bogue en fonction de la 

      catégorie que l'auteur a choisie.  Donc, si vous choisissez 

      la mauvaise catégorie, il y a de fortes chances qu'il 

      passera inaperçu pendant un moment, jusqu'à ce que 

      quelqu'un le re-cat&eacute;gorise.</para>

  </sect1>

  <sect1 id="pr-writing">

    <title>Ecrire le rapport de bogue</title>

    <para>Maintenant que vous avez d&eacute;cid&eacute; que votre 

      problème mérite un rapport de bogue, et que c'est 

      un problème avec FreeBSD, il est temps d'écrire 

      le rapport.  Assurez-vous que votre variable d'environnement 

      <envar>VISUAL</envar> (ou <envar>EDITOR</envar> si

      <envar>VISUAL</envar> n'existe pas) est configur&eacute;e avec 

      quelque chose de pratique, et lancez &man.send-pr.1;.</para>

    <sect2>

      <title>Attacher des correctifs ou des fichiers</title>

      <para>Le programme &man.send-pr.1; pr&eacute;voit l'attachement de

	fichiers à un rapport de bogue.  Vous pouvez attacher 

	autant de fichiers que vous le désirez à condition 

	que chacun ait un nom de base unique (i.e. le nom propre du 

	fichier, sans le chemin).  Utilisez juste l'option en ligne de 

	commande <option>-a</option> pour sp&eacute;cifier le nom des 

	fichiers que vous souhaitez attacher:</para>

<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/errors</userinput>

</screen>

      <para>Ne vous inqui&eacute;tez pas pour les fichiers binaires; 

	ils seront automatiquement encodés de façon 

	&agrave; ne pas d&eacute;ranger votre logiciel de courrier.</para>

      <para>Si vous attachez un correctif, assurez-vous d'employer

	l'option <option>-c</option> ou <option>-u</option> avec

	&man.diff.1; pour créer un fichier diff unifié 

	ou contextuel, et soyez sûr d'indiquer les numéros 

	exacts des révisions CVS des fichiers que vous avez 

	modifiés afin que les développeurs qui

	liront votre rapport soient capable d'appliquer facilement vos

	correctifs.</para>

      <para>Vous devez &eacute;galement prendre note &agrave; moins que 

	vous ne le précisiez explicitement dans votre PR, que 

	tous les correctifs que vous soumettez seront 

	présumés être sous les mêmes termes de

	licence que le fichier original que vous avez modifi&eacute;.</para>

    </sect2>

    <sect2>

      <title>Remplir le formulaire</title>

      <para>Le formulaire se compose d'une liste de champs, dont

	certains sont déjà préremplis, et qui 

	peuvent avoir des commentaires expliquant leur but et la liste 

	des valeurs utilisables.  Ne vous inquiétez pas des 

	commentaires; ils seront retirés automatiquement si vous 

	ne les modifiez ou retirez pas vous-m&ecirc;me.</para>

      <para>En haut du formulaire, sous les lignes

        <literal>SEND-PR:</literal>, se trouvent les ent&ecirc;tes

	d'émail.  Vous n'avez normalement pas besoin de les 

	modifier, à moins que vous envoyiez le rapport de bogue 

	à partir d'une machine ou d'un compte qui peut envoyer 

	mais pas recevoir de courrier, dans ce cas vous voudrez remplir 

	les champs <literal>From:</literal> et <literal>Reply-To:</literal> 

	suivant votre adresse émail réelle.  Vous pouvez 

	vouloir vous envoyer (ou à quelqu'un d'autre) une copie 

	carbone du rapport de bogue en ajoutant une ou plusieurs 

	adresses &eacute;mail au champ <literal>Cc:</literal>.</para>

      <para>Ensuite vient une s&eacute;rie de champ &agrave; une ligne:</para>

      <itemizedlist>

        <listitem>

	  <para><emphasis>Submitter-Id:</emphasis> ne rien changer.

	    La valeur par d&eacute;faut <literal>current-users</literal> est

	    correcte, m&ecirc;me si vous utilisez FreeBSD-STABLE.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Originator:</emphasis> ceci est normalement

	    complété avec le champ gecos de l'utilisateur 

	    actuellement attaché au système.  Veuillez 

	    indiquer votre véritable nom,

	    suivi optionnellement de votre émail entre les symboles

	    inf&eacute;rieur et sup&eacute;rieur.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Organization:</emphasis> comme vous le sentez.

	    Ce champ n'est pas employé pour quelque chose de

	    significatif.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Confidential:</emphasis> ceci est pr&eacute;rempli

	    avec <literal>no</literal>; le changer ne signifie pas grand

	    chose car il n'y a aucun rapport de bogue confidentiel pour

	    FreeBSD—la base de données des PRs est 

	    distribu&eacute;e dans le monde entier par CVSup.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Synopsis:</emphasis> compl&eacute;tez ceci 

	    avec une description courte et précise du 

	    problème.  Le synopsis est utilisé comme sujet 

	    du rapport de bogue, et est employé dans

	    les listes et résumés de rapport de bogue; les 

	    rapports de bogue avec d'obscures sujets ont tendance à 

	    &ecirc;tre ignor&eacute;s.</para> 

	  <para>Si votre rapport de bogue inclut un correctif, veuillez

	    utiliser un synopsis débutant avec le mot

	    <literal>[PATCH]</literal>.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Severity:</emphasis> une parmi

  	    <literal>non-critical</literal>,

  	    <literal>serious</literal> ou

  	    <literal>critical</literal>.  Pas de surestimation,

	    abstenez-vous de marquer votre problème comme

	    <literal>critical</literal> &agrave; moins qu'il ne le soit

	    vraiment (e.g. root exploit, panique du système facilement

	    reproductible).  Les développeurs ont tendance à 

	    ignorer ce champ et le suivant, précisément parce 

	    que les auteurs ont tendance à surestimer l'importance 

	    de leurs probl&egrave;mes.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Priority:</emphasis> une parmi

  	    <literal>low</literal>, <literal>medium</literal> ou

  	    <literal>high</literal>.  Voir ci-dessus.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Category:</emphasis> choisir l'une des

	    suivantes:</para>

	  <itemizedlist>

	    <listitem>

	      <para><literal>advocacy:</literal> probl&egrave;mes concernant

	        l'image publique de FreeBSD.  Rarement utilis&eacute;.</para>

	    </listitem>

	    <listitem>

	      <para><literal>alpha:</literal> probl&egrave;mes 

		spécifiques à la

	        plateforme Alpha.</para>

	    </listitem>

	    <listitem>

	      <para><literal>bin:</literal> probl&egrave;mes avec les

		programmes utilisateur du syst&egrave;me de base.</para>

	    </listitem>

	    <listitem>

	      <para><literal>conf:</literal> probl&egrave;mes avec les fichiers

		de configuration, les valeurs par d&eacute;faut etc...</para>

	    </listitem>

	    <listitem>

	      <para><literal>docs:</literal> probl&egrave;mes avec les pages de

		manuel ou la documentation en ligne.</para>

	    </listitem>

	    <listitem>

	      <para><literal>gnu:</literal> probl&egrave;mes avec les logiciels 

		GNU comme &man.gcc.1; ou &man.grep.1;.</para>

	    </listitem>

	    <listitem>

	      <para><literal>i386:</literal> probl&egrave;mes 

		spécifiques à la

		plateforme i386.</para>

	    </listitem>

	    <listitem>

	      <para><literal>kern:</literal> probl&egrave;mes avec le

		noyau.</para>

	    </listitem>

	    <listitem>

	      <para><literal>misc:</literal> tout ce qui ne va pas dans

		une des autres cat&eacute;gories.</para>

	    </listitem>

	    <listitem>

	      <para><literal>ports:</literal> probl&egrave;mes concernant le

		catalogue des logiciels port&eacute;s.</para>

	    </listitem>

	    <listitem>

	      <para><literal>sparc:</literal> probl&egrave;mes 

		spécifiques à la

		plateforme Sparc.</para>

	    </listitem>

	  </itemizedlist>

	</listitem>

	<listitem>

	  <para><emphasis>Class:</emphasis> choisissez une des

	    suivantes:</para>

	  <itemizedlist>

	    <listitem>

	      <para><literal>sw-bug:</literal> bogues logiciel.</para>

	    </listitem>

	    <listitem>

	      <para><literal>doc-bug:</literal> erreurs dans la

	        documentation.</para>

	    </listitem>

	    <listitem>

	      <para><literal>change-request:</literal> demande de

		fonctionnalités supplémentaires ou de 

		changement dans

		des fonctionnalit&eacute;s existantes.</para>

	    </listitem>

	    <listitem>

	      <para><literal>update:</literal> mise &agrave; jour de logiciels

		port&eacute;s ou d'autres logiciels.</para>

	    </listitem>

	    <listitem>

	      <para><literal>maintainer-update:</literal> mise &agrave; 

		jour de logiciels portés dont vous êtes le 

		responsable.</para>

	    </listitem>

	  </itemizedlist>

	</listitem>

	<listitem>

	  <para><emphasis>Release:</emphasis> La version de FreeBSD que

	    vous utilisez.  Ceci sera complété 

	    automatiquement par &man.send-pr.1; et devra être 

	    modifié seulement si vous envoyez le rapport de 

	    bogue à partir d'un système différent

	    de celui qui pr&eacute;sente le probl&egrave;me.</para>

	</listitem>

      </itemizedlist>

      <para>Et enfin, il y a une s&eacute;rie de champs &agrave; plusieurs

	lignes:</para>

      <itemizedlist>

        <listitem>

	  <para><emphasis>Environment:</emphasis> Ceci devrait d&eacute;crire,

	    le plus exactement que possible, l'environnement dans lequel

	    le problème a été observé.  Cela 

	    inclut la version du système d'exploitation, la version 

	    du programme spécifique

	    ou fichier qui contient le problème, et tout autre 

	    élément

	    important comme la configuration du système, d'autres

	    logiciels qui influencent le problème, etc... —

	    presque tout ce dont a besoin un développeur pour

	    reconstruire l'environnement dans lequel le problème

	    appara&icirc;t.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Description:</emphasis> une description

	    complète et précise du problème que vous 

	    expérimentez.

	    Essayez d'éviter de spéculer au sujet des causes 

	    du problème à moins que vous soyez certain 

	    d'être dans le vrai, car cela

	    peut tromper le d&eacute;veloppeur.</para>

	</listitem>

	<listitem>

	  <para><emphasis>How-To-Repeat:</emphasis> Un r&eacute;sum&eacute; 

	    des actions nécessaires pour reproduire le 

	    probl&egrave;me.</para>

	</listitem>

	<listitem>

	  <para><emphasis>Fix:</emphasis> De pr&eacute;f&eacute;rence un 

	    correctif, ou au moins une solution de fortune (qui n'aidera 

	    pas seulement les autres personnes avec le même 

	    problème, mais peut aussi

	    aider un développeur à comprendre la cause du 

	    problème),

	    mais si vous n'avez aucune idée pour l'un ou l'autre, il

	    vaut mieux laisser ce champ en blanc plutôt que de

	    sp&eacute;culer.</para>

	</listitem>

      </itemizedlist>

    </sect2>

    <sect2>

      <title>Envoie du rapport de bogue</title>

      <para>Une fois que vous avez rempli et sauvegard&eacute; le formulaire,

	puis quitté votre éditeur, &man.send-pr.1; vous 

	proposera

	<prompt>s)end, e)dit or a)bort?</prompt> (envoyer, &eacute;diter ou

	abandonner?).  Vous pouvez alors taper <userinput>s</userinput>

	pour continuer et envoyer le rapport, <userinput>e</userinput>

	pour relancer l'éditeur et faire d'autres modifications, ou

	encore <userinput>a</userinput> pour abandonner.  Si vous

	choisissez cette dernière votre rapport de bogue restera sur le

	disque (&man.send-pr.1; vous donnera le nom du fichier avant de

	terminer), ainsi vous pouvez l'éditer à loisir, 

	où peut-être

	même le transférer sur un système avec une 

	meilleure connexion à

	l'Internet, avant de l'envoyer avec l'option <option>-f</option>

	de &man.send-pr.1;:</para>

<screen>&prompt.user; <userinput>send-pr -f ~/my-problem-report</userinput></screen>

      <para>Il lira le fichier sp&eacute;cifi&eacute;, en validera le contenu,

	retirera les commentaires et l'enverra.</para>

    </sect2>

  </sect1>

  <sect1 id="pr-followup">

    <title>Suivi</title>

    <para>Une fois que votre rapport de bogue a &eacute;t&eacute; 

      classé, vous

      recevrez une confirmation par courrier qui contiendra le 

      numéro de suivi qui a été assigné 

      à votre rapport de bogue et l'URL que vous

      pouvez utiliser pour vérifier son statut.  Avec un peu de chance,

      quelqu'un sera intéressé par votre problème et 

      essaiera de s'en

      occuper, ou, quand ce sera le cas, expliquera pourquoi ce n'est

      pas un problème.  Vous serez automatiquement prévenu 

      de tout changement d'état, et vous recevrez des copies de 

      tout commentaire

      ou correctif que quelqu'un pourra attacher au suivi de votre

      rapport de bogue.</para>

    <para>Si quelqu'un vous demande des informations suppl&eacute;mentaires, ou

      vous vous rappelez ou découvrez quelque chose que vous n'avez pas

      mentionné dans le rapport initial, envoyez-le juste à

      <email>bug-followup@FreeBSD.org</email>, en vous assurant que le

      numéro de suivi est inclut dans le sujet ainsi le système 

      de suivi des bogues connaîtra à quel rapport de 

      probl&egrave;me l'attacher.</para>

    <para>Si le rapport de bogue reste ouvert apr&egrave;s que le 

      problème soit

      corrigé, envoyez juste un courrier de suivi (de la manière

      prescrite ci-dessus) disant que le rapport de bogue peut être

      fermé, et, si possible, expliquant comment et quand le 

      problème

      fut corrig&eacute;.</para>

  </sect1>

  <sect1 id="pr-further">

    <title>Lecture suppl&eacute;mentaire</title>

    <para>Voici une liste des ressources concernant l'&eacute;criture et le

      traitement appropriés des rapports de bogue.  Cela ne veut pas

      dire exhaustive.</para>

    <itemizedlist>

      <listitem>

        <para><ulink

	    url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">

	    Comment rapporter efficacement les bogues</ulink>&mdash;un 

	    excellent essai de Simon G. Tatham sur l'écriture de 

	    rapports de bogue utiles

	    (non sp&eacute;cifique &agrave; FreeBSD).</para>

      </listitem>

    </itemizedlist>

  </sect1>

</article>