Informations concernant le système de traitement des bogues pour les responsables de paquet et les trieurs de bogues
Initialement, un rapport de bogue est soumis par un utilisateur
comme un message ordinaire
à submit@bugs.debian.org
qui doit contenir
une ligne Package
(veuillez consulter
les instructions pour signaler un bogue pour
plus d'informations).
Ce rapport recevra un numéro, un accusé de réception sera envoyé
à l'utilisateur, et il sera transmis
à debian-bugs-dist
. Si la ligne
Package
indique un paquet ayant un responsable connu,
le responsable recevra aussi une copie.
Bug#
nnn:
sera ajouté à la ligne
Subject
, et l'en-tête
Reply-To
sera modifié pour inclure à la fois celui qui
a soumis le rapport et nnn@bugs.debian.org
.
- Fermer un rapport de bogue
- Destinataires des messages
- Niveaux de gravité
- Étiquettes pour les rapports de bogues
- Enregistrer que vous avez transmis un rapport de bogue
- Changer le propriétaire d'un bogue
- Responsables de paquet mal énoncés
- Rouvrir, réassigner ou utiliser un rapport de bogue
- S'inscrire à des bogues
- Possibilités plus ou moins obsolètes d'utiliser l'objet des messages
- Fonctionnalité obsolète
X-Debian-PR: quiet
Fermer un rapport de bogue
Un rapport de bogue devrait être fermé quand le problème est corrigé. On ne peut considérer qu'un problème dans un paquet est corrigé que lorsque le paquet qui comporte la correction est entré dans l'archive Debian.
Normalement, seule la personne ayant envoyé le rapport et le ou les responsables du paquet concerné devraient fermer un rapport de bogue. Il y a des exceptions à cette règle, par exemple, pour les bogues concernant des paquets inconnus ou des pseudopaquets génériques. Un bogue peut être aussi fermé par n’importe quel contributeur si le bogue concerne un paquet orphelin ou si le responsable du paquet a omis de le faire. Il est très important de mentionner la version dans laquelle il a été corrigé. En cas de doute, ne le fermez pas, demandez d’abord un conseil sur la liste de diffusion debian-devel.
Les rapports de bogue seront fermés en envoyant un courriel
à nnn-done@bugs.debian.org
. Le corps du message doit
contenir l'explication de la correction du bogue.
Avec les courriels reçus du système de suivi de bogues, il suffit, pour
fermer un rapport de bogue, de répondre à l'aide de son logiciel de courrier
préféré, et de modifier l'en-tête To
pour y inscrire
nnn-done@bugs.debian.org
à la place de
nnn@bugs.debian.org
(nnn-close
est fourni comme alias pour
nnn-done
).
Quand cela est possible, veuillez fournir une ligne
Version
dans les pseudo-en-têtes de votre message
quand vous fermez un rapport de bogue, de façon à ce que le système
de suivi des bogues connaisse la version du paquet qui contient le
correctif.
La personne qui a soumis le rapport de bogue, celle qui l'a fermé et la
liste debian-bugs-closed
seront informées du changement d'état
du rapport. La personne qui a soumis le rapport de bogue et la liste recevront
en outre le contenu du message envoyé à nnn-done
.
Destinataires des messages
Le système de suivi des bogues indique l'adresse de la personne
qui a soumis le rapport de bogue et l'adresse du rapport
(nnn@bugs.debian.org
) dans l'en-tête
Reply-To
après avoir fait suivre le rapport de
bogue. Veuillez remarquer que ce sont deux adresses différentes.
Si un développeur souhaite répondre à un rapport de bogue, il peut
simplement répondre au message, en respectant l'en-tête Reply-To
.
Cela ne fermera pas le rapport.
N'utilisez pas les fonctions « répondre à tous les
destinataires » ou « transférer » de votre logiciel de courrier sauf
si vous avez l'intention de modifier la liste des destinataires de
manière substantielle. En particulier, vérifiez que vous n'envoyez
pas de réponse à submit@bugs.debian.org
.
Les messages peuvent être envoyés aux adresses suivantes afin d'être enregistrés dans le système de suivi des bogues :
-
nnn
@bugs.debian.org
— ces messages seront aussi envoyés au responsable du paquet et transmis àdebian-bugs-dist
, mais pas à la personne qui a soumis le bogue ; -
nnn
-submitter@bugs.debian.org
— ces messages seront aussi envoyés à la personne qui a soumis le bogue et transmis àdebian-bugs-dist
, mais pas au responsable du paquet ; -
nnn
-maintonly@bugs.debian.org
— ces messages seront seulement envoyés au responsable du paquet, pas à la personne qui a soumis le bogue ni àdebian-bugs-dist
; -
nnn
-quiet@bugs.debian.org
— ces messages seront seulement enregistrés dans le système de suivi des bogues (comme c'est le cas de tous les précédents), mais ne seront envoyés à personne d'autre.
Pour plus d'informations sur les en-têtes permettant de supprimer les accusés de réception et sur les moyens d'envoyer des copies de messages en utilisant le système de suivi des bogues, voyez les instructions pour signaler les bogues.
Niveaux de gravité
Le système de bogues enregistre un niveau de gravité pour chaque
rapport de bogue. Celui-ci est mis à normal
par défaut,
mais peut être modifié soit en fournissant une ligne
Severity
dans le pseudo-en-tête quand le bogue est soumis
(voir les instructions pour signaler
les bogues), soit en utilisant la commande severity
avec le serveur de requêtes de
contrôle.
Les niveaux de gravité sont :
critical
(critique)- rend inexploitable des programmes qui ne lui sont pourtant pas associés, ou casse globalement le système, ou cause de sévères pertes de données, ou encore crée une faille dans la sécurité du système.
grave
(grave)- rend le paquet en question inutilisable ou presque, ou cause des pertes de données, ou introduit une faille de sécurité permettant l'accès aux comptes des utilisateurs qui se servent du paquet.
serious
(sérieux)- est une sévère violation de la charte Debian (grossièrement, il viole une directive « must » ou « required »), ou, dans l'esprit du responsable du paquet ou du responsable de la publication, rend le paquet non distribuable.
important
(important)- est un bogue ayant un effet majeur sur l'utilité du paquet, tout en ne le rendant pas complètement inutilisable.
normal
(normal)- la valeur par défaut, applicable à la plupart des bogues.
minor
(mineur)- un problème qui n'affecte pas l'utilité du paquet, et qui est a priori simple à résoudre.
wishlist
(liste de souhaits)- pour une demande d'une fonctionnalité, et aussi pour un bogue très difficile à résoudre du fait de la conception du paquet.
Certains niveaux de gravité sont considérés comme de niveau « critique pour la sortie de la prochaine version » ; c'est-à-dire que le bogue influera sur l'introduction du paquet dans la version stable de Debian. Actuellement, ce sont les niveaux critical, grave et serious. Pour connaître les règles complètes et canoniques qui indiquent quels problèmes méritent ces gravités, consultez la liste des problèmes critiques pour la sortie de la prochaine publication.
Étiquettes sur les rapports de bogues
Chaque bogue peut avoir zéro, un ou plusieurs ensembles d'étiquettes. Ces étiquettes sont affichées dans la liste des bogues quand vous consultez la page d'un paquet, et quand vous consultez l'enregistrement complet du bogue.
Les étiquettes peuvent être indiquées en fournissant une ligne
Tags
dans le pseudo-en-tête quand le bogue est soumis (consultez les
instructions pour signaler des bogues),
ou en utilisant la commande tags
avec le
serveur de requêtes de contrôle.
Séparez les différentes étiquettes avec des virgules, des espaces ou
les deux.
Les étiquettes actuellement disponibles sont :
patch
, wontfix
, moreinfo
, unreproducible
,
help
, security
, upstream
, pending
, confirmed
,
ipv6
, lfs
, d-i
, l10n
, newcomer
, a11y
, ftbfs
,
fixed-upstream
, fixed
, fixed-in-experimental
,
potato
,
woody
,
sarge
,
etch
,
lenny
,
squeeze
,
wheezy
,
jessie
,
stretch
,
buster
,
bullseye
,
bookworm
,
trixie
,
forky
,
sid
,
experimental
,
sarge-ignore
,
etch-ignore
,
lenny-ignore
,
squeeze-ignore
,
wheezy-ignore
,
jessie-ignore
,
stretch-ignore
,
buster-ignore
,
bullseye-ignore
,
bookworm-ignore
,
trixie-ignore
forky-ignore
.
Voici quelques renseignements détaillés sur les étiquettes :
patch
(rustine)- Une rustine ou une procédure facile à suivre pour résoudre le bogue est incluse dans les enregistrements du bogue. S'il y a une rustine mais qu'elle ne résout pas le bogue correctement ou cause d'autres problèmes, cette étiquette ne doit pas être utilisée.
wontfix
(ne sera pas corrigé)- Ce bogue ne sera pas corrigé. Peut-être parce que c'est un choix entre deux façons arbitraires de faire les choses et que le responsable et celui qui a soumis le bogue préfèrent des façons différentes de faire les choses, peut-être parce que changer le fonctionnement entraînera des problèmes plus graves pour certains, ou peut-être pour d'autres raisons.
moreinfo
(plus d'info)- Ce bogue ne peut pas être résolu tant que des informations supplémentaires n'auront pas été fournies par celui qui a soumis le bogue. Ce bogue sera fermé si celui qui l'a soumis ne fournit pas plus d'informations pendant une période de temps raisonnable (quelques mois). C'est pour les bogues du type « Ça ne marche pas ». Qu'est-ce qui ne marche pas ?
unreproducible
(non reproductible)- Ce bogue ne peut pas être reproduit sur le système du responsable. L'assistance d'un tiers est nécessaire pour diagnostiquer les causes du problème.
help
(aide)- Le responsable demande de l'aide pour traiter ce bogue.
Soit le responsable n'a pas les connaissances nécessaires pour
corriger ce bogue, soit il est surchargé et veut déléguer cette tâche.
Ce bogue n'est pas forcément adapté aux nouveaux contributeurs, sauf s'il est
aussi étiqueté
newcomer
. newcomer
(nouveau venu)- Ce bogue a une correction connue mais le responsable demande à quelqu'un d'autre de l'implémenter. C'est une tâche idéale pour les nouveaux contributeurs qui veulent s'investir dans Debian, ou qui veulent améliorer leurs connaissances.
pending
(en cours)- Une solution à ce bogue a été trouvée et une mise à jour sera faite prochainement.
fixed
(résolu)- Ce bogue a été corrigé ou contourné (par un envoi d'un non responsable, par exemple), mais il reste un problème qui doit être résolu. Cette marque remplace l'ancien niveau de gravité « fixed ».
security
(sécurité)- Ce bogue décrit un problème de sécurité dans un paquet (par exemple, mauvaises permissions permettant l'accès à des données qui ne devraient pas être accessibles, dépassement de limite de tampon permettant à des gens de prendre le contrôle d'un système par des moyens illicites, attaques par dénis de service qui devraient être résolues, etc.). La plupart des bogues de sécurité devraient aussi être signalés par le niveau de gravité critique (« critical ») ou grave (« grave »).
upstream
(original)- Ce bogue concerne la partie originale du paquet (et non la partie Debian).
confirmed
(confirmé)- Le responsable a examiné le bogue. Il le comprend et il est fondamentalement d'accord avec lui. Mais il reste au responsable à le corriger. (L'utilisation de cette étiquette est optionnelle ; elle est destinée principalement aux responsables qui doivent gérer un grand nombre de bogues ouverts.)
fixed-upstream
- Le bogue a été corrigé par le développeur amont, mais il n'est pas encore dans le paquet (pour une raison quelconque : peut-être est-il trop compliqué de rétroporter le changement ou trop insignifiant pour que cela vaille la peine de s'en occuper).
fixed-in-experimental
- Le bogue a été corrigé dans le paquet de la distribution experimental, mais pas encore dans la distribution unstable.
d-i
- Ce bogue concerne le développement de l'installateur Debian. Il est prévu que cette étiquette soit utilisée quand un bogue affecte le développement de l'installateur mais qu'il n'est pas rempli contre un paquet qui fait directement partie de l'installateur.
ipv6
- Ce bogue concerne la prise en charge du protocole IPv6 « Internet Protocol version 6 ».
lfs
- Ce bogue concerne la prise en charge des gros fichiers (plus de 2 gigaoctets).
l10n
- Ce bogue concerne la localisation du paquet.
a11y
- Ce bogue affecte l'accessibilité pour les utilisateurs handicapés. Il impacte en particulier l'ergonomie pour les personnes qui dépendent d'une technologie d'assitance (ou d'autres dispositifs adaptés) pour utiliser le système ou le paquet.
ftbfs
- La construction du paquet à partir du source a échouée. Si le bogue est assigné à un paquet source, la construction de ce paquet échoue. Si le bogue est assigné à un paquet binaire, la construction des paquets sources concernés échoue. L’étiquette est valable pour les environnements de construction non standard (par exemple, utilisation de Build-Depends à partir d’experimental), mais la sévérité devrait être inférieure à serious (release critical) dans de tels cas.
-
potato
,woody
,sarge
,etch
,lenny
,squeeze
,wheezy
,jessie
,stretch
,buster
,bullseye
,bookworm
,trixie
,forky
,sid
,experimental
- Ce sont des étiquettes de version qui ont deux effets. Quand elles sont utilisées pour un bogue, le bogue concerne seulement une version particulière (bien qu'il puisse concerner d'autres versions si d'autres étiquettes de version sont utilisées), sinon les principes normaux bogués/résolus/absents s'appliquent. Ce bogue ne doit également pas être archivé avant qu'il ne soit résolu dans la version.
-
sarge-ignore
,etch-ignore
,lenny-ignore
,squeeze-ignore
,wheezy-ignore
,jessie-ignore
,stretch-ignore
,buster-ignore
,bullseye-ignore
,bookworm-ignore
,trixie-ignore
forky-ignore
- Ce bogue, empêchant l'intégration dans la prochaine version, doit être ignoré pour les objectifs de publication de cette version particulière. Cette étiquette ne doit être utilisée que par le responsable de publication ; ne la positionnez pas vous-même sans son autorisation explicite.
Quelques renseignements sur les étiquettes particulières de version : les étiquettes de type *-ignore ignorent le bogue afin de pouvoir continuer à intégrer des paquets dans la distribution testing. Les étiquettes de version indiquent qu'un bogue ne peut pas être archivé tant qu'il n'est pas corrigé dans la ou les distribution(s) dans lequel il est indiqué. Elles indiquent également qu'un bogue ne peut être considéré que dans les différentes versions indiquées. (En d'autres termes, si une étiquette de version est utilisée, alors le bogue est considéré comme absent de toute version non étiquetée ; sinon les principes normaux — trouvé ou résolu — s'appliquent.)
Les étiquettes de version ne devraient pas être utilisées si la version appropriée du bogue produit le même effet car elles nécessiteront un ajout et une suppression manuelle. Si vous n'êtes pas sûrs qu'une étiquette de version est nécessaire, veuillez contacter les administrateurs du BTS de Debian (owner@bugs.debian.org) ou l'équipe de publication pour demander conseil.
Enregistrer que vous avez transmis un rapport de bogue
Quand un développeur envoie un rapport de bogue au développeur du paquet source original duquel est dérivé le paquet Debian, il devrait noter cela dans le système de suivi de la manière suivante :
S'assurer que l'en-tête To
de son message à l'auteur
ne comporte que l'adresse du ou des auteurs ; mettre la personne
qui a rapporté le bogue,
nnn-forwarded@bugs.debian.org
et nnn@bugs.debian.org
dans l'en-tête CC
.
Demander à l'auteur de garder tel quel le CC
vers
nnn-forwarded@bugs.debian.org
quand il répond,
de façon à ce que le système de suivi des bogues enregistre sa réponse
avec le rapport original. Ces messages sont simplement enregistrés et
ne sont pas renvoyés ; pour que les messages soient renvoyés
normalement, envoyez-les ausi
à nnn@bugs.debian.org
.
Quand le système de suivi des bogues reçoit un message
à nnn-forwarded
, il marquera le bogue correspondant
comme ayant été transmis à(aux) adresse(s) dans l'en-tête To
du
message qu'il reçoit, si le bogue n'est pas déjà marqué comme ayant été
transmis.
Vous pouvez aussi manipuler les informations
« forwarded to » en envoyant des messages
à control@bugs.debian.org
.
Changer le propriétaire d'un bogue
Dans les cas où la personne responsable de la correction d'un bogue n'est pas le responsable du paquet associé (par exemple, quand le paquet est maintenu par une équipe), il peut être utile d'enregistrer cette information dans le système de suivi des bogues. Pour aider à le faire, chaque bogue peut éventuellement avoir un propriétaire.
Le propriétaire peut être désigné en fournissant une ligne
Owner
dans le pseudo-en-tête quand le bogue est soumis
(voir les instructions pour signaler
les bogues), ou en utilisant les commandes owner
et
noowner
avec le serveur de requêtes de
contrôle.
Responsables de paquet mal énoncés
Si le responsable d'un paquet est inscrit de manière incorrecte,
c'est généralement dû au fait que le responsable a changé récemment,
et que le nouveau responsable n'a pas encore envoyé une nouvelle
version du paquet avec le champ de contrôle Maintainer
modifié. Cela sera corrigé quand le paquet sera mis à jour ;
autrement, les responsables de l'archive peuvent annuler à la main les
informations concernant le responsable, par exemple si une
reconstruction ou une mise à jour du paquet n'est pas prévue avant un
certain temps. Contactez override-change@debian.org
pour
les modifications du fichier d'annulation (« override
file »).
Rouvrir, réassigner ou utiliser un rapport de bogue
Il est possible de réassigner des rapports de bogues à d'autres
paquets, de rouvrir des bogues fermés par erreur, de modifier, s'il y
a lieu, l'information disant où un rapport de bogue a été transmis,
de changer les niveaux de gravité et les titres des rapports, de
déclarer le propriétaire d'un bogue, de fusionner et de diviser
des rapports de bogue, et d'enregistrer le numéro des versions
des paquets dans lesquels les bogues ont été trouvés et de celles
où ils ont été corrigés. Cela se fait en envoyant un message
à control@bugs.debian.org
.
Le format de ces messages est décrit
dans un autre document disponible sur la Toile ou dans le fichier
bug-maint-mailcontrol.txt
. Une version texte peut
aussi être obtenue en envoyant le mot help
au serveur
à l'adresse ci-dessus.
S'abonner à des bogues
Le système de suivi des bogues permet aussi à ceux qui ont soumis
le bogue, aux développeurs et aux tiers intéressés de s'abonner à des
bogues en particulier. Cette fonctionnalité peut être utilisée par
ceux qui souhaitent garder un œil sur un bogue, sans avoir
à s'abonner à un paquet par le biais du
Debian Package Tracker. Tous les
messages reçus sur nnn@bugs.debian.org
sont envoyés
aux abonnés.
S'abonner à un bogue se fait en envoyant un courriel
à nnn-subscribe@bugs.debian.org
. L'objet et le
corps du courriel sont ignorés par le système de suivi des bogues.
Une fois le message traité, les utilisateurs reçoivent un message de
confirmation auquel ils devront répondre avant de pouvoir recevoir les
messages en relation avec ce bogue.
Il est aussi possible de se désabonner d'un bogue.
Se désabonner se fait en envoyant un courriel
à nnn-unsubscribe@bugs.debian.org
. L'objet et le
corps du courriel sont une fois encore ignorés par le système de suivi
des bogues. Les utilisateurs recevront un message de confirmation auquel
ils devront répondre s'ils souhaitent être désabonnés du bogue.
Par défaut, l'adresse abonnée est celle qui se trouve
dans l'en-tête From
. Si vous souhaitez abonner
une autre adresse à un bogue, vous devrez coder l'adresse
à abonner dans le message d'abonnement. Cela ressemble à :
nnn-subscribe-
adresse=
exemple.com@bugs.debian.org
.
Cet exemple enverrait un message d'abonnement au bogue
nnn à adresse@exemple.com
. Le signe
arobase @
doit être codée en le remplaçant par un signe égal
=
. De manière analogue, un désabonnement ressemble
à nnn-unsubscribe-
adresse=
exemple.com@bugs.debian.org
.
Dans les deux cas, l'objet et le corp du courriel seront transmis
à l'adresse électronique dans la requête de confirmation.
Possibilités plus ou moins obsolètes d'utiliser l'objet des messages
Les messages qui arrivent à submit
ou bugs
et
dont l'en-tête « Objet » (« Subject ») commence par
Bug#
nnn seront traités comme ayant été envoyés
à nnn@bugs.debian.org
. Ceci pour
assurer la compatibilité ascendante avec les messages envoyés depuis les
anciennes adresses, et pour récupérer les réponses envoyées
à submit
par erreur (par exemple, en utilisant la commande
« répondre à tous les destinataires »).
Un schéma identique opère pour maintonly
,
done
, quiet
et forwarded
,
qui traitent les messages arrivant avec un tel « Objet » comme ayant été
envoyés à l'adresse correspondante
nnn-XXXXXX@bugs.debian.org
.
Les messages arrivant à forwarded
et done
sans identificateur — c'est-à-dire sans numéro de rapport de
bogue dans l'adresse — et sans numéro de bogue dans l'« Objet »
seront enregistrés sous « junk » et gardés pendant quelques
semaines, mais néanmoins ignorés.
Fonctionnalité obsolète X-Debian-PR:
quiet
Il était possible d'empêcher le système de suivi des bogues de
transmettre les messages qu'il recevait à debian-bugs
,
en mettant une ligne X-Debian-PR: quiet
dans l'en-tête
du message.
Cette ligne d'en-tête est maintenant ignorée. À la place, envoyez votre
message à quiet
ou nnn-quiet
(ou
maintonly
ou nnn-maintonly
).
Autres pages concernant le système de gestion des bogues (SGB ou BTS pour Bug Tracking System en anglais) :
- Page principale du système de gestion des bogues.
- Instructions pour signaler des bogues.
- Accéder aux enregistrements de bogues autrement que sur la Toile.
- Informations pour les développeurs sur le système de gestion des bogues.
- Informations pour les développeurs sur le traitement des bogues par messagerie électronique.
- Carte de référence des serveurs de messagerie.
- Requêtes de rapport de bogues par messages électroniques.
Debian BTS administrators <owner@bugs.debian.org>
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.