                Directives d'utilisation des rapports de bogues

  Dag-Erling Smo/rgrav

  Hiten Pandya

   Version: 8def749c53
   2013-11-13 07:52:45 +0000 par Hiroki Sato.
   Resume

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

   [ Multiples pages HTML / Page HTML unique ]

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

   Table des matieres

   1. Introduction

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

   3. Etat du rapport de bogue

   4. Types de rapport de bogues

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).
