361 lines
14 KiB
Text
361 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.5 2002-12-11 16:24:29 gioria Exp $
|
||
Original revision: 1.8
|
||
-->
|
||
|
||
<!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 la plupart du temps
|
||
via &man.send-pr.1; ou la page Web de rapport des bogues <20>
|
||
<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
|
||
“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 ou 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 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 “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, vous pouvez donc directement passer en
|
||
<20>tat “fermé”, 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 tous les autres 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>
|