path: root/fr_FR.ISO8859-1/articles/pr-guidelines/article.xml

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN"
	"../../../share/xml/freebsd42.dtd" [
<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//FR" "../../share/xml/entities.ent">
%entities;
]>

<!--
	Problem Report Handling Guidelines
	The FreeBSD Project - http://www.FreeBSD.org
	The FreeBSD French Documentation Project

	$FreeBSD$
	$Id: article.xml,v 1.5 2002-12-11 16:24:29 gioria Exp $
	Original revision: 1.8
-->

<article lang="fr">
  <!-- :START of Article Metadata -->
  <articleinfo>
    <title>Directives d'utilisation des rapports de bogues</title>

    <abstract>
      <para>Ces directives décrivent les pratiques
	recommandées d'utilisation des rapports de bogues de
	FreeBSD (PRs - &ldquo;Problem Reports&rdquo;).  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>

	&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>

    <pubdate>$FreeBSD$</pubdate>

    <releaseinfo>$FreeBSD$</releaseinfo>
  </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 suspens
      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 &agrave; GNATS est fourni aux
      développeurs de FreeBSD aussi bien qu'&agrave; 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 la plupart du temps
          via &man.send-pr.1; ou la page Web de rapport des bogues &agrave;
          <ulink url="http://www.FreeBSD.org/send-pr.html">
          http://www.FreeBSD.org/send-pr.html</ulink>.</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
	  &ldquo;analysé&rdquo; (&ldquo;analysed&rdquo;).</para>
      </listitem>

      <listitem>
	<para>Joe passe une nuit blanche &agrave; travailler et produit
	  un correctif dont il pense qu'il corrigera le problème,
	  et le soumet dans le suivi du rapport, demandant &agrave; 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 &agrave; la
	  branche <literal>-CURRENT</literal> (ou directement &agrave;
	  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 &ldquo;commit&rdquo; (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;).</para>
      </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
	  &ldquo;corrigé&rdquo; (&ldquo;patched&rdquo;)
	  jusqu'&agrave; 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 complexes &agrave; 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 &agrave; la résolution du
	problème.  Si le problème décrit
	par le rapport ne peut être résolu, ou s'est
	reproduit, 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 &agrave;
	l'accoutumé et demandez &agrave; 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 ou non
	installée.</para>
    </note>
  </section>

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

    <para>Il est important de maintenir &agrave; 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 le changement de l'état
      d'un PR</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 &ldquo;retour&rdquo;
	(&ldquo;feedback&rdquo;).  A ce moment-l&agrave;
	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 (&ldquo;MFC&rdquo;, ou peut être une
	    confirmation de l'auteur) sont encore en suspens.</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
	    &ldquo;suspendu&rdquo; 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, vous pouvez donc directement passer en
        état &ldquo;fermé&rdquo;, 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é &agrave; 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éassigné, envoyez un message &agrave; 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, en faisant référence 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
	    &agrave; 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 &ldquo;User error&rdquo; (Erreur
	    d'utilisation) ou &ldquo;Configuration error&rdquo; (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 cela 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 &ldquo;retour&rdquo; et assignez-le
	    &agrave; quiconque fera l'intégration.</para>
	</listitem>

	<listitem>
	  <para>Dans tous les autres cas, demandez &agrave; l'auteur de
	    confirmer si le problème existe toujours dans les
	    nouvelles versions.  Si l'auteur ne répond pas sous
	    un mois, fermez le PR avec la mention &ldquo;Feedback
	    timeout&rdquo; (Délai de retour expiré).</para>
	</listitem>
      </itemizedlist>
    </section>
  </section>
</article>