357 lines
14 KiB
Text
357 lines
14 KiB
Text
|
|
<!--
|
|
Problem Report Handling Guidelines
|
|
The FreeBSD Project - http://www.FreeBSD.org
|
|
The FreeBSD French Documentation Project
|
|
|
|
$FreeBSD$
|
|
$Id: article.sgml,v 1.4 2002-09-22 16:46:13 blackend Exp $
|
|
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 rapports de bogues</title>
|
|
|
|
<pubdate>$FreeBSD$</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ø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 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 à Gnats est fourni 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 (“PR”) 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é” (“analysed”).</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 “retour” (“feeback”).</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> (“MFC”).
|
|
</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 complexes à 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 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 à
|
|
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 - “ouvert”</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 - “analysé”</glossterm>
|
|
<glossdef>
|
|
<para>Le problème a été passé en
|
|
revue et une solution est cherchée.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>feedback - “retour”</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 - “corrigé”</glossterm>
|
|
<glossdef>
|
|
<para>Un correctif a été commis, mais quelques
|
|
problèmes (“MFC”, ou peut être une
|
|
confirmation de l'auteur) sont encore en suspens.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>suspended - “suspendu”</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 - “fermé”</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 “corrigé” 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éassigné, 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, en faisant référence aux
|
|
PRs que vous fermez.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>PRs “éventés”</title>
|
|
|
|
<para>Un PR est considéré comme
|
|
“éventé” 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
|
|
“analysé” 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 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 “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épond pas sous
|
|
un mois, fermez le PR avec la mention “Feedback
|
|
timeout” (Délai de retour expiré).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|
|
</article>
|