[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Correction du fichier Bugs/Developer.wml



Salut à tous,

Voici une autre correction du fichier Bugs/Developer.wml

Merci encore à Nicolas Bertolissio pour sa relecture.

A+,
Christian.
#use wml::debian::template title="Gestion des bogues Debian - informations pour les développeurs" NOHEADER=yes NOCOPYRIGHT=true #use wml::debian::translation-check translation="1.22" translation_maintainer="Christian Couder "

Informations pour les développeurs concernant le système de traitement des bogues

Initialement, un rapport de bogue est soumis par un utilisateur comme un message ordinaire à submit@bugs.debian.org. Il lui sera alors donné un numéro, un accusé de réception sera envoyé à l'utilisateur, et il sera transmis à debian-bugs-dist. Si celui qui a soumis le rapport a inclus une ligne Package indiquant un paquet ayant un mainteneur connu, le mainteneur recevra aussi une copie.

La ligne Subject se verra rajouter Bug#nnn:, et le Reply-To sera modifié pour inclure à la fois celui qui a soumis le rapport et nnn@bugs.debian.org.

Fermer un rapport de bogue

Un développeur qui reçoit un bogue du système de gestion, ou qui le voit sur debian-bugs-dist, et prend la responsabilité de celui-ci doit répondre à l'aide de son logiciel de courrier préféré, et modifier le champ To pour y inscrire nnn-done@bugs.debian.org à la place de nnn@bugs (nnn-close est fourni comme alias pour nnn-done).

L'adresse de celui qui a soumis le rapport de bogue sera incluse dans le champ To par défaut, parce que le système de gestion des bogues l'a inclus dans le Reply-To.

Les messages « Done » sont automatiquement envoyés à la liste de diffusion debian-bugs-closed uniquement. Si d'autres développeurs sont susceptibles d'être intéressés il peut être parfois utile d'inclure la liste de diffusion debian-devel@lists.debian.org.

La personne fermant le bogue et la personne l'ayant soumis recevront une notification du changement de statut du rapport.

Messages suivants

Si un développeur souhaite répondre à un rapport de bogue, il peut simplement répondre au message (cela ne marquera pas le bogue comme ayant été traité). Sa réponse ira (par défaut s'il respecte le champ Reply-To:) à nnn@bugs, et à celui qui a soumis le rapport de bogue original (note : ce sont deux adresses distinctes). Le système de gestion des bogues recevra le message à nnn@bugs, le transmettra au mainteneur du paquet, enregistrera la réponse avec les autres enregistrements de ce rapport de bogue et le transmettra à debian-bugs-dist.

Un développeur pourra explicitement envoyer un message à celui qui a soumis le bogue en envoyant un message à nnn-submitter@bugs.

Si vous souhaitez envoyer un message de réponse qui n'est pas approprié pour debian-bugs-dist vous pouvez le faire en l'envoyant à nnn-quiet@bugs ou nnn-maintonly@bugs. Un message envoyé à nnn-quiet@bugs est enregistré dans le système de gestion des bogues mais n'est transmis à aucun individu ni aucune liste de diffusion. Un message envoyé à nnn-maintonly@bugs est enregistré dans le système de gestion des bogues et est transmis au mainteneur du paquet en question.

N'utilisez pas les fonctions « répondre à tous les destinataires » ou « transférer » de votre logiciel de courrier sauf si vous avez l'intention d'éditer la liste des destinataires de manière substantielle. En particulier, vérifiez que vous n'envoyez pas de réponse à submit@bugs.debian.org.

Niveaux de gravité

Le système de bogues enregistre un niveau de gravité avec 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 inexploitables des programmes qui ne lui sont pourtant pas associés ou casse globalement le système ou cause des pertes sévères 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 politique Debian (c'est-à-dire qu'il viole une directive « must » ou « required »), ou, dans l'esprit du mainteneur du paquet, rend le paquet inadapté à la livraison.
important (important)
est un bogue ayant un effet majeur sur l'utilité du paquet, tout en ne le rendant pas complètement inutilisable par n'importe qui.
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 à priori simple à résoudre.
wishlist (liste de souhaits)
pour n'importe quelle demande d'une fonctionnalité, et aussi pour n'importe quel bogue très difficile à résoudre du fait de la conception du paquet.
fixed (corrigé)
pour les bogues qui ont été corrigés mais ne devraient pas encore être fermés. C'est une exception faite pour les bogues résolus par des envois de non-mainteneurs. Note : la marque « fixed » devrait être utilisée à la place.

Marques sur les rapports de bogues

Chaque bogue peut avoir zéro, un ou plusieurs ensembles de certaines marques. Ces marques sont affichées dans la liste des bogues quand vous regardez la page d'un paquet, et quand vous regardez l'enregistrement complet du bogue.

Les marques peuvent être indiquées en fournissant une ligne Tags dans le pseudo-en-tête quand le bogue est soumis (voyez les instructions pour signaler des bogues), ou en utilisant la commande tags avec le serveur de requêtes de contrôle.

Les marques disponibles actuellement pour les bogues sont :

patch (patch)
Un patch ou une procédure facile à suivre pour résoudre le bogue est incluse dans les enregistrements du bogue. S'il y a un patch mais qu'il ne résoud pas le bogue correctement ou cause d'autres problèmes, cette marque ne devrait pas être utilisée.
wontfix (ne va pas être résolu)
Ce bogue ne sera pas résolu. Peut être parce que c'est un choix entre deux façons arbitraires de faire les choses et que le mainteneur 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 causera d'autres problèmes, pires à d'autres, 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 mainteneur. De l'assistance d'un tiers est nécessaire pour diagnostiquer les causes du problème.
fixed (résolu)
Ce bogue a été résolu ou contourné (par un envoi d'un non-mainteneur, par exemple), mais il reste un problème qui doit être résolu. Cette marque remplace l'ancienne sévérité « 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 de façons dont ils ne devraient pas ; attaques par dénis de service qui devraient être résolues, etc). La pluspart des bogues de sécurité devraient aussi être indiqués par une sévérité critique (critical) ou grave (grave).
potato
Ce bogue s'applique particulièrement à la version potato de Debian.
woody
Ce bogue s'applique particulièrement à la version woody (non encore livrée) de woody.
sid
Ce bogue s'applique particulièrement à une architecture qui est pour l'instant non disponible (c'est à dire dans la distribution sid).

Les trois marques qui précèdent sont destinées à être utilisées principalement pour les bogues critiques pour la sortie de la version, pour lesquels il est important de savoir quelles distributions sont affectées afin d'appliquer les corrections (ou les suppressions) au bon endroit.

Enregistrer que vous avez traité un rapport de bogue

Quand un développeur envoie un rapport de bogue au développeur du paquet source original depuis lequel le paquet Debian est dérivé, il devrait noter cela dans le système de gestion de la manière suivante :

S'assurer que le champ To de son message à l'auteur ne comporte que l'adresse du ou des auteurs ; mettre à la fois la personne qui a rapporté le bogue et nnn-forwarded@bugs.debian.org dans le champ CC.

Demander à l'auteur de garder tel quel le CC vers nnn-forwarded@bugs quand il répond, de façon à ce que le système de gestion des bogues enregistre sa réponse avec le rapport original.

Quand le système de gestion des bogues reçoit un message à nnn-forwarded il marquera le bogue correspondant comme ayant été transmis à(aux) adresse(s) dans le champ To du message qu'il reçoit.

Vous pouvez aussi manipuler les informations « forwarded to » en envoyant des messages à control@bugs.debian.org.

Résumés postés à debian-bugs-reports

Chaque vendredi une liste de rapports de bogues non encore corrigés est postée à debian-bugs-reports, triée par date du rapport. Chaque mardi une liste de rapports de bogues auxquels il n'a pas été répondu depuis trop longtemps est postée, triée par mainteneur de paquet.

Si le mainteneur d'un paquet est inscrit de manière incorrecte cela est généralement dû au fait que le mainteneur a changé récemment, et que le nouveau mainteneur n'a pas encore soumis une nouvelle version du paquet avec le champ de contrôle Maintainer modifié. Cela sera corrigé quand le paquet sera remis à jour ; autrement, les mainteneurs des archives peuvent écraser à la main les informations concernant le mainteneur, par exemple si une reconstruction ou une remise à jour du paquet n'est pas prévue avant un certain temps. Contactez override-change@debian.org pour les modifications du fichier d'écrasement (override file).

Rouvrir, réassigner et manipuler les bogues

Il est possible de réassigner des rapports de bogues à d'autres paquets, de rouvrir des bogues fermés par erreur, de modifier l'information disant où, s'il y a lieu, un rapport de bogue a été transmis, de changer les gravités et titres des rapports et de fusionner et de diviser des rapports de bogue. Ceci 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 en texte seul peut aussi être obtenue en envoyant le mot help au serveur à l'adresse ci-dessus.

Possibilités plus ou moins obsolètes d'utiliser l'objet des messages

Les messages qui arrivent à submit ou bugs et dont le champ « Objet » (Subject) commence par Bug#nnn seront traités comme ayant été envoyés à nnn@bugs. 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 traite les messages arrivant avec un tel Objet comme ayant été envoyés à l'adresse correspondante nnn-XXXXXX@bugs.

Les messages arrivant à forwarded et done sans identificateur - i.e., 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 à part cela ignorés.

Fonctionnalité obsolète X-Debian-PR: quiet

Il était possible d'empêcher le système de gestion 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).

#use "otherpages.inc" #use "footer.inc"
Reply to: