SUBDIR+= pr-guidelines

#

#   The FreeBSD Documentation Project

#   The FreeBSD French Documentation Project

#

#   $FreeBSD: doc/en_US.ISO8859-1/articles/pr-guidelines/Makefile,v 1.1 2002/05/09 12:28:53 des Exp $

#   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"

<!--

	Problem Report Handling Guidelines

	The FreeBSD Project - http://www.FreeBSD.org

	The FreeBSD French Documentation Project

	$Id$

	Original revision: 1.3

-->

<!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">

  <!-- :START of Article Metadata -->

  <articleinfo>

    <title>Directives d'utilisation des rapport de bogues</title>

    <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/pr-guidelines/article.sgml,v 1.3 2002/05/23 00:42:35 keramida Exp $</pubdate>

    <abstract>

      <para>Ces directives décrivent les pratiques recommandées

	d'utilisation des rapports de bogues de FreeBSD (PRs -

	“Problem Reports”).  Bien que développées pour

	l'équipe de maintenance de la base de données PR de FreeBSD

	<email>freebsd-bugbusters@FreeBSD.org</email>, ces directives

	devraient être suivies par toute personne travaillant avec les

	rapports de bogues de FreeBSD.</para>

	&abstract.license;

	&abstract.disclaimer;

	&trans.a.fonvieille;

    </abstract>

    <authorgroup>

      <author>

	<firstname>Dag-Erling</firstname>

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

      </author>

      <author>

	<firstname>Hiten</firstname>

	<surname>Pandya</surname>

      </author>

    </authorgroup>

  </articleinfo>

  <!-- :END of Article Metadata-->

  <section>

    <title>Introduction</title>

    <para>Gnats est un système de gestion des défauts (rapport de bogue)

      utilisé par le projet FreeBSD.  Comme le suivi précis des

      défauts logiciels en suspend est important pour le processus de

      qualité, une utilisation correcte de Gnats est essentielle pour

      l'avancée du Projet.</para>

    <para>Un accès à Gnats est fournis aux développeurs de FreeBSD aussi

      bien qu'à la communauté.  Afin de maintenir la cohérence de la

      base de données et fournir une expérience uniforme d'utilisateur,

      des directives ont été établies couvrant les aspects courants de

      la gestion de bogue comme la présentation des requêtes de suivi,

      de fermeture et ainsi de suite.</para>

  </section>

  <section>

    <title>Le cycle de vie d'un rapport de bogue</title>

    <itemizedlist>

      <listitem>

	<para>L'auteur soumet un rapport de bogue (&ldquo;PR&rdquo;) et

	  reçoit un message de confirmation.</para>

      </listitem>

      <listitem>

	<para>Joe Random Committer s'intéresse au PR et se l'assigne, ou

	  Jane Random BugBuster décide que Joe est le plus compétent 

	  pour s'en occuper et le lui assigne.</para>

      </listitem>

      <listitem>

	<para>Joe a un bref échange avec l'auteur (s'assurant que que

	  cela ira dans le rapport d'audit) et détermine la cause du 

	  problème.  Il s'assure ensuite que la cause du problème est

	  documentée dans le rapport d'audit, et positionne l'état du

	  rapport de bogue sur “analysé”

	  (&ldquo;analysed&rdquo;).</para>

      </listitem>

      <listitem>

	<para>Joe passe une nuit blanche à travailler et produit un

	  correctif dont il pense qu'il corrigera le problème, et le

	  soumet dans le suivi du rapport, demandant à son auteur de le

	  tester.  Il fixe ensuite l'état du rapport de bogue sur

	  &ldquo;retour&rdquo; (&ldquo;feeback&rdquo;).</para>

      </listitem>

      <listitem>

	<para>Quelques échanges plus tard, Joe et l'auteur sont

	  satisfaits du correctif, et Joe l'intègre à la branche

	  <literal>-CURRENT</literal> (ou directement à la branche

	  <literal>-STABLE</literal> si le problème n'existe pas sur la

	  branche <literal>-CURRENT</literal>), s'assurant de bien

	  faire référence au rapport de bogue dans le commentaire de son

	  “commit” (et créditant l'auteur s'il a soumis tout

	  ou une partie du correctif) et, si approprié, commence le

	  décompte de l'intégration dans la branche

	  <literal>-STABLE</literal> (&ldquo;MFC&rdquo;).

      </listitem>

      <listitem>

	<para>Si le correctif ne nécessite pas d'intégration, Joe ferme

	  alors le PR.</para>

      </listitem>

      <listitem>

	<para>Si le correctif nécessite une intégration, Joe laisse le

	  rapport de bogue dans l'état “corrigé”

	  (“patched”) jusqu'à ce que le correctif soit

	  intégré, et puis le ferme.</para>

      </listitem>

    </itemizedlist>

    <note>

      <para>Beaucoup de PRs sont soumis avec très peu d'information sur

	le problème, et certains sont soit très complexe à résoudre,

	soit effleurent juste un problème bien plus important; dans ces

	cas, il est vraiment important d'obtenir toute l'information

	nécessaire à la résolution du problème.  Si le problème contenu

	dans le rapport ne peut être résolu, ou s'est produit à nouveau,

	il est nécessaire de rouvrir le PR.</para>

    </note>

    <note>

      <para>L'adresse électronique utilisée dans le rapport de bogue

	pourrait ne pas pouvoir recevoir de courrier.  Dans ce cas,

	faites le suivi du PR comme à l'accoutumé et demandez à

	l'auteur (dans le message de suivi) de fournir une adresse

	électronique fonctionnant.  C'est habituellement le cas quand

	&man.send-pr.1; est utilisé depuis un système ayant la gestion

	du courrier désactivée / non installée.</para>

    </note>

  </section>

  <section>

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

    <para>Il est important de maintenir à jour l'état d'un PR quand des

      mesures ont été prises.  L'état devrait refléter exactement l'état

      actuel du travail sur le rapport de bogue.</para>

    <example>

      <title>Un petit exemple sur quand doit-on changer un état</title>

      <para>Quand un PR a été étudié et que le(s) développeur(s)

	responsable(s) se sent(ent) satisfait(s) du correctif, ils

	soumettront un suivi au rapport de bogue et changeront l'état en

	“retour” (“feedback”).  A ce moment-là

	l'auteur du rapport devrait évaluer le correctif dans son

	contexte et répondre en indiquant si le défaut a été en effet

	corrigé.</para>

    </example>

    <para>Un rapport de bogue peut être dans un des états

      suivants:</para>

    <glosslist>

      <glossentry>

	<glossterm>open - &ldquo;ouvert&rdquo;</glossterm>

	<glossdef>

	  <para>Etat initial, le problème a été constaté et il a besoin

	    d'être passé en revue.</para>

	</glossdef>

      </glossentry>

      <glossentry>

	<glossterm>analyzed - &ldquo;analysé&rdquo;</glossterm>

	<glossdef>

	  <para>Le problème a été passé en revue et une solution est

	    cherchée.</para>

	</glossdef>

      </glossentry>

      <glossentry>

	<glossterm>feedback - &ldquo;retour&rdquo;</glossterm>

	<glossdef>

	  <para>Un travail plus approfondi exige une information

	    supplémentaire de la part de l'auteur ou de la communauté,

	    probablement de l'information concernant la solution

	    proposée.</para>

	</glossdef>

      </glossentry>

      <glossentry>

	<glossterm>patched - &ldquo;corrigé&rdquo;</glossterm>

	<glossdef>

	  <para>Un correctif a été commis, mais quelques problèmes

	    (“MFC”, ou peut être une confirmation de 

	    l'auteur) sont encore en suspend.</para>

	</glossdef>

      </glossentry>

      <glossentry>

	<glossterm>suspended - &ldquo;suspendu&rdquo;</glossterm>

	<glossdef>

	  <para>Personne ne travaille sur le problème, en raison d'un

	    manque d'information ou de ressources.  C'est le premier

	    candidat pour quelqu'un qui recherche un projet pour

	    travailler dessus.  Si le problème ne peut être résolu, il

	    sera fermé, plutôt que suspendu. Le projet de documentation

	    utilise “suspendu” pour les éléments qui

	    nécessitent une quantité significative de travail pour

	    laquelle personne n'a actuellement le temps.</para>

	</glossdef>

      </glossentry>

      <glossentry>

	<glossterm>closed - &ldquo;fermé&rdquo;</glossterm>

	<glossdef>

	  <para>Un rapport de problème est fermé quand tous les

	    changements ont été intégrés, documentés, et testés, ou 

	    quand la correction du problème est abandonnée.</para>

	</glossdef>

      </glossentry>

    </glosslist>

    <note>

      <para>L'état &ldquo;corrigé&rdquo; est directement lié au retour,

	du fait vous pouvez directement passer à cet état si l'auteur ne

	peut tester le correctif, et étant donné que cela

	fonctionne.</para>

    </note>

  </section>

  <section>

    <title>Types de rapport de bogues</title>

    <section>

      <title>PRs assignés</title>

      <para>Si un PR a son champ <literal>responsible</literal> 

	complété avec le nom d'utilisateur d'un développeur FreeBSD,

	cela signifie que le PR a été confié à cette personne pour

	davantage de travail.</para>

      <para>Les PRs assignés ne devraient pas être touchés par

	n'importe qui mais par la personne désignée.  Si vous avez des

	commentaires, soumettez un message de suivi.  Si pour une raison

	ou une autre vous pensez que le PR devrait être changé d'état ou

	réassigner, envoyez un message à la personne assignée.  Si cette

	dernière ne répond pas dans un délai de deux semaines,

	désassignez le PR et faites ce qu'il vous plaît.</para>

    </section>

    <section>

      <title>Doublons</title>

      <para>Si vous trouvez plus d'un PR décrivant le même problème,

	choisissez celui qui contient la plus grande quantité

	d'information utile et fermez les autres, en précisant

	clairement le numéro du PR de remplacement.  Si plusieurs PRs

	contiennent des informations utiles mais différentes, soumettez

	ce qui est manquant dans un PR que vous gardez ouvert par

	l'intermédiaire d'un rapport de suivi, avec les références aux 

	PRs que vous fermez.</para>

    </section>

    <section>

      <title>PRs &ldquo;éventés&rdquo;</title>

      <para>Un PR est considéré comme &ldquo;éventé&rdquo; s'il n'a pas été 

	modifié en plus de six mois.  Appliquez la procédure suivante:</para>

      <itemizedlist>

	<listitem>

	  <para>Si le PR contient suffisamment de détails, essayez de

	    reproduire le problème sur les branches

	    <literal>-CURRENT</literal> et <literal>-STABLE</literal>.

	    Si vous réussissez, soumettez un rapport de suivi détaillant

	    vos résultats et trouvez quelqu'un à qui l'assigner.  Placez

	    l'état sur &ldquo;analysé&rdquo; si c'est approprié.</para>

	</listitem>

	<listitem>

	  <para>Si le PR décrit un problème dont vous savez que c'est le

	    résultat d'une erreur d'utilisation (configuration

	    incorrecte ou autre), soumettez un rapport de suivi

	    expliquant où s'est trompé l'auteur, ensuite fermez le PR

	    avec comme raison “User error” (Erreur

	    d'utilisation) ou “Configuration error” (Erreur

	    de configuration).</para>

	</listitem>

	<listitem>

	  <para>Si le PR décrit une erreur dont vous savez qu'elle a été

	    corrigée dans les branches <literal>-CURRENT</literal> et

	    <literal>-STABLE</literal>, fermez-le avec un message

	    précisant quand il a été corrigé dans chaque branche.</para>

	</listitem>

	<listitem>

	  <para>Si le PR décrit une erreur dont vous savez qu'elle a été

	    corrigée dans la branche <literal>-CURRENT</literal>, mais

	    pas dans la branche <literal>-STABLE</literal>, essayez de

	    voir si la personne qui l'a corrigé projette de faire

	    l'intégration dans la branche <literal>-STABLE</literal>,

	    ou essayez de trouver quelqu'un (peut-être vous-même?) pour

	    le faire.  Placez l'état sur “retour” et

	    assignez-le à quiconque fera l'intégration.</para>

	</listitem>

	<listitem>

	  <para>Dans tout autre cas, demandez à l'auteur de confirmer si

	    le problème existe toujours dans les nouvelles versions.  Si

	    l'auteur ne réponds pas sous un mois, fermez le PR avec la

	    mention “Feedback timeout” (Délai de retour

	    expiré).</para>

	</listitem>

      </itemizedlist>

    </section>

  </section>

</article>