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