diff --git a/fr_FR.ISO8859-1/articles/pr-guidelines/Makefile b/fr_FR.ISO8859-1/articles/pr-guidelines/Makefile new file mode 100644 index 0000000000..b4e09dedad --- /dev/null +++ b/fr_FR.ISO8859-1/articles/pr-guidelines/Makefile @@ -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" diff --git a/fr_FR.ISO8859-1/articles/pr-guidelines/article.sgml b/fr_FR.ISO8859-1/articles/pr-guidelines/article.sgml new file mode 100644 index 0000000000..e9aebf113e --- /dev/null +++ b/fr_FR.ISO8859-1/articles/pr-guidelines/article.sgml @@ -0,0 +1,357 @@ + + + + +%man; + %abstract; + %artheader; + %translators; + %man; +]> + +
+ + + Directives d'utilisation des rapport de bogues + + $FreeBSD$ + + + 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é). + + +
+
+