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. &trans.a.fonvieille; Dag-ErlingSmørgrav HitenPandya $FreeBSD$ $FreeBSD$

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é. 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.

L'auteur soumet un rapport de bogue (“PR”) et reçoit un message de confirmation la plupart du temps via &man.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 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 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. 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 ou non installée.

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. 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 suspens. 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, vous pouvez donc directement passer en état “fermé”, si l'auteur ne peut tester le correctif, et étant donné que cela fonctionne.

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é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.

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.

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 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 -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é).