            Directives d'utilisation des rapports de bogues

  Dag-Erling Smo/rgrav

  Hiten Pandya

   $FreeBSD:
   release/8.4.0/fr_FR.ISO8859-1/articles/pr-guidelines/article.xml
   39632 2012-10-01 11:56:00Z gabor $

   $FreeBSD:
   release/8.4.0/fr_FR.ISO8859-1/articles/pr-guidelines/article.xml
   39632 2012-10-01 11:56:00Z gabor $

   Ces directives decrivent les pratiques recommandees d'utilisation
   des rapports de bogues de FreeBSD (PRs - "Problem Reports"). Bien
   que developpees pour l'equipe de maintenance de la base de donnees
   PR de FreeBSD <freebsd-bugbusters@FreeBSD.org>, ces directives
   devraient etre suivies par toute personne travaillant avec les
   rapports de bogues de FreeBSD.

   Version franc,aise de Marc Fonvieille <blackend@FreeBSD.org>.

     --------------------------------------------------------------

1. Introduction

   GNATS est un systeme de gestion des defauts (rapport de bogue)
   utilise par le projet FreeBSD. Comme le suivi precis des defauts
   logiciels en suspens est important pour le processus de qualite,
   une utilisation correcte de GNATS est essentielle pour l'avancee
   du Projet.

   Un acces `a GNATS est fourni aux developpeurs de FreeBSD aussi
   bien qu'`a la communaute. Afin de maintenir la coherence de la
   base de donnees et fournir une experience uniforme d'utilisateur,
   des directives ont ete etablies couvrant les aspects courants de
   la gestion de bogue comme la presentation des requetes de suivi,
   de fermeture et ainsi de suite.

     --------------------------------------------------------------

2. Le cycle de vie d'un rapport de bogue

     * L'auteur soumet un rapport de bogue ("PR") et rec,oit un
       message de confirmation la plupart du temps via send-pr(1) ou
       la page Web de rapport des bogues `a  
       http://www.FreeBSD.org/send-pr.html.

     * Joe Random Committer s'interesse au PR et se l'assigne, ou
       Jane Random BugBuster decide que Joe est le plus competent
       pour s'en occuper et le lui assigne.

     * Joe a un bref echange avec l'auteur (s'assurant que que cela
       ira dans le rapport d'audit) et determine la cause du
       probleme. Il s'assure ensuite que la cause du probleme est
       documentee dans le rapport d'audit, et positionne l'etat du
       rapport de bogue sur "analyse" ("analysed").

     * Joe passe une nuit blanche `a travailler et produit un
       correctif dont il pense qu'il corrigera le probleme, et le
       soumet dans le suivi du rapport, demandant `a son auteur de le
       tester. Il fixe ensuite l'etat du rapport de bogue sur
       "retour" ("feeback").

     * Quelques echanges plus tard, Joe et l'auteur sont satisfaits
       du correctif, et Joe l'integre `a la branche -CURRENT (ou
       directement `a la branche -STABLE si le probleme n'existe pas
       sur la branche -CURRENT), s'assurant de bien faire reference
       au rapport de bogue dans le commentaire de son "commit" (et
       creditant l'auteur s'il a soumis tout ou une partie du
       correctif) et, si approprie, commence le decompte de
       l'integration dans la branche -STABLE ("MFC").

     * Si le correctif ne necessite pas d'integration, Joe ferme
       alors le PR.

     * Si le correctif necessite une integration, Joe laisse le
       rapport de bogue dans l'etat "corrige" ("patched") jusqu'`a ce
       que le correctif soit integre, et puis le ferme.

     Note : Beaucoup de PRs sont soumis avec tres peu d'information
     sur le probleme, et certains sont soit tres complexes `a
     resoudre, soit effleurent juste un probleme bien plus important;
     dans ces cas, il est vraiment important d'obtenir toute
     l'information necessaire `a la resolution du probleme. Si le
     probleme decrit par le rapport ne peut etre resolu, ou s'est
     reproduit, il est necessaire de rouvrir le PR.

     Note : L'adresse electronique utilisee dans le rapport de bogue
     pourrait ne pas pouvoir recevoir de courrier. Dans ce cas,
     faites le suivi du PR comme `a l'accoutume et demandez `a
     l'auteur (dans le message de suivi) de fournir une adresse
     electronique fonctionnant. C'est habituellement le cas quand
     send-pr(1) est utilise depuis un systeme ayant la gestion du
     courrier desactivee ou non installee.

     --------------------------------------------------------------

3. Etat du rapport de bogue

   Il est important de maintenir `a jour l'etat d'un PR quand des
   mesures ont ete prises. L'etat devrait refleter exactement l'etat
   actuel du travail sur le rapport de bogue.

   Exemple 1. Un petit exemple sur le changement de l'etat d'un PR

   Quand un PR a ete etudie et que le(s) developpeur(s)
   responsable(s) se sent(ent) satisfait(s) du correctif, ils
   soumettront un suivi au rapport de bogue et changeront l'etat en
   "retour" ("feedback"). A ce moment-l`a l'auteur du rapport devrait
   evaluer le correctif dans son contexte et repondre en indiquant si
   le defaut a ete en effet corrige.

   Un rapport de bogue peut etre dans un des etats suivants:

   open - "ouvert"

           Etat initial, le probleme a ete constate et il a besoin
           d'etre passe en revue.

   analyzed - "analyse"

           Le probleme a ete passe en revue et une solution est
           cherchee.

   feedback - "retour"

           Un travail plus approfondi exige une information
           supplementaire de la part de l'auteur ou de la communaute,
           probablement de l'information concernant la solution
           proposee.

   patched - "corrige"

           Un correctif a ete commis, mais quelques problemes ("MFC",
           ou peut etre une confirmation de l'auteur) sont encore en
           suspens.

   suspended - "suspendu"

           Personne ne travaille sur le probleme, 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 probleme ne peut etre resolu, il
           sera ferme, plutot que suspendu. Le projet de
           documentation utilise "suspendu" pour les elements qui
           necessitent une quantite significative de travail pour
           laquelle personne n'a actuellement le temps.

   closed - "ferme"

           Un rapport de probleme est ferme quand tous les
           changements ont ete integres, documentes, et testes, ou
           quand la correction du probleme est abandonnee.

     Note : L'etat "corrige" est directement lie au retour, vous
     pouvez donc directement passer en etat "ferme", si l'auteur ne
     peut tester le correctif, et etant donne que cela fonctionne.

     --------------------------------------------------------------

4. Types de rapport de bogues

  4.1. PRs assignes

   Si un PR a son champ responsible complete avec le nom
   d'utilisateur d'un developpeur FreeBSD, cela signifie que le PR a
   ete confie `a cette personne pour davantage de travail.

   Les PRs assignes ne devraient pas etre touches par n'importe qui
   mais par la personne designee. Si vous avez des commentaires,
   soumettez un message de suivi. Si pour une raison ou une autre
   vous pensez que le PR devrait etre change d'etat ou reassigne,
   envoyez un message `a la personne assignee. Si cette derniere ne
   repond pas dans un delai de deux semaines, desassignez le PR et
   faites ce qu'il vous plait.

     --------------------------------------------------------------

  4.2. Doublons

   Si vous trouvez plus d'un PR decrivant le meme probleme,
   choisissez celui qui contient la plus grande quantite
   d'information utile et fermez les autres, en precisant clairement
   le numero du PR de remplacement. Si plusieurs PRs contiennent des
   informations utiles mais differentes, soumettez ce qui est
   manquant dans un PR que vous gardez ouvert par l'intermediaire
   d'un rapport de suivi, en faisant reference aux PRs que vous
   fermez.

     --------------------------------------------------------------

  4.3. PRs "eventes"

   Un PR est considere comme "evente" s'il n'a pas ete modifie en
   plus de six mois. Appliquez la procedure suivante:

     * Si le PR contient suffisamment de details, essayez de
       reproduire le probleme sur les branches -CURRENT et -STABLE.
       Si vous reussissez, soumettez un rapport de suivi detaillant
       vos resultats et trouvez quelqu'un `a qui l'assigner. Placez
       l'etat sur "analyse" si c'est approprie.

     * Si le PR decrit un probleme dont vous savez que c'est le
       resultat d'une erreur d'utilisation (configuration incorrecte
       ou autre), soumettez un rapport de suivi expliquant ou s'est
       trompe l'auteur, ensuite fermez le PR avec comme raison "User
       error" (Erreur d'utilisation) ou "Configuration error" (Erreur
       de configuration).

     * Si le PR decrit une erreur dont vous savez qu'elle a ete
       corrigee dans les branches -CURRENT et -STABLE, fermez-le avec
       un message precisant quand cela a ete corrige dans chaque
       branche.

     * Si le PR decrit une erreur dont vous savez qu'elle a ete
       corrigee dans la branche -CURRENT, mais pas dans la branche
       -STABLE, essayez de voir si la personne qui l'a corrige
       projette de faire l'integration dans la branche -STABLE, ou
       essayez de trouver quelqu'un (peut-etre vous-meme?) pour le
       faire. Placez l'etat sur "retour" et assignez-le `a quiconque
       fera l'integration.

     * Dans tous les autres cas, demandez `a l'auteur de confirmer si
       le probleme existe toujours dans les nouvelles versions. Si
       l'auteur ne repond pas sous un mois, fermez le PR avec la
       mention "Feedback timeout" (Delai de retour expire).

     --------------------------------------------------------------

        Ce document, ainsi que d'autres peut etre telecharge sur
                   ftp.FreeBSD.org/pub/FreeBSD/doc/.

Pour toutes questions `a propos de FreeBSD, lisez la documentation avant
                 de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.
