Guide de Référence du Développeur Debian - chapitre 4
Le système de suivi des bugs

Ce chapitre explique le système de traitement des bugs de Debian aux mainteneurs Debian. Si vous voulez savoir comment reporter un bug ou comment accéder aux informations sur les bugs reportés, regardez plutôt Le Manuel de l'utilisateur Debian.

Initialement, un rapport de bogue est soumis par un utilisateur par un simple courrier électronique à submit@bugs.debian.org. Il lui sera alors donné un numéro, un accusé de réception sera envoyé à l'utilisateur et le message sera envoyé vers la liste de diffusion debian-devel. Si l'utilisateur a inclus une ligne `Package' indiquant un paquet avec un mainteneur connu, ce mainteneur recevra une copie lui aussi.

Bug#nnn: sera ajouté à la ligne `Subject', et le champ `Reply-To' inclura et l'auteur du rapport de bug, et nnn@bugs.debian.org.


4.1 Manipuler les rapports de bugs


4.1.1 Clore un rapport de bug

Un développeur qui voit un bug sur debian-devel et qui en prend la responsabilité devrait envoyer une réponse, en utilisant la fonction `Répondre' de son logiciel favori et en éditant le champ `À' pour envoyer nnn-done@bugs.debian.org au lieu de nnn@bugs (nnn-close est un alias pour nnn-done).

L'adresse de l'auteur originel du rapport de bug sera incluse dans le champ 'To' parce que le système de gestion des bugs l'avait inclus dans le champ `Reply-To.'

Les messages `Done' messages ne sont pas automatiquement envoyés dans la liste de diffusion, il pourrait donc parfois valoir la peine d'inclure la liste de diffusion debian-devel si les autres développeurs peuvent être intéressés.

La personne qui clôt le rapport de bug et la personne qui l'a soumis recevront chacun une notification du changement de statut du rapport.


4.1.2 Messages suivis

Si un développeur veut répondre à un rapport de bug sans marquer le bug comme résolu, il peut simplement répondre au message. Sa réponse ira (par défaut) à nnn@bugs et à l'auteur du rapport de bug. Le système de suivi de bug archivera la réponse avec le reste des traces pour ce rapport de bug et le fera suivre à debian-devel. Le bug ne sera pas marqué comme résolu.

Si vous voulez envoyer une réponse à un message qui n'est pas appropriée pour debian-devel, vous pouvez le faire en envoyant votre réponse à nnn-quiet@bugs ou nnn-maintonly@bugs, qui l'archivera simplement (sans le faire suivre aucunement) et l'enverra seulement au mainteneur du paquet en question.

N'utilisez pas les fonctionnalités `reply to all recipients' ou `followup' de votre outil de courrier, a moins d'avoir l'intention de modifier ensuite les destinataires. En particulier, n'envoyer pas un message de followup à nnn@bugs.debian.org et à submit@bugs.debian.org simultanément parce que le système de suivi de bug recevrait alors deux copies de chaque et chacune serait renvoyée à debian-devel séparément.


4.1.3 Enregistrer que vous avez fait suivre un rapport de bug

Quand un développeur fait suivre un rapport de bug au développeur d'un paquet plus général dont est dérivé le paquet Debian, il doit le noter dans le système de suivi de bug comme suit :

Vérifiez que le champ `To' de votre message à l'auteur contient uniquement l'adresse de l'auteur; mettez ensuite la personne qui a rapporté le bug et nnn-forwarded@bugs.debian.org dans le champ `CC'.

Demandez à l'auteur de respecter le `CC' à nnn-forwarded@bugs quand il répond, pour que le système de suivi de bug archive sa réponse avec le rapport original.

Quand le système de suivi de bug reçoit un message à nnn-forwarded, il marque le bug correspondant comme ayant été transmis à (aux) adresse(s) figurant dans le champ `To' du message qu'il reçoit.

Vous pouvez aussi manipuler l'information `forwarded to' en envoyant des messages à control@bugs.


4.1.4 Messages de résumé à `debian-devel'

Chaque vendredi, une liste des bugs non résolus est postée à debian-devel, triée suivant l'âge du rapport; chaque mardi, une liste des rapports de bug non résolus depuis trop longtemps est postée, triée suivant le mainteneur du paquet.

Si le mainteneur d'un paquet est listé incorrectement, c'est habituellement parce que le mainteneur a changé récemment, et le nouveau mainteneur n'a pas encore envoyé de nouvelle version du paquet avec un champ de contrôle `Maintainer' modifié. Ceci sera réglé quand le paquet sera envoyé une autre solution, il y a un fichier que les mainteneurs de la distribution peuvent éditer pour enregistrer les changements de mainteneur. Par exemple, si un nouveau paquet n'est pas prévu pour une période suffisamment longue, vous pouvez contacter iwj-mastercron@master.debian.org pour que le changement soit forcé.


4.1.5 Réouvrir, réassigner et manipuler des bugs

Il est possible de réassigner des rapports de bug à d'autres paquets, d'en réouvrir certains clos par erreur, de modifier l'information disant où l'information a été forwardée, si elle l'a été, de changer les titres des rapports et de fusionner et séparer des rapports de bug. Ceci est fait en envoyant des courriers électroniques à control@bugs.debian.org.

Le format de ces messages est décrit dans les section suivantes.


4.1.6 Fonctionnalités plus ou moins obsolètes (étude des sujets)

Les messages qui arrivent pour soumission ou les bugs dont le sujet commence par Bug#nnn sont traités comme ayant déjà été envoyés à nnn@bugs. Ceci pour des raisons de compatibilité ascendante avec les courriers envoyés depuis les anciennes adresses et pour éviter les messages de followup envoyés par erreur à pour soumission (par exemple, en utilisant `reply to all recipients').

Un schéma similaire est utilisé pour `maintonly,' `done,' `quiet,' et `forwarded,' qui traitent les courriers arrivant avec un champ `Subject' modifié comme ayant été envoyés à l'adresse nnn-whatever@bugs correspondante.

Les messages arrivant sans numéro de rapport de bug dans leur adresse, ni dans leur champ Subject seront archivés comme `junk' et gardés pendant quelques semaines, mais autrement ignorés.


4.1.7 Projets futurs

Le champ `Package:' de l'en-tête devrait devenir obligatoire - actuellement, en cas d'oubli, seul un avertissement est généré.


4.1.8 Fonctionnalité obsolète `X-Debian-PR: quiet'

Ceci est utilisé pour empècher le système de suivi de bugs de transmettre n'importe où des messages qu'il reçoit à debian-bugs, en rajoutant une ligne X-Debian-PR: quiet dans l'en-tète du courrier.

Cette en-tète est maintenant ignorée. A la place, envoyez vos messages à quiet ou nnn-quiet (ou maintonly ou nnn-maintonly).


4.2 L'interface de contrôle par courrier

En plus du serveur de courrier sur request@bugs.debian.org qui permet la recherche de données sur les bugs et de documentation par courrier électronique, il y a un autre serveur à control@bugs.debian.org qui permet de manipuler les rapports de bugs de plusieurs façons.

Le serveur de contrôle fonctionne de la même façon que le serveur de requêtes, excepté qu'il a quelques commandes supplémentaires; en fait, c'est le même programme. Les deux adresses sont seulement séparées pour éviter que les utilisateurs ne fassent des erreurs et causent des problèmes en essayant juste d'obtenir des informations.

Regardez 'introduction au serveur de requêtes disponible sur le World Wide Web, dans le fichier bug-maint-mailcontrol.txt ou en demandant de l'aide à chaque serveur de courrier pour les bases d'utilisation des serveurs et les différentes commandes disponibles quand on écrit à une adresse.

La carte de référence pour les serveurs de courrier est disponible via le WWW, dans le fichier bug-mailserver-refcard.txt ou par courrier électronique en utilisant la commande `refcard'.

Voici la liste des commandes disponibles :

close bugnumber
Ferme le rapport de bug `#bugnumber.'

Une notification est envoyée à l'utilisateur qui a soumis le bug, mais (en différence avec le courrier envoyé à bugnumber-done@bugs) le texte du courrier qui a clos le bug n'est pas inclus dans cette notification. Le mainteneur qui a fermé un rapport devrait s'assurer, probablement en envoyant un message séparé, que l'utilisateur qui a soumis le bug sait pourquoi il a été clos.

reassign bugnumber package
Enregistre que le rapport de bug `#bugnumber' est un bug dans un paquet. Ce peut être utilisé pour fixer le paquet si l'utilisateur a oublié la pseudo-entête, ou pour modifier une assignation précédente. Aucune notification n'est envoyée à qui que ce soit (autrement que les informations usuelles transcrites lors des traitements).

reopen bugnumber [originator-address|=]
Réouvre `#bugnumber' si il a été fermé.

Par défaut, vous êtes enregistré comme étant à l'origine du rapport, donc que vous recevrez l'accusé quand il sera fermé une nouvelle fois. Ceci pour éviter d'inonder un innocent utilisateur avec plusieurs notifications sur un même rapport de bug.

Si vous rajoutez une adresse d'origine, l'auteur du rapport de bug sera enregistré à l'adresse que vous avez rajouté. Vous pouvez utiliser `=' pour conserver l'auteur original des traitements précédents. Il est habituellement un bonne idée d'annoncer à la personne qui est enregistrée comme auteur du rapport de bug que vous réouvrez le rapport, pour qu'elle s'attende à recevoir l'accusé de clôture du bug.

Si le bug n'est pas fermé, alors le réouvrir ne fera rien, même pas changer l'auteur original. Il n'y a aucune manière de changer l'auteur original d'un rapport de bug ouvert (ceci est délibéré pour qu'il ne puisse pas y avoir de rapport de bug fermé et détruit 28 jours plus tard sans que personne ne soit au courant.

forwarded bugnumber address
Enregistre que le rapport de bug a été passé à un mainteneur à l'adresse address. Ceci n'envoie pas le message à la personne concernée. Ceci peut être utilisé pour modifier une adresse de forwarded-to erronée, ou pour en enregistrer un nouveau pour un bug n'ayant pas été noté comme ayant précédemment été transmis.

notforwarded bugnumber
Efface toute trace que le rapport de bug a été transmis à un quelconque mainteneur. Si le bug n'a pas été enregistré comme ayant été transmis, alors ceci ne fera rien.

retitle bugnumber new-title
Change le titre d'un rapport de bug pour celui spécifié (par défaut, il s'agit du champ Subject de l'en-tête du courrier du rapport original).

Contrairement à beaucoup des commandes de manipulation de bug utilisées sur un rapport parmi quelques-uns fusionnés, celle-ci changera uniquement le titre du bug concerné et pas ceux des rapports avec lesquels il est fusionné.

merge bugnumber bugnumber ...
Fusionne deux ou plusieurs rapports de bug. Quand des rapports sont fusionnés, ouvrir, fermer, marquer comme transmis ou supprimer cette marque et réassigner un des bugs à un nouveau paquet aura un effet identique sur tous les autres rapports fusionnés.

Avant que les bugs puissent être fusionnés, ils doivent exactement dans le même état : soit tous ouverts, soit tous fermés, avec la même adresse de mainteneur forwarded-to, si ils ont été transmis ou aucun marqué comme transmis, et tous assignés au(x) même(s) paquet(s) (une comparaison exacte des chaînes de caractères est faite su la paquet auquel le bug est assigné). Si ils ne sont pas dans le même état au départ, vous devrez utiliser réassigne, réouvre et les autres pour vous assurer qu'ils se trouvent dans le même état avant de les fusionner

Si un des bugs listés dans la commande de fusion est déjà fusionné avec un autre bug, alors tous les rapports fusionnés avec un de ceux listés seront fusionnés ensemble. La fusion est comme l'égalité : c'est réflexif, transitif and symétrique.

Fusionner des rapports de bug cause l'apparition d'une note dans les traces de chacun des rapports; sur les pages WWW, des liens sur les autres bugs sont rajoutés

Les rapports fusionnés sont tous expirés simultanément, et uniquement quand chacun des paquets pris séparément répond aux critères d'expiration.

unmerge bugnumber
Sépare un rapport de bug d'autres rapports de bug avec lesquels il a été fusionné. Si le rapport listé est fusionné avec plusieurs autres, alors ils sont tous laissés fusionnés ensemble, et seules leurs associations avec le bug explicitement cité sont supprimées.

Si plusieurs rapports de bugs sont fusionnés et que vous voulez les séparer en deux groupes séparés de rapports fusionnés, vous devez séparer chacun des rapports des nouveaux groupes séparément et alors les fusionner dans les nouveaux groupes désirés.

Vous pouvez uniquement séparer un rapport de bug des autres rapports de bug fusionnés avec chaque commande unmerge; si vous voulez séparer plus d'un rapport de bug, ajoutez simplement quelques commandes unmerge à votre message.


4.3 Résumé des commandes disponibles


4.3.1 Synopsis des commandes disponibles à `request@bugs.debian.org'


4.3.2 Liste des fichiers d'informations pour `getinfo'


4.3.3 Synopsis des commandes supplémentaires disponibles sur le serveur de courriers de contrôle


Guide de Référence du Développeur Debian - Copyright ©1997 Christian Schwarz.
Table des matières; précédent.
version 0.1, 15 octobre 1998
Christian Schwarz schwarz@debian.org
basé sur des documents précédemment écrits par Ian Jackson ijackson@gnu.ai.mit.edu
version française par Hervé FlochHerve.Floch@Linux.EU.Org