Date: Fri, 24 May 2002 12:57:01 +0200 (CEST) From: Marc Fonvieille <marc@blackend.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/38492: French translation of pr-guidelines article Message-ID: <200205241057.g4OAv1cm035016@abigail.blackend.org>
next in thread | raw e-mail | index | archive | help
>Number: 38492
>Category: docs
>Synopsis: French translation of pr-guidelines article
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: update
>Submitter-Id: current-users
>Arrival-Date: Fri May 24 04:00:11 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Marc Fonvieille
>Release: FreeBSD 4.6-PRERELEASE i386
>Organization:
>Environment:
System: FreeBSD abigail.blackend.org 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #5: Sun May 12 00:30:43 CEST 2002 marc@abigail.blackend.org:/usr/src/sys/compile/ABIGAIL i386
>Description:
French translation of pr-guidelines article
>How-To-Repeat:
>Fix:
Apply the patch to fr_FR.ISO8859-1/ directory
--- articles.diff begins here ---
diff -ruN articles.org/Makefile articles/Makefile
--- articles.org/Makefile Sat Apr 27 22:49:24 2002
+++ articles/Makefile Fri May 24 12:45:22 2002
@@ -25,6 +25,7 @@
SUBDIR+= dialup-firewall
SUBDIR+= laptop
SUBDIR+= pxe
+SUBDIR+= pr-guidelines
ROOT_SYMLINKS+= new-users
diff -ruN articles.org/pr-guidelines/Makefile articles/pr-guidelines/Makefile
--- articles.org/pr-guidelines/Makefile Thu Jan 1 01:00:00 1970
+++ articles/pr-guidelines/Makefile Thu May 23 22:08:06 2002
@@ -0,0 +1,22 @@
+#
+# The FreeBSD Documentation Project
+# The FreeBSD French Documentation Project
+#
+# $FreeBSD: doc/en_US.ISO8859-1/articles/pr-guidelines/Makefile,v 1.1 2002/05/09 12:28:53 des Exp $
+# Original revision: 1.1
+#
+
+DOC?= article
+
+FORMATS?= html
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+JADEFLAGS+= -V %generate-article-toc%
+
+SRCS= article.sgml
+
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff -ruN articles.org/pr-guidelines/article.sgml articles/pr-guidelines/article.sgml
--- articles.org/pr-guidelines/article.sgml Thu Jan 1 01:00:00 1970
+++ articles/pr-guidelines/article.sgml Fri May 24 12:50:40 2002
@@ -0,0 +1,326 @@
+
+<!--
+ Problem Report Handling Guidelines
+ The FreeBSD Project - http://www.FreeBSD.org
+ The FreeBSD French Documentation Project
+
+ $Id$
+ 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: doc/en_US.ISO8859-1/articles/pr-guidelines/article.sgml,v 1.3 2002/05/23 00:42:35 keramida Exp $</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>
--- articles.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205241057.g4OAv1cm035016>