Merge from French CVS tree the translation of the PR guideline
PR: docs/38492 Submitted by: Marc Fonvieille <marc@FreeBSD-fr.ORG>
This commit is contained in:
Sebastien Gioria
parent
7e7514f204
commit
df14e9b8a5
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=13231
2 changed files with 378 additions and 0 deletions
21
fr_FR.ISO8859-1/articles/pr-guidelines/Makefile
Normal file
21
fr_FR.ISO8859-1/articles/pr-guidelines/Makefile
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
#
|
||||
# The FreeBSD Documentation Project
|
||||
# The FreeBSD French Documentation Project
|
||||
#
|
||||
# $FreeBSD$
|
||||
# Original revision: 1.1
|
||||
#
|
||||
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
357
fr_FR.ISO8859-1/articles/pr-guidelines/article.sgml
Normal file
357
fr_FR.ISO8859-1/articles/pr-guidelines/article.sgml
Normal file
|
|
@ -0,0 +1,357 @@
|
|||
|
||||
<!--
|
||||
Problem Report Handling Guidelines
|
||||
The FreeBSD Project - http://www.FreeBSD.org
|
||||
The FreeBSD French Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$Id: article.sgml,v 1.1 2002-05-25 16:24:44 gioria 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 rapport 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 suspend
|
||||
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 fournis 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 complexe à 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 contenu
|
||||
dans le rapport ne peut être résolu, ou s'est
|
||||
produit à nouveau, 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 suspend.</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éassigner, 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, avec les références 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 il 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éponds pas sous
|
||||
un mois, fermez le PR avec la mention “Feedback
|
||||
timeout” (Délai de retour expiré).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
</article>
|
||||
Loading…
Reference in a new issue