From owner-freebsd-doc Fri May 24 4: 0:43 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B538537B40C for ; Fri, 24 May 2002 04:00:12 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g4OB0Cm48219; Fri, 24 May 2002 04:00:12 -0700 (PDT) (envelope-from gnats) Received: from abigail.blackend.org (blackend.org [212.11.50.35]) by hub.freebsd.org (Postfix) with ESMTP id 0B8CB37B40B for ; Fri, 24 May 2002 04:00:08 -0700 (PDT) Received: from abigail.blackend.org (localhost [127.0.0.1]) by abigail.blackend.org (8.12.3/8.12.3/ - 15/04/02) with ESMTP id g4OAv2p9035017 for ; Fri, 24 May 2002 12:57:02 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: (from marc@localhost) by abigail.blackend.org (8.12.3/8.12.3/Submit) id g4OAv1cm035016; Fri, 24 May 2002 12:57:01 +0200 (CEST) (envelope-from marc) Message-Id: <200205241057.g4OAv1cm035016@abigail.blackend.org> Date: Fri, 24 May 2002 12:57:01 +0200 (CEST) From: Marc Fonvieille Reply-To: Marc Fonvieille To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/38492: French translation of pr-guidelines article Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >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 @@ + + + + +%man; + %abstract; + %artheader; + %translators; + %man; +]> + +
+ + + Directives d'utilisation des rapport de bogues + + $FreeBSD: doc/en_US.ISO8859-1/articles/pr-guidelines/article.sgml,v 1.3 2002/05/23 00:42:35 keramida Exp $ + + + 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 + freebsd-bugbusters@FreeBSD.org, ces directives + devraient être suivies par toute personne travaillant avec les + rapports de bogues de FreeBSD. + &abstract.license; + &abstract.disclaimer; + &trans.a.fonvieille; + + + + + Dag-Erling + Smørgrav + + + + Hiten + Pandya + + + + + +
+ Introduction + + 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. + + 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. +
+ +
+ Le cycle de vie d'un rapport de bogue + + + + L'auteur soumet un rapport de bogue (“PR”) et + reçoit un message de confirmation. + + + + 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. + + + + 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”). + + + + 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”). + + + + Quelques échanges plus tard, Joe et l'auteur sont + satisfaits du correctif, et Joe l'intègre à la branche + -CURRENT (ou directement à la branche + -STABLE si le problème n'existe pas sur la + branche -CURRENT), 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 + -STABLE (“MFC”). + + + + Si le correctif ne nécessite pas d'intégration, Joe ferme + alors le PR. + + + + 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. + + + + + 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. + + + 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. + +
+ +
+ Etat du rapport de bogue + + 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. + + + Un petit exemple sur quand doit-on changer un état + + 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é. + + + Un rapport de bogue peut être dans un des états + suivants: + + + + open - “ouvert” + + Etat initial, le problème a été constaté et il a besoin + d'être passé en revue. + + + + + analyzed - “analysé” + + Le problème a été passé en revue et une solution est + cherchée. + + + + + feedback - “retour” + + 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. + + + + + patched - “corrigé” + + Un correctif a été commis, mais quelques problèmes + (“MFC”, ou peut être une confirmation de + l'auteur) sont encore en suspend. + + + + + suspended - “suspendu” + + 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. + + + + + closed - “fermé” + + 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. + + + + + + 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. + +
+ +
+ Types de rapport de bogues + +
+ PRs assignés + + Si un PR a son champ responsible + 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. + + 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. +
+ +
+ Doublons + + 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. +
+ +
+ PRs “éventés” + + Un PR est considéré comme “éventé” s'il n'a pas été + modifié en plus de six mois. Appliquez la procédure suivante: + + + + Si le PR contient suffisamment de détails, essayez de + reproduire le problème sur les branches + -CURRENT et -STABLE. + 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é. + + + + 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). + + + + Si le PR décrit une erreur dont vous savez qu'elle a été + corrigée dans les branches -CURRENT et + -STABLE, fermez-le avec un message + précisant quand il a été corrigé dans chaque branche. + + + + Si le PR décrit une erreur dont vous savez qu'elle a été + corrigée dans la branche -CURRENT, mais + pas dans la branche -STABLE, essayez de + voir si la personne qui l'a corrigé projette de faire + l'intégration dans la branche -STABLE, + 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. + + + + 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é). + + +
+
+
--- 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