Attachment 22118 Details for Bug 38492 – articles.diff

[patch] articles.diff

articles.diff (text/plain), 13.40 KB, created by Marc Fonvieille on 2002-05-24 12:00:11 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Marc Fonvieille

Created: 2002-05-24 12:00:11 UTC

Size: 13.40 KB

patch

obsolete

>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 @@
>+
>+
>+
>+<!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">
>+  
>+  <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 -
>+	&ldquo;Problem Reports&rdquo;).  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&oslash;rgrav</surname>
>+      </author>
>+
>+      <author>
>+	<firstname>Hiten</firstname>
>+	<surname>Pandya</surname>
>+      </author>
>+    </authorgroup>
>+  </articleinfo>
>+  
>+
>+  <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 (&ldquo;PR&rdquo;) 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 &ldquo;analysé&rdquo;
>+	  (&ldquo;analysed&rdquo;).</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
>+	  &ldquo;retour&rdquo; (&ldquo;feeback&rdquo;).</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
>+	  &ldquo;commit&rdquo; (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> (&ldquo;MFC&rdquo;).
>+      </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 &ldquo;corrigé&rdquo;
>+	  (&ldquo;patched&rdquo;) 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
>+	&ldquo;retour&rdquo; (&ldquo;feedback&rdquo;).  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 - &ldquo;ouvert&rdquo;</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 - &ldquo;analysé&rdquo;</glossterm>
>+	<glossdef>
>+	  <para>Le problème a été passé en revue et une solution est
>+	    cherchée.</para>
>+	</glossdef>
>+      </glossentry>
>+
>+      <glossentry>
>+	<glossterm>feedback - &ldquo;retour&rdquo;</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 - &ldquo;corrigé&rdquo;</glossterm>
>+	<glossdef>
>+	  <para>Un correctif a été commis, mais quelques problèmes
>+	    (&ldquo;MFC&rdquo;, ou peut être une confirmation de 
>+	    l'auteur) sont encore en suspend.</para>
>+	</glossdef>
>+      </glossentry>
>+
>+      <glossentry>
>+	<glossterm>suspended - &ldquo;suspendu&rdquo;</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 &ldquo;suspendu&rdquo; 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 - &ldquo;fermé&rdquo;</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 &ldquo;corrigé&rdquo; 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 &ldquo;éventés&rdquo;</title>
>+
>+      <para>Un PR est considéré comme &ldquo;éventé&rdquo; 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 &ldquo;analysé&rdquo; 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 &ldquo;User error&rdquo; (Erreur
>+	    d'utilisation) ou &ldquo;Configuration error&rdquo; (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 &ldquo;retour&rdquo; 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 &ldquo;Feedback timeout&rdquo; (Délai de retour
>+	    expiré).</para>
>+	</listitem>
>+      </itemizedlist>
>+    </section>
>+  </section>
>+</article>

Actions: View | Diff

Attachments on bug 38492: 22118