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
.
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.
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.
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
.
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é.
control@bugs.debian.org
.Le format de ces messages est décrit dans les section suivantes.
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.
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
).
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
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
reopen bugnumber [originator-address|=]
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
notforwarded bugnumber
retitle bugnumber new-title
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 ...
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
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.
send bugnumber
send-detail bugnumber
index [full]
index-summary by-package
index-summary by-number
index-maint
index maint maintainer-substring
send-unmatched [this|0]
send-unmatched last|-1
send-unmatched old|-2
getinfo filename
(voir plus bas)help
refcard
quit|stop|thank...|--...
#...
_(comment)_debug level
maintainers
override.stable
override.development
override.contrib
override.non-free
override.experimental
override.codeword
pseudo-packages.description
pseudo-packages.maintainers
close bugnumber
(vous devez expliquer
séparément à l'auteur pourquoi)reassign bugnumber package
reopen bugnumber [originator-address|=]
forwarded bugnumber address
notforwarded bugnumber
retitle bugnumber new-title
merge bugnumber bugnumber ...
unmerge bugnumber