Traductions: English - Français - Italiano



Session d'entrainement IRC Debian Women conduite par Gerfried Fuchs, le 09 Décembre 2010

Comment utiliser le Système de Suivi de Bogues (BTS)

Voici un tutoriel sur l'utilisation du système de suivi de bogues.

L'acronyme BTS signifie Bug Tracking System (ou Système de suivi de bogues en français). Il s'agit du système où le projet Debian réalise l'enregistrement et le suivi des rapports de bogues (y compris les demandes d'amélioration, pas uniquement les « véritables » bogues). Il s'agit en majorité d'un système basé sur le courrier électronique : on peut modifier ou effectuer des manipulations uniquement en envoyant un courrier électronique. Les courriers doivent être envoyés en format texte et non en HTML.

Pré-requis

Pré-requis techniques :

Interroger les rapports de bogues : l'interface web du BTS

L'interface Web du BTS se consulte sur http://bugs.debian.org/. À travers cette interface, vous pouvez lancer des recherches, assez rapidement (si le serveur n'est pas trop chargé) et assez facilement, sur les rapports de bogues.

Si vous allez sur http://bugs.debian.org, vous serez redirigé sur une page affichant un formulaire de recherche. Mais la chose la plus utile à propos de bugs.debian.org est les redirections plus spécifiques qu'il offre :

En haut des pages d'aperçu se trouve une liste de catégories de rapports de bogues (par gravité et statut). En bas, vous trouverez un formulaire qui vous permet d'élargir ou d'affiner votre recherche par des mots clés ou des propriétés des bogues comme leur statut ou leur âge. Notez également que dans la section principale de la page de présentation, juste après chaque numéro de bogue, se trouve une liste cryptique de caractères et de symboles entre deux crochets. Passer la souris sur l'un de ces symboles donne une info-bulle qui explique ce que cela signifie et si vous cliquez dessus, une fenêtre contextuelle apparait avec des informations supplémentaires sur le rapport de bogue à portée de main.

C'est une courte introduction à l'interface Web. N'oubliez pas qu'il est uniquement capable de récupérer des informations sur les bogues, alors n'hésitez pas à cliquer - rien de mal ne peut arriver !

Créer des rapports de bogues : reportbug

Pour signaler des bogues, vous aurez besoin d'un client de courrier électronique ou, mieux encore, vous pouvez utiliser le paquet reportbug. reportbug est un outil principalement en mode texte mais il existe deux interfaces graphiques : une basée sur urwid, l'autre sur GTK+. Il y a aussi reportbug-ng, un outil complètement différent, avec également une interface graphique et qui fait la même chose.

Ces outils imposent l'utilisation d'un MTA (Mail Transport Agent) comme postfix, exim ou ssmtp. Vous aurez à vous renseigner par ailleurs pour obtenir des détails sur la manière de les configurer.

Même lorsque vous ne disposez pas d'un MTA local, reportbug reste tout de même extrêmement utile car il dispose d'une option --template. Cette dernière vous aide à produire de l'information qui vous sera de toute manière demandée par le mainteneur du paquet, comme les versions du paquet avec le bogue et les paquets dont il dépend.

Pour l'essayer, lancez dans un terminal :

reportbug --template paquet

avec un nom de paquet que vous avez installé. N'ayez pas peur : cela ne fait rien de mal ! Cela permet juste d'afficher quelques lignes de texte. :)

En regardant la sortie, vous verrez plusieurs éléments importants qui devraient apparaitre sur tout le courriel de rapport de bogue. Tout d'abord, il y a l'adresse à laquelle nous envoyons le rapport :

To: Debian Bug Tracking System <submit@bugs.debian.org>

L'adresse submit@bugs.debian.org est l'adresse à laquelle les nouveaux rapports de bogues sont envoyés. Bien entendu vous devrez utiliser un titre compréhensible et bien descriptif qui permettra au mainteneur du paquet de voir quel est le problème (l'élément par défaut Subject: none n'est pas très utile !)

Ensuite, il y a un autre bloc qui commence avec Package:, a une ligne Version: et une autre Severity: :

Les trois premiers niveaux (grave, critical et serious) sont considérés comme critique pour la version et définissent un groupe spécial de rapports de bogues. Dans le doute, il ne faut pas les utiliser à moins de comprendre vraiment leur signification : certaines personnes peuvent réagir vivement lorsqu'ils sont employés dans le cas d'un rapport qui ne serait pas vraiment si grave. Je vous indiquerai la signification de ces rapports spéciaux un peu plus tard.

wishlist est le niveau de sévérité que vous devez utiliser pour les demandes d'amélioration que vous voudriez voir intégrées au paquet. Certains mainteneurs vous suggéreront probablement de faire ces demandes dans le projet originel. Soyez préparé à cette réaction, même si personnellement, je considère qu'un mainteneur de paquet doit être un lien entre les utilisateurs Debian et les développeurs amont.

Enfin, essayez d'être le plus descriptif possible non seulement dans le titre du bogue mais également dans le message du rapport. Ce serait encore mieux si vous pouviez indiquer une méthode permettant de reproduire votre bogue.

Pour une description plus systématique de la façon de signaler les bogues, voir http://www.debian.org/Bugs/Reporting, qui donne également plus d'informations sur les champs de pseudo-en-têtes et ce qui devrait apparaitre dans le corps du rapport de bogue.

Modifier les rapports de bogues : control@bugs.debian.org

Pour modifier les rapports de bogues, vous devez utiliser l'adresse control@bugs.debian.org. L'intégralité du système de suivi de bogues est ouvert à tous, comme cette adresse électronique. Cela signifie que techniquement tout le monde peut modifier un rapport de bogue. L'adresse de contrôle est le point d'entrée. Elle fonctionne comme l'adresse d'envoi sur les premières lignes du rapport de bogue.

La documentation de l'adresse électronique de contrôle est située sur http://www.debian.org/Bugs/server-control.

La syntaxe est généralement la suivante :

 commande numéro_de_bug arguments

La quantité d'arguments varie selon la commande employée.

Ainsi, avec la commande retitle:

retitle 12345 nouveau-titre

vous modifiez le titre du rapport de bogue 12345 en nouveau-titre.

N'ayez crainte, vous ne pouvez pas réaliser cette opération pour ce numéro de bogue car il est archivé. Vous ne pouvez modifier que les rapports de bogues qui n'ont pas déjà été archivés.

Une commande fréquemment utilisée est la commande reassign qui permet d'indiquer que le rapport de bogue concerne un paquet différent. Cette commande utilise un deuxième argument après le nom du paquet : un numéro de version. Si vous connaissez le numéro de version de l'autre paquet concerné par le bogue, il est très utile et nécessaire d'ajouter la version pour que le suivi de version puisse continuer à fonctionner. Je vais expliquer le suivi des versions un peu plus tard, et j'ai trouvé quelques exemples où vous pouvez voir comment cela fonctionne. :)

La commande tag améliore la classification des bogues. Lorsque vous créez un rapport de bogue, vous pouvez également ajouter des Tags (étiquettes) aux champs de pseudo en-têtes de votre message et affecter des étiquettes spécifiquement à un rapport de bogue.

Voici quelques étiquettes qui sont souvent employées :

La liste complète des étiquettes peut être consultée sur http://www.debian.org/Bugs/Developer#tags.

Les courriers à destination de l'adresse de contrôle sont stockés dans le BTS mais ne sont pas renvoyés ailleurs. Ainsi, ces messages sont souvent accompagnés d'un champ Cc vers bugnumber@bugs.debian.org. Ces courriers sont alors envoyés vers le mainteneur de paquet (ainsi qu'aux autres personnes abonnées à ce rapport de bogue particulier).

Si vous voulez vous abonner à un rapport de bogue en particulier, envoyez simplement un courrier électronique à bugnumber-subscribe@bugs.debian.org. Vous recevrez un courriel de confirmation à la suite de laquelle, vous recevrez tous les messages envoyés à ce rapport de bogue. Vous pouvez également souscrire à tous les rapports de bogues d'un paquet en utilisant le PTS (Package Tracking System ou Système de Suivi de Paquets en français) en allant sur http://packages.qa.debian.org/nom_du_paquet (remplacer nom_du_paquet par le paquet auquel vous désirez vous abonner). En bas à gauche, vous trouverez le formulaire d'inscription.

Bien sûr, le courrier envoyé à la fois à control@bugs et à bugnumber@bugs contient à la fois des commandes pour le serveur de contrôle et des informations pour les humains. Afin de ne pas confondre l'analyseur de contrôle avec le texte humain, il existe une commande spéciale, thanks, que vous avez peut-être remarquée après les commandes de contrôle indique au programme de contrôle d'arrêter de traiter le message à partir de là. Merci de vous soucier de ce programme et d'utiliser thanks pour terminer vos messages de contrôle. :)

Merci de prendre note que j'ai toujours dit que les courriers envoyés à bugnumber@bugs sont envoyés au mainteneur du paquet (et aux personnes qui sont abonnées à ce bogue). Ces courriers ne sont PAS envoyés à la personne qui a créé le rapport de bogue originel ! C'est quelque chose qui pourrait changer à l'avenir, mais pour le moment, vous devez soit détacher l'émetteur du rapport de bogue et l'ajouter explicitement aux copies, soit utiliser une autre adresse de messagerie pratique : bugnumber-submitter@bugs.debian.org.

Suivi de version

Qu'est-ce-que le suivi de version ?

Le BTS conserve la trace de la version d'un paquet dans laquelle un bogue a été corrigé et quelle version de Debian il affecte. C'est pourquoi le champ de pseudo en-tête Version: dans la création du rapport est très importante. Dans le cas contraire, le BTS pourrait croire que le bogue touche toutes les versions du paquet.

C'est également ici où je reviens vers le groupe spécial de bogues : les bogues critiques pour la version de Debian que j'ai mentionnés plus haut. Les rapports de bogues peuvent être archivés après 28 jours s'ils remplissent certaines conditions : en général, celle d'être corrigés dans unstable et dans testing.

Bien entendu, s'ils touchent toutes les version de Debian, ils sont également concernés par les architectures de Debian. Un rapport de bogue qui touche uniquement unstable mais pas testing (à cause de la version concernée) peut être archivé tout de suite.

Ainsi, les distributions concernées forment un critère, les architectures touchées, un autre. Si ces deux critères sont gérés et corrigés, le décompte du temps est lancé.

Les rapports de bogues peuvent être fermés selon plusieurs méthodes. La plus courante est par le versement d'un paquet contenant un message closes: #12345 dans le changelog. Lorsque le paquet est accepté dans l'archive Debian, un courrier électronique est envoyé à 12345-done@bugs.debian.org avec Version: 1.2.3 dans la première ligne du message. Cela peut évidemment être déclenché manuellement si un courrier est envoyé à numéro_de_bug-done@bugs avec une en-tête Version: qui indique également que le bogue a été corrigé dans cette version.

Si le rapport de bogue est un faux problème (comme, un faux rapport), alors la ligne Version: ne doit PAS être ajoutée au courrier.

Cette différence est nécessaire pour que le BTS puisse distinguer les bogues corrigés pour une version donnée et les bogues qui n'en sont pas vraiment.

Au plus tard, l'archivage interviendra après la période de 28 jours. Au plus tôt, il commencera seulement lorsque le paquet dans cette version sera synchronisé dans unstable sur toutes les architectures et également dans testing (si le bogue concerne testing).

Je n'ai pas encore touché un mot sur les rapports de bogues critiques pour la version de Debian qui sont envoyés ici et là.

Les rapports de bogues critiques pour la version de Debian devront AUSSI être corrigés pour la version stable avant de commencer le processus d'archivage. Ainsi, même si un rapport de bogue critique est fermé dans unstable, qu'il a migré dans testing et qu'il est synchronisé dans toutes les architectures, il ne sera PAS archivé tant que le suivi de version pensera qu'il affecte la version stable de Debian.

L'interface Web du BTS dispose d'une fonctionnalité très utile pour tout cela : le graphe de version. Vous les avez sans doute déjà remarqués dans quelques rapports de bogues, ils sont situés en haut à droite. Ils contiennent plusieurs boites : des rouges arrondies et des vertes rectangulaires. Les boites vertes indiquent les versions corrigées, les rouges sont les versions touchées par le bogue.

Comme indiqué plus haut, n'hésitez pas à cliquer partout, y compris sur les graphes de version. Cela vous permettra de mieux les comprendre. ;)

Exemple 1

Jetons un coup d’œil à un graphe de bogue simple :

Aperçu d'un rapport de bogue pour le bogue #598227 avant la tenue de ce tutoriel

Ce graphe est vraiment simple, il peut y en avoir de très complexes avec de nombreuses branches. Vous pouvez voir en haut la boite verte et également les versions de Debian (testing, unstable) qui y sont mentionnées. Sur la gauche, vous pouvez lire la sévérité : grave. Comme mentionné plus haut, nous sommes en présence d'un bogue critique pour la publication. C'est la raison pour laquelle il n'est pas encore archivé.

En lisant le rapport de bogue, on voit qu'il affecte la version stable de manière non justifiée : icedove 3 n'est pas dans stable et donc ce rapport n'a pas une sévérité grave pour cette version de Debian. Mais étant donné qu'on ne peut affecter de sévérité à la version de publication, l'étiquette mentionnée précédemment peut maintenant intervenir.

Il existe en effet des étiquettes pour les distributions. Lors de mon travail sur la réduction du nombre de bogues critiques pour la publication de la version stable de Debian, je suis tombé sur de nombreux bogues comme celui-ci. J'ai donc étiqueté ce rapport comme suit :

 tag 598274 + squeeze sid

ce qui indique qu'il ne concerne pas Lenny.

Si un rapport de bogue dispose d'une étiquette de version, le BTS le considère comme touchant uniquement les versions mentionnées. Si vous disposez d'un MTA local et que vous avez renseigné la variable d'environnement DEBEMAIL comme je l'ai fait, il existe un outil très utile dans le paquet devscripts : il s'appelle bts (et devinez à quoi il sert ?).

bts est un client en ligne de commande pour le BTS et me permet d'envoyer juste un simple courrier pour corriger le problème grâce à la commande :

bts tag 598274 + squeeze sid  '# not relevant for stable'

Ainsi, lorsqu'on poursuit la lecture du rapport de bogue, il semble que la version corrigée 0.7.3-3 soit fausse et qu'elle doit être supprimée :

bts notfound 598274 0.7.3-3

Dans la pratique, ces commandes peuvent être chainées et combinées, en les séparant avec des points.

C'est très utile lorsqu'on veut réaliser plusieurs opérations en une seule, en produisant un seul courrier au lieu de plusieurs.

Si vous rechargez la page du rapport de bogue vous verrez que les étiquettes ont été déjà modifiées. N'y-a-t-il rien d'autre qui a changé ? Bien sûr, quelque-chose a changé: si vous cliquez sur icedove-bidiui en haut pour consulter la page récapitulative des bogues de ce paquet et que vous cliquez sur la partie [G|u|☺] dans le résumé du bogue, vous constaterez que le bogue peut être archivé dans 28 jours ! Hourra, nous venons de supprimer un bogue critique pour la publication de la version stable, ici et maintenant :)

Exemple 2

Jetons un coup d'oeil à ce bogue :

aperçu d'une page web du rapport de bogue #606327 avant le déroulement de ce tutoriel

En fait, ce bogue semble un peu étrange. Le courrier initial contient une en-tête Version mais il n'y a pas de graphe et aucune information de version dans le résumé situé en haut de la page. Lisons la suite et voyons ce qu'il arrive.

Juste après le courrier initial, vous pourrez remarquer deux extraits de Bug reassigned (Bogue réaffecté) et spécialement Bug no longer marked as found in versions (Bogue non trouvé dans les versions). Ahah! Le rapport a perdu son information de version suite à une réaffectation ! J'ai mentionné précédemment qu'une réaffectation utilise un argument supplémentaire qui indique une version. Malheureusement, il n'a pas été utilisé dans notre cas.

Aperçu du message "Bug Reassigned" dans la page web du rapport de bogue #606327

Vérifions. C'est encore plus drôle ! Le bogue a été réaffecté de open-vm-dkms à open-vm-tools. Ne sont-ils pas liés ? Si vous allez plus loin, vous remarquerez que l'un est le nom du paquet source tandis que l'autre correspond au binaire produit par ces sources. Ainsi, ils devraient avoir la même information de version, n'est-ce-pas ? Que faire maintenant ?

bts found 606327 2010.06.16-268169-3 '# re-add version information lost in reassign'

Nous devrons attendre un peu avant que la commande soit appliquée. Après quelques temps, si nous rechargeons la page, nous verrons un graphe apparaitre qui contiendra uniquement (testing, unstable). Ce bogue ne concerne donc plus stable. Deuxième bogue RC viré ! :)

Exemple 3

Voyons maintenant le prochain rapport de bogue.

aperçu d'une page web du rapport de bogue #605784

Ce graphe de bogue concerne une version unique. Ce paquet ne semble pas avoir été mis à jour depuis que Lenny a été publiée !

Ainsi, le BTS n'a aucune chance de distinguer juste par l'information de version si le bogue affecte stable ou non. Il a besoin encore de l'aide des étiquettes de publication. Lorsqu'on lit la première ligne du message du rapport (Ndt: après hello), on voit just after upgrade to squeeze (après la mise à jour dans squeeze), cela indique que le bogue n'affecte pas vraiment stable.

Donc, nous allons l'étiqueter avec + squeeze sid encore une fois. :)

Après un peu de temps, nous constatons que le graphe de version sur la page du bogue n'a pas du tout changé. C'est correct mais comme les étiquettes de publication sont indiquées, le bogue ne concerne plus stable. :) Troisième bogue RC viré !

Exemple 4

Maintenant, un problème plus corsé que les cas précédents.

Consultons ce rapport de bogue :

aperçu de la page web du rapport de bogue #507360

Ce bogue est marqué comme fermé depuis février (2010) ! Ce qui est largement plus long que 28 jours n'est-ce-pas ?

Nous trouvons une version listée et une version corrigée dans l'information en haut à gauche. Et nous avons un graphe presqu'entièrement rouge. Où est donc la boite verte ? Comme mentionné plus haut, vous pouvez cliquer sur le graphe. Cela ne donne pas beaucoup plus d'information pour le moment mais vous pouvez déplier le graphe en cliquant sur [Don't collapse].

screenshot of expanded version graph for bug #507360

Corrigé dans la version 2.28.0-1. Pourtant, même si je ne suis pas aveugle, je ne trouve nulle part de version 2.28.0-1 dans ce graphe et je pense que comme moi, vous pouvez le confirmer ! Que s'est-il donc passé ? Comme on peut le constater, le bogue n'a pas été fermé avec le versement d'un paquet mais à l'aide d'un simple courrier électronique.

Cela arrive souvent lorsque quelqu'un tatonne avec la version et cela semble être le cas ici. En effet, le PTS ne connait rien sur cette version dans l'historique du paquet : http://packages.qa.debian.org/g/gnome-media.html (Ntd: la version 2.28.0-1 n'existe pas !).

Nous avons juste à ajouter l'information de version. Nous conservons l'approche conservatrice et marquons le bogue comme corrigé dans la version 2.28.1-1 qui est la version versée juste après:

bts notfound 507360 2.28.0-1 '# fixing version information' . found 507360 2.28.1-1

Même problème avec le bogue 418597 où il faut chercher le bon numéro de version.

En fait, il semble qu'il y ait toujours encore des problèmes dans le paquet gnome-media donc j'ai envoyé un petit message à l'un des mainteneurs du paquet pour qu'il voie ça de plus près. :)

Il ne s'agit pas de bogues RC mais de bogues non fermés correctement à cause d'une erreur de suivi de version.

Exemple 5

Passons maintenant à d'autres problèmes: http://bugs.debian.org/src:logrotate. Ce paquet dispose d'un grand nombre de versions corrigées. Lorsqu'on clique sur les étiquettes des bogues pour avoir plus d'information, on se rend compte qu'ils sont clos depuis… des lustres ! Que-se-passe-t-il ?

Vérifions le bogue 388608. L'infobulle nous indique : Modified 1 year and 116 days ago (modifié il y a 1 an et 116 jours). Wow! Ça fait sacrément plus que 28 jours non ? ;)

Consultons le graphe du bogue.

Aperçu de la page web du graphe du bogue #388608

Je ne pense pas que ce graphe soit lisible en l'état, donc cliquez dessus. :) On y trouve en haut une boite verte (testing, unstable). Toutefois, il y a une autre unstable dans un cercle rouge un peut plus bas ! Que se passe-t-il ? deux versions unstable ?

Vérifions la page du paquet http://packages.debian.org/unstable/logrotate : si vous descendez en bas de la page, vous trouverez l'information de version. Ici également, il y a un codage couleur : vert signifie synchronisé, jaune indique une version de retard dans Debian et rouge indique un retard par rapport à la version originelle. Nous pouvons ignorer le jaune de m68k car cette architecture n'est pas un port officiel de Debian.

La version coupable est la hurd-i386, dans le numéro 3.7.1-5 et c'est également la version du cercle avec (stable, unstable) dans le graphe du bogue !

Aperçu de la page web du paquet logrotate avec les informations de version pour toutes les architectures

Que pouvons-nous faire ? Soit trouver quelqu'un pour construire le paquet sous Hurd, ou demander à l'un de nos sympathiques gestionnaires FTP de supprimer le paquet dans hurd-i386. On peut réaliser cette opération en créant un rapport de bogue pour le paquet ftp.debian.org. reportbug permet cela grâce à un système de menu pour ce pseudo-paquet (ftp.debian.org) en simplifiant fortement la demande, même pour la suppression partielle d'un paquet.

Je choisis en général RoQA (Request of Quality Assurance, Demande d'assurance qualité en français) car l'équipe QA, c'est tout le monde, y compris vous. Eh oui, ça comprend toutes les personnes qui s'occupent de Debian.

En fait, le paquet suivant a le même problème : http://bugs.debian.org/src:distcc. J'ai donc envoyé une demande de suppression pour hurd-i386 sur distcc un peu plus tôt et comme nous avons des gestionnaires ftp rapides, c'est déjà fait.

Si vous cliquez sur les informations de ces bogues, vous verrez qu'ils seront bientôt archivés. :)

UDD

Si vous vous demandez comment je suis tombé sur ces exemples, sachez que j'ai employé la UDD pour cela.

UDD signifie Ultimate Debian Database (Base de Données Ultime sur Debian) et qu'elle peut être interrogée avec n'importe quoi.

La première requête est la liste des bogues critiques pour la publication en cours de traitement (qui peut être également interrogée depuis http://udd.debian.org/bugs.cgi) en sélectionnant Lenny en haut. La deuxième est juste un résumé des rapports de bogues qui ont été fermés l'année dernière et qui ne sont pas encore archivés.

Questions et Réponses

QUESTION : Y-a-t-il une règle pour le titre des bogues ?

REPONSE : en général, non. Certains paquets (ou plutôt des pseudo-paquets) utilisent le titre du bogue pour lancer automatiquement des tâches et ils utilisent un formatage particulier. En général, les personnes qui s'en occupent sont au courant qu'il n'est pas facile d'avoir cette information et ils savent rester souples si vous ne respectez pas ces règles.

Un de ces paquets spéciaux (pseudo) est ftp.debian.org. Cette équipe a des règles spéciales pour les sujets et ils utilisent cette information pour savoir quoi faire juste en lisant le sujet au lieu de lire le message complet (qui contient juste quelques informations complémentaires).

QUESTION : Qui change l'étiquette Severity d'un rapport de bogue (et comment le faire ?) ?

REPONSE : Lisez la partie sur l'adresse de courrier électronique spéciale, control@bugs.debian.org

QUESTION : A quel point la "politique APT" est-elle importante pour un rapport de bogue ?

REPONSE : En fait, je ne suis pas sûr de savoir ce que vous entendez par "politique APT". Pouvez-vous expliciter ce terme que j'entends pour la première fois, particulièrement dans le contexte de la remontée de bogues ?

Peut-être est-ce la ligne "APT Policy" que reportbug ajoute généralement lorsqu'on crée un rapport de bogue sur un paquet (résumé de l'information d'apt-cache). Revenons à la sortie de reportbug --template :) Le rapport de bogue doit être placé entre le bloc comprenant Package, Version et Severity, et le bloc qui commence avec System Information.

Ce dernier aide le mainteneur à trouver les problèmes liés à des dépendances spéciales ou aux paramètres de debconf ou du noyau utilisé. Lorsque le rapport de bogue est très détaillé, il n'y a pas forcément besoin d'indiquer ces dépendances spéciales. Mais souvent, les gens soumettent des rapports de bogues avec peu d'information (en général, pas volontairement) et ces Informations Système peuvent donner une bonne idée de la cause du problème. J'espère que ces éléments apportent des réponses à vos question. :)

QUESTION : Dans la sortie de « reportbug --template nom_du_paquet », en dessous des informations système : APT policy: (500, 'stable').

REPONSE : Ah oui, ça me dit quelque-chose maintenant. C'est la valeur par défaut que les utilisateurs de stable renvoient. Ces personnes ont peut-être d'autres dépôts d'indiqués dans leur fichier sources.list et ils ont peut-être modifié les préférences de manière à ce que les paquets d'une version spécifique de Debian soit installés préférentiellement. Il s'agit d'une information interne à apt mais elle est utile (en plus de la version du paquet) pour comprendre dans quel environnement le bogue se produit.

QUESTION : Peut-on lancer toutes les commande de contrôle en utilisant les pseudos en-têtes dans un courrier électronique envoyé à l'adresse numéro_de_bug@b.d.o ou doit-on utiliser control@b.d.o ?

REPONSE : Vous devez nécessairement utiliser l'adresse explicite control@, la vérification automatique n'étant pas faite. De ce j'ai pu comprendre, ça a fonctionné dans le passé mais ce n'est pas très fiable.

QUESTION : 28 jours depuis la notification ou depuis la dernière édition ?

REPONSE : La réponse est dans la section Suivi de version.

QUESTION : Le bogue est marqué comme corrigé dans la version 0.7.3-3, qui est également la version stable. Pourquoi le BTS pense qu'il affecte encore stable ?

REPONSE : Bonne question ! :) En fait, je l'attendais ! ;) Lisez la ligne en dessous : il est également trouvé dans la même version. Étant donné qu'un bogue ne peut être trouvé et corrigé dans la même version, le BTS garde une approche conservative et supprime les deux éléments en considérant qu'ils n'existent pas.

QUESTION : Qu'en est-il des attaques contre le BTS , par exemple, celles qui sont ciblées sur la fermeture ou la réouverture arbitraire, etc... ?

REPONSE : Dans la pratique, certains spams parviennent à être envoyés aux adresses -done. Ils sont généralement faciles à repérer et comme on peut facilement revenir en arrière, ça ne pose pas de problème. En général, les mainteneurs de paquets les remarquent et réagissent ainsi que le font régulièrement les administrateurs du BTS.

Ces administrateurs ont également la possibilité de bloquer certains émetteurs du BTS en cas d'envoi malicieux délibéré.

Néanmoins, le fait d'être ouvert et d'inviter tout le monde à travailler sur les bogues surpasse complètement les quelques troubles qui viennent parfois perturber le robot de contrôle.

QUESTION : Le bogue n'aurait-il pas eu besoin d'être marqué comme fixed (corrigé) au lieu de notfound (non trouvé) (Ndt : cf exemple 1) ?

REPONSE : Merci de cette réflexion, vous avez raison bien entendu. Néanmoins, je ne vais pas renvoyer un autre message de contrôle car cela n'aura pas d'effet. La mauvaise correction ne fera rien donc je ne vais pas ennuyer un mainteneur de paquet. :)

Voir aussi


CategoryBugs | CategoryRedundant: merge with BTS (this is/was the transcript of a Debian Women Training Session; maybe consult with the Debian Women Team if they want to keep this info under the DebianWomen wiki infrastructure before deleting it).