article.pdf

(113 KB) Pobierz
Directives d'utilisation
des rapports de bogues
Dag-Erling Smørgrav
Hiten Pandya
Version:
43184
2013-11-13 par hrs.
Résumé
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.
Version française de Marc Fonvieille
<blackend@FreeBSD.org>
.
Table des matières
1. Introduction ...........................................................................................................................
2. Le cycle de vie d'un rapport de bogue ..........................................................................................
3. Etat du rapport de bogue ...........................................................................................................
4. Types de rapport de bogues .......................................................................................................
1
1
2
3
1. 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 suspens 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 fourni aux développeurs de FreeBSD aussi bien qu'à la communauté. An 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.
2. Le cycle de vie d'un rapport de bogue
• L'auteur soumet un rapport de bogue (“PR”) et reçoit un message de confirmation la plupart du temps via
send-
pr(1)
ou la page Web de rapport des bogues à
http://www.FreeBSD.org/send-pr.html.
• 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 xe ensuite l'état du rapport de bogue
sur “retour” (“feeback”).
Etat du rapport de bogue
• 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.
Note
Beaucoup de PRs sont soumis avec très peu d'information sur le problème, et certains sont
soit très complexes à 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 décrit par le rapport ne peut être résolu, ou s'est reproduit, il est
nécessaire de rouvrir le PR.
Note
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
send-pr(1)
est utilisé depuis un système ayant la gestion du courrier désactivée
ou non installée.
3. 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 exacte-
ment l'état actuel du travail sur le rapport de bogue.
Exemple 1. Un petit exemple sur le changement de l'état d'un PR
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”
analyzed - “analysé”
feedback - “retour”
Etat initial, le problème a été constaté et il a besoin d'être passé en revue.
Le problème a été passé en revue et une solution est cherchée.
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.
2
Directives d'utilisation des rapports de bogues
patched - “corrigé”
suspended - “suspendu”
Un correctif a été commis, mais quelques problèmes (“MFC”, ou peut être une
confirmation de l'auteur) sont encore en suspens.
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.
Un rapport de problème est fermé quand tous les changements ont été in-
tégrés, documentés, et testés, ou quand la correction du problème est aban-
donnée.
closed - “fermé”
Note
L'état “corrigé” est directement lié au retour, vous pouvez donc directement passer en état
“fermé”, si l'auteur ne peut tester le correctif, et étant donné que cela fonctionne.
4. Types de rapport de bogues
4.1. 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é coné à 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éassigné, 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.
4.2. 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, en faisant référence aux PRs que vous fermez.
4.3. 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 incor-
recte 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 cela 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
3
PRs “éventés”
-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 tous les autres cas, demandez à l'auteur de confirmer si le problème existe toujours dans les nouvelles
versions. Si l'auteur ne répond pas sous un mois, fermez le PR avec la mention “Feedback timeout” (Délai de
retour expiré).
4

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin