From Mageia wiki
Jump to: navigation, search


Drakconf multiflag.png
 Autres langues
Deutsch ; English ; Français ;
Résumé :
Cette page est destinée à vous guider dans le triage des bogues signalés sur Mageia. Elle est principalement destinée aux personnes de l’équipe de recherche d’incidents et devrait servir de guide pour les nouveaux membres et d’aide-mémoire pour les membres expérimentés.

Contents

Ce qu’il reste à faire

  • Ajouter davantage d’informations au sujet de l’installation (quel paquet choisir).
  • Ajouter des informations sur les bogues de l’infrastructure et du site Web.
  • Et sur les demandes de retrait d’un paquet de cauldron.
  • Faciliter la compréhension des phrases, dans la mesure du possible.
  • Ajouter des lignes vides là où c’est nécessaire.

Avant toute chose, est-ce un doublon ?

La première chose à considérer est de savoir si le bogue est un doublon d’un rapport déjà ouvert. Vous pouvez simplement vous souvenir d’un travail précédent ou avoir vu un rapport de bogue similaire. Sinon, il est recommandé d’effectuer une exploration dans toute la base de données à l’aide de mots-clés liés au dysfonctionnement qui sont les plus susceptibles de renvoyer des bogues en double.

Lors de l’exploration dans bugzilla, il est recommandé d’utiliser l’interface de recherche avancée Advanced Search; Cela peut paraître un peu trop complexe au début jusqu’à ce que vous vous y habituiez, mais c’est un outil de prospection très puissant, où vous pouvez pister un dysfonctionnement logiciel à l’aide de la pile d’appel (backtraces), des mots ou des chaînes de caractères uniques concernant un rapport de bogue.

Tenir compte des relations entre les éléments lors de la recherche. Ainsi, si quelqu’un signale un plantage dans une application GNOME, considérez que le problème sous-jacent peut en fait se situer, par exemple, dans les bibliothèques GTK+ ou Pango. Rechercher dans ces champs.

Dans le cas où le bogue est un doublon qui a été résolu, n’oubliez pas d’inclure les bogues RESOLVED dans votre recherche.

Mettez « ALL » avant le mot-clé lorsque vous êtes sûr qu’une exploration rapide quick search est suffisante. Ainsi, si quelqu’un dépose un bogue contre dansguardian, la recherche

ALL dansguardian

affichera également les bogues déjà résolus.

Vous pouvez également obtenir la plupart des bogues signalés au cours des 7 derniers jours dans la page des doublons du bugzilla (ou depuis le début de la distribution si vous jouez un peu avec les paramètres).

Bien, c’est un doublon, et ensuite ?

Si le bogue est une copie d’un rapport précédent, vous devez lui attribuer le statut RESOLVED DUPLICATE avec le numéro de bogue approprié. Il s’agit généralement de la seule action requise. Si le fait que le bogue est un doublon peut ne pas être évident pour le contributeur sans autre explication – par exemple, le rapport concerne un plantage dans un certain programme, mais le problème se situe en fait dans une bibliothèque sous-jacente et a déjà été signalé précédemment – vous pouvez expliquer cela dans un commentaire pour vous assurer que le contributeur comprend la décision.

Le bogue affecte deux versions différentes ! Que faire maintenant ?

Les bogues identiques déposés sur des versions distinctes ne doivent pas être fermés en tant que doublons. Ainsi, si un bogue est signalé sur Cauldron et ensuite sur une version stable, ne fermez pas le deuxième rapport en tant que doublon du premier. La raison en est que la résolution d’un bogue dans une distribution n’implique pas la résolution du même bogue dans une autre distribution, donc sous le système actuel de Bugzilla, avoir des rapports séparés pour chaque distribution est la meilleure façon de gérer de telles situations. Vous devez également définir des blocages et cela dépend de votre ordinateur : un bogue dans cauldron bloque les bogues dans les autres versions de Mageia

Remarque :
Au lieu d’avoir des rapports de bogue séparés pour des versions séparées, nous avons commencé à mettre MGA5TOO dans le formulaire des rapports de bogue de cauldron qui sont également valides pour Mageia 5. Lorsque le bogue est corrigé dans cauldron, la version peut être réglée sur 5 et MGA5TOO peut être supprimé du formulaire.

Est-ce-que le problème est apte à être pris en charge par les développeurs de Mageia ?

Premièrement, réfléchissons à la définition d’un bogue

Dans le cadre de Gestion des bogues : Un bogue est défini comme un cas dans lequel un composant d’une distribution Mageia Linux (ou un autre produit couvert par Bugzilla, tel qu’un site web Mageia) ne remplit pas sa fonction prévue. Déterminez si l’incident déclaré est admissible en vertu de ces conditions.

Notez qu’il y a une exception pour les demandes d’évolution valides – voir la pratique sur la gestion des bogues pour plus de détails.

Un exemple d’un rapport qui échouerait au test est une demande de fonctionnalité supplémentaire dans un logiciel qui n’est pas maintenu par l’équipe de développement de Mageia ou un rapport qui est évidemment attribué non pas à un composant Mageia mais à une erreur de l’utilisateur ou à un problème matériel spécifique à la machine du contributeur.

Si un bogue échoue au test, le rapport de bogue devrait recevoir un commentaire expliquant pourquoi il ne se rapporte pas à un bogue Mageia et son statut devrait être modifié à RESOLVED INVALID.

Il en va de même lorsque le logiciel défaillant n’est pas un paquet Mageia officiel. Ce n’est pas toujours évident, n’importe qui peut construire un paquet qui ressemble à un paquet Mageia, mais qui n’a pas été construit sur nos serveurs et certainement pas signé par nous.

Ceci peut être vérifié en mettant un espace et le nom du paquet après la commande suivante :

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n'

comme c’est fait ci-dessous pour translate-shell :

[m@c ~]$ rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n' translate-shell translate-shell-0.9.6.11-1.mga8 RSA/SHA256, zo 28 jul 2019 11:53:22 CEST, Key ID b742fa8b80420f66 [m@c ~]$

Si la commande renvoie « Key ID b742fa8b80420f66 », comme dans l’exemple ci-dessus, alors c’est bon : ce paquet, sur le même ordinateur, était signé par Mageia.

Surtout lorsqu’un bogue ne peut pas être confirmé, c’est une bonne idée de demander au déclarant de vérifier les paquets tiers installés. L’obtention d’une liste des paquets installés, qui n’ont pas été signés par les membres de Mageia, peut se faire avec (commande complète sur une seule ligne) :

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n' | grep -v b742fa8b80420f66

Parfois, un rapport de bogue est un problème de support plutôt qu’un véritable bogue, ou alors, le déclarant est incapable de décrire le bogue et de fournir toutes les informations nécessaires. Dans ces situations, il est sage de suggérer au déclarant de demander de l’aide depuis le forum en français ou le forum en anglais ou sur discuss@ml.mageia.org. Il est souvent préférable de laisser de tels rapports ouverts pendant un certain temps et de les fermer (en tant que RESOLVED-OLD) lorsque, quelques semaines plus tard, aucune information complémentaire confirme qu’il s’agit d’un véritable bogue, ou lorsque le rapport continue à manquer d’informations nécessaires. Officiellement, ces signalements devraient obtenir le statut RESOLVED-INVALID, mais cela peut provoquer un profond sentiment de gêne pour certains utilisateurs inexpérimentés.

Deuxièmement, est-ce que le bogue devrait être pris en charge ailleurs ?

(Le plus souvent par les développeurs du logiciel en question.) Par exemple, un bogue causé par une faille fondamentale dans le code source du logiciel devrait être résolu en amont par l’équipe de développement, même s’il pourrait théoriquement être corrigé par un développeur Mageia avec un correctif. La résolution de ces problèmes en amont réduit le fardeau de la maintenance des correctifs sur l’équipe de développement de Mageia (et le risque d’erreur et d’instabilité qui y est associé).

Si une pile d’exécution est fournie dans le rapport de bogue, pensez à rechercher dans le système de gestion des bogues en amont (par exemple, dans le Bugzilla GNOME ou KDE) pour voir si un bogue avec une pile d’exécution similaire a déjà été signalé.

Dans le cas où le problème réside dans le logiciel lui-même, c’est-à-dire en amont, définissez le mot clé UPSTREAM

Lorsque le code est peu ou prou maintenu en amont, vous pouvez le considérer comme pertinent pour le processus Mageia, car il y a une plus grande probabilité que l’équipe de développement de Mageia soit capable de le résoudre que celle des responsables inactifs en amont.

Si l’équipe de développement en amont maintient bien le logiciel, vous devriez poster un commentaire expliquant votre raisonnement et demandant que le rapporteur du bogue envoie un rapport à l’endroit adéquat (selon le paquet, il peut s’agir d’un autre système de suivi des bogues, d’un forum ou d’une liste de diffusion). Idéalement, incluez un lien dans votre commentaire vers l’endroit adapté, pour la commodité du contributeur. Demandez au contributeur de laisser un commentaire une fois qu’il a fait son rapport en amont, avec un lien vers le rapport. Une fois que le déclarant l’a fait, vous devez ajouter le lien vers le rapport en amont dans le champ URL, avant de l’assigner au responsable. Une fois le bogue corrigé par l’équipe de développement en amont, le correctif peut ensuite être incorporé avec une mise à jour du paquet Mageia. Bien sûr, notre développeur est libre de patcher le paquet avant que le correctif soit livré en amont.

Troisièmement, est-ce que le bogue est déposé sur une version prise en charge ?

Si la version de Mageia sur laquelle le bogue est classé n’est plus supporté, ajoutez le mot-clé NEEDINFO et demandez au contributeur de tester si elle est toujours valide avec la version cauldron ou tout autre version encore supportée. Contactez-le s’il ne répond pas dans les deux semaines. S’il ne répond pas dans un délai de deux semaines, vous pouvez définir le bogue RESOLVED OLD avec un commentaire expliquant la raison. Ceci ne s’applique pas aux demandes d’amélioration, car la plupart d’entre elles doivent être appliquées à la version Cauldron (modifiez le cas échéant le champ version).

Est-ce que toutes les informations nécessaires sont présentes ?

Si le dysfonctionnement passe les tests précédents, il s’agit d’un problème nécessitant une intervention de la part du mainteneur, et devrait éventuellement être assigné au mainteneur pour action. Toutefois, vous ne devriez pas le faire avant que l’information fournie sur la question soit aussi complète que possible.

La règle générale est qu’un rapport de bogue doit contenir au moins assez d’informations pour rendre le problème plus simple à reproduire et à comprendre pour le mainteneur. L’information utile comprend, sans toutefois s’y limiter :

  • Version exacte du ou des paquets utilisés
  • Architecture (i586 ou x86-64)
  • Étapes précises pour reproduire le défaut (gedit plante est mauvais. « gedit plante quand je le lance depuis le menu, tapez 'votre commentaire…' et cliquez sur Imprimer » est bon).
  • Messages d’erreur affichés par l’application ou sur une console lorsque l’application est exécutée depuis cette dernière.
  • Informations matérielles lorsque cela peut être un élément important – disques durs IDE / SCSI / SATA, périphériques de stockage USB, lsusb, lspci,'lspcidrake -v'…etc sortie…
  • Informations sur le système d’exploitation : quel bureau / shell utilisé, l’application en cours d’exécution à distance, quels autres paquets utilisés peuvent affecter le fonctionnement de l’application employé, quels paramètres de configuration ont été modifiés, etc.

Une très bonne méthode pour vérifier si tous les renseignements nécessaires ont été apportés est de voir si vous pouvez reproduire le problème vous-même en utilisant les informations fournies dans le rapport de bogue. Il est conseillé aux membres de l’équipe de triage de bogues de conserver des copies de toutes les versions de Mageia actuellement prises en charge. Vous pouvez envisager d’utiliser VirtualBox, VMware, qemu… etc à cette fin.

Si des informations ne sont pas encore fournies, vous devez ajouter le mot-clé NEEDINFO au bogue et ajouter un commentaire expliquant au contributeur quels renseignements supplémentaires sont requises et – si cela est nécessaire – comment les obtenir. Contactez-le s’il ne répond pas dans les deux semaines. S’il ne répond toujours pas dans un délai de deux semaines, vous pouvez le régler sur RESOLVED INVALID avec un commentaire expliquant la raison et, idéalement, inviter le contributeur à rouvrir le rapport de bogue lorsqu’il fournit les informations souhaitées.

Cas particuliers d’informations spécifiques indispensable

Voici quelques types de bogues spécifiques pour lesquels certains types d’informations seront toujours nécessaires :

Bogues liés au programme d’installation.

Programme d’installation traditionnel.

Pour les bogues liés à l’installateur traditionnel (ne pas installer à partir d’un Live CD / DVD), le contributeur doit fournir le fichier /root/drakx/report.bug.xz en pièce jointe. Une façon simple de le faire est de demander au contributeur de passer à la console 2 (en appuyant sur la touche Ctrl-Alt-F2) pendant l’installation après l’apparition du bogue, de brancher une clé USB et de saisir bug puis d’appuyer sur la touche Entrée. Il mettra un fichier report.bug sur la clé USB. Si le fichier est trop volumineux pour être attaché, veuillez le compresser avec xz : xz report.bug et attacher le report.bug.xz généré.

Si la commande bug ne fonctionne pas, réessayez par exemple (Si votre clé USB est sur /dev/sdb) : bug /dev/sdb1. Si nécessaire, adapter la commande. Vous pouvez trouver, en exécutant d’abord, la commande dmesg si votre clé USB est sur "/dev/sdb", "/dev/sdc" or "/dev/sdd", etc. Les bogues d’installation traditionnels sont assignés aux mainteneurs des outils Mageia.

Remarque :
Au moment où ceci est écrit (autour de la version 4 beta2), pour les mises à niveau traditionnelles de l’outil d’installation, le /root/drakx/report.bug.xz est celui de l’installation originale, pas celui de la mise à jour. Toutefois, /root/drakx/report.bug est en cours de mise à jour. Si cela est toujours comme ça quand vous lisez ceci, alors, bien sûr, le dernier fichier doit être compressé et en pièce jointe.

Installation en mode autonome.

Après avoir démarré depuis un DVD ou une clé USB autonome en tant que root, pour les problèmes (bogues) liés à l’installation journalctl -a > journalctl-a.txt avant de redémarrer après l’installation et de joindre le journalctl-a.txt au rapport de bogue. Si le fichier est très volumineux (c’est probablement le cas), d’abord le compresser.

Problèmes de détection du matériel, matériel non pris en charge.

Si un matériel est incorrectement détecté ou ne semble pas être du tout prise en charge, la sortie de la commande lspcidrake -v est requise. Pour les périphériques USB, demandez au contributeur d’installer usbutils et d’utiliser ensuite lsusb.

Si le périphérique n’est pas du tout pris en charge, il serait également utile de savoir si le contributeur est au courant de l’existence d’un pilote qui pourrait prendre en charge le périphérique. Si vous rencontrez des problèmes avec du matériel que vous branchez et qui ne fonctionne pas correctement ou qui n’est pas reconnu convenablement, voir pas du tout, les informations nécessaires peuvent être affichées via la procédure suivante :

Ouvrez un terminal, en tant que root, exécutez la commande suivante tee output.txt Et laisser le contributeur joindre le fichier output.txt. Ceci s’applique au périphérique qui est connecté à l’ordinateur lorsqu’il est déjà en cours d’exécution. Si plus de vingt lignes sont requises, alors faites ce qui suit. journalctl -f 2>&1 en premier et laissez-le fonctionner jusqu’à ce que l’appareil soit branché.

Lent pendant le démarrage.

Demander boot.svg qui est le résultat de l’exécution de systemd-analyze plot > boot.svg dans un terminal ou une console
et aussi journal.txt qui est le résultat de l’exécution, en tant que root de journalctl -ab > journal.txt.

Le serveur X ne démarre pas.

Il n’est pas rare que le serveur X plante au démarrage, dans ce cas, il faut demander au contributeur de joindre /var/log/Xorg.0.log (le copier avant de redémarrer X, ou /var/log/Xorg.0.log.old après reconfiguration et redémarrage de X) au rapport de bogue.

Si vous n’avez pas de logs Xorg, essayez (en tant que root) : journalctl -b -e /bin/Xorg
voir (archive disparue)


Le système ne démarre pas à cause d’un menu.lst erroné.

Vous devez demander au contributeur de joindre le fichier /boot/grub/menu.lst file et un menu.lst propre si possible. En outre, pour en savoir plus sur la table de partition, le contributeur doit fournir le résultat defdisk -l /dev/sd[a-z]

Problèmes d’imprimante

Découverte

Si vous rencontrez des problèmes avec du matériel que vous branchez et qui ne fonctionne pas correctement ou qui n’est pas reconnu convenablement voir pas du tout, les informations nécessaires peuvent être affichées via la procédure suivante :

journalctl -f 2>&1

Pendant quelques minutes après l’avoir branché. Ensuite, arrêtez la commande avec « Ctrl »+« C » et attachez le fichier output.txt au rapport de bogue. Ceci s’applique à tout le matériel qui est connecté à l’ordinateur lorsqu’il est déjà en cours d’exécution.

De plus, demandez toujours comment l’imprimante est connectée au PC, par exemple via USB, port parallèle, une sorte de convertisseur USB-parallèle ou même n’importe quoi d’autre (directement connecté via Ethernet ou sans fil, dans un réseau via un serveur d’impression…).

Peut-être aussi que le service de triage devrait regarder en amont dans quelle mesure l’imprimante est supportée et, le cas échéant, quel pilote tâcherait d’être utilisé :

  • Pour toutes les imprimantes HP (à l’exception de certaines imprimantes GDI)

à l’adresse suivante

Toutes les autres problématiques

Demander la sortie de rpm -qa cups et de systemctl status cups.service cups.socket -al -n50 et pour la connexion de

  • /etc/cups/printers.conf
  • /var/log/cups/error_log

Également à l’adresse suivante, par ex : http://fedoraproject.org/wiki/How_to_debug_printing_problems#Printing_troubleshooter pour activer la journalisation de débogage cups et / ou rassembler des logs de cups via journalctl.

Problèmes du scanner

La sortie suivante doit être fournie en plus des sorties générales : sane-find-scanner et scanimage -L Les deux doivent être exécutés en tant que root pour trouver tous les scanners connectés (comme pour certains périphériques/pilotes, sans changer les règles udev ou ajouter l’utilisateur normal à certains groupes système comme lpadmin pour lui donner les permissions correctes d’utiliser le scanner comme utilisateur standard, le scanner ne montrera rien quand ces commandes sont exécutées par un utilisateur standard).

Bogues en rapport avec initrd

Les bogues liés à initrd peuvent facilement être confondus avec les bogues du noyau, alors examinez attentivement le rapport pour les identifier correctement. Si un bogue est lié à initrd, le paquet doit être défini pour dracut Page de Fedora au sujet de dracut.

Problèmes de son

Cliquez sur le lien et lisez les suggestions de Colin sur la marche à suivre pour corriger les problèmes de son. debug sound problems

Les problèmes de mise en réseau

Ils peuvent être dus à des pilotes ou des problèmes de configuration, vous devriez donc faire appel au fichier

  • journalctl.txt qui découle, en tant que root, de l’exécution de : journalctl -b > journalctl.txt
  • et du fichier dmesg.txt qui résulte de l’exécution de dmesg > /tmp/dmesg.txt qui pourrait montrer des problèmes avec les modules du noyau impliqués.
  • ip route show affiche le contenu des tables de routage du noyau.
  • lspcidrake -v cela va de soi, devrait aussi être demandé.

dans le cas d’un problème de connexion sans fil, la sortie des 3 commandes suivantes est exigée en tant que root :

  • iwconfig
  • iwlist scan
  • iw dev wlp5s0 scan (changer « wlp5s0 » avec l’identifiant de la carte listé par iwconfig)

Note pour les testeurs : le support général de linux pour les périphériques sans fil peut être consulté à l’adresse http://linuxwireless.org/ ou à http://linux-wless.passys.nl/index.php?lang=english

De plus, si un pilote est supporté par ndiswrapper, vous devrez entrer la commande

  • ndiswrapper -l output,

et avec les cartes pcmcia utiliser la commande

  • lspcmcia

Problème en lien avec la mise en veille prolongée

Demandez toujours la sortie dmesg après le redémarrage si possible. Comme indiqué ci-dessus, demandez à joindre le fichier dmesg.txt qui résulte de la première exécution, dmesg > /tmp/dmesg.txt nous avons besoin de savoir si c’est provoqué par X ou non, pour cela, veuillez demander à l’utilisateur de désactiver X.

service dm stop Connectez-vous en tant que root et exécutez la commande {{code-fr|pm-{suspend,hibernate}}} Si cela fonctionne, cela pourrait être un problème dû à X, alors, demandez à la personne les fichiers /var/log/Xorg.0.log, /etc/X11/xorg.conf et la sortie de la commande lspcidrake -v. Si elle échoue toujours, demandez au contributeur d’essayer de suspendre ou d’interdire la mise en veille prolongée en cours d’exécution. echo mem

Liens pertinents

Wiki Arch Linux en anglais

Bloc note : En anglais

Problèmes lié au logiciel de démarrage (Plymouth)

  • On peut désactiver Plymouth en ajoutant facilement le code suivant
init=/sbin/init/

au noyau via la ligne de commande.

  • Démarrez en mode verbeux, supprimez les arguments « splash=silent » ou « splash » et « quiet » s’ils apparaissent.

Problème lié à samba

En règle générale, le contenu de /var/log/samba est utile pour essayer de résoudre les problèmes de samba, il est donc recommandé de demander à l’utilisateur de joindre son contenu au rapport de bogue.

Plantages

Habituellement, le contributeur aura besoin d’installer des paquets de débogage supplémentaires pour obtenir des traces de plantage pertinentes. Il devrait d’abord lire les instructions de dépannage du logiciel de débogage Comment corriger les plantages de logiciels sur la manière d’obtenir une trace de plantage efficace.

Plantage des outils Drakx

Pour les plantages de Drakxtools, vous devez demander à l’utilisateur de suivre ces étapes (posté par Thierry Vignaud dans un précédent rapport de bogue, puis mis à jour par l’équipe de triage de bogue) :

  • Assurez-vous que gdb soit installé.
  • Installer les paquets glib2.0-debug, glibc-debug, gtk+2.0-debug, perl-Gtk2-debug & perl-debug à partir des médias « Core Release Debug » et « Core Updates Debug ». Par défaut, ils ne sont pas activés et l’utilisateur devra donc le faire avant :
    • Démarrer en tant que root drakrpm-edit-media puis activer « Core Release Debug » et « Core Updates Debug » excepté si vous utilisez cauldron : alors seulement « Core Release Debug » est nécessaire.
    • Cela peut également être fait en ligne de commande : urpmi.update --no-ignore -v « Core Release Debug »; urpmi.update --no-ignore -v « Core Updates Debug » et les mettre à jour urpmi.update « Core Release Debug » ; urpmi.update « Core Updates Debug »
    • Puis installer les paquetages de débogage : urpmi glib2.0-debug glibc-debug gtk+2.0-debug perl-Gtk2-debug perl-debug
  • Exécuter la commande suivante dans un terminal : gdb -q --args perl /usr/bin/<application name>
  • Puis saisir run et valider par la touche entrée
  • Quand l’application plante, saisir bt et valider par la touche entrée
  • joindre la trace d’appels (stack trace) ainsi obtenue au rapport de bogue

Perl – Problème lié à CPAN

Si vous tentez de mettre à jour les modules cpan en utilisant « cpan », le bogue devrait être fermé comme étant INVALID parce que ce n’est pas la méthode officielle, puisque nous fournissons les modules cpan sous forme de paquets dans les dépôts officiels ; pour plus d’informations, lisez-le commentaire de Jérôme Quelin dans ce rapport de bogue.

Renseigner les champs produit, ordre de priorité, degré de gravité, et différents composants

En tant que membre de l’équipe de triage, vous avez la mission de déterminer le produit, la priorité, la gravité et les caractéristiques des composants de façon appropriée.

Le produit est simplement la gamme de produits dans laquelle se trouve un bogue. Pour la majorité des bogues, ce sera Mageia. Les options sont généralement explicites.

Ordre de priorité

  • La priorité de blocage de publication release_blocker n’est pertinente que pour les bogues déposés sur les versions Cauldron ou bêta, et ne devrait être utilisée que pour les problèmes suffisamment critiques pour nuire gravement à la qualité globale d’une version si elle était mise à disposition sans que le problème soit résolu.
  • La priorité élevée high devrait être utilisée pour les problèmes qui sont suffisamment critiques pour que leur résolution prenne le pas sur la résolution d’autres problèmes, mais qui ne répondent pas aux critères de blocage de publication release_blocker
  • La faible priorité low devrait être utilisée pour les bogues qui sont suffisamment triviaux et/ou dont l’impact est suffisamment limité pour que la résolution d’autres problèmes soit prioritaire.
  • La priorité normale normal devrait être utilisée pour toutes les autres cas.

Essayez de faire en sorte que les bogues non triés encore assignés à l’équipe de triage de bogue ne soient pas définis en blocage de publication release_blocker, sauf lorsqu’ils sont vraiment graves.

Degrés de gravité

  • La gravité critique critical devrait être utilisée pour les bogues qui rendent un paquet essentiellement inutilisable (par exemple, les plantages qui affecteraient la majorité des utilisations d’un paquet, ou l’incapacité totale d’installer ou d’exécuter le paquet).
  • La gravité majeure major doit être utilisée pour les problèmes qui rendent une caractéristique importante du paquet inutilisable, ou qui rendent le paquet généralement instable.
  • La gravité mineure minor devrait être utilisée pour les problèmes qui n’ont qu’un impact limité sur la facilité d’utilisation d’un paquet ou qui n’affecteront qu’une petite minorité d’utilisateurs ou de cas d’utilisation.
  • La gravité normale normal devrait être utilisée pour tous les autres cas.
  • L’importance de l’évolution enhancement, voir ci-dessous pour plus de détails.

Vous devez également renseigner le champ RPM Package lorsque ce champ n’a pas été rempli par le contributeur, et si vous savez sur quoi il doit être réglé. Ce champ peut être modifié à droite de la page de bogue.

Pour les composants

  • Backports: Demandes de rétroportage de paquets (nouvelle version) sur les versions stables.
  • Installer: Les rapports de bogues concernant l’installation traditionnelle de Mageia avec drakx (le programme d’installation utilisé sur le DVD et le Dual ISO's). Pour les bogues du programme d’installation avec le LiveCD, utilisez-le paquet RPM et ajoutez draklive-installer dans le champ installer.
  • Nouvelle demande de paquet RPM New RPM package request: Bogues pour tous les logiciels souhaités (autorisés à inclure dans la distribution), un rapport par logiciel, pour garder la liste des bogues claire, aidez l’empaqueteur et l’équipe d’assurance qualité QA.
  • RPM package: Bugs concernant tous les RPMs Mageia (dépôt officiel, nous ne supportons pas les RPMs tiers)
  • Publication (média ou procédé) : Bugs liés à des problèmes avec les médias fournis pour installer Mageia (miroirs, CD, DVD…)
(inclure les bogues grub/gfxboot/syslinux bugs dans l’isos elle-même)
  • Security: Question de sécurité (CVE) dans les RPMs Mageia.

Valider le dysfonctionnement et s’assurer qu’il est correctement attribué.

Si le bogue est parvenu jusqu’ici, vous pouvez maintenant l’accepter et ajouter le mot-clé Triaged. Vous pouvez aussi poster un commentaire dans le rapport de bogue, par exemple Affecter au mainteneur « Assigning to the maintainer ».

Il est important de vérifier que le rapport de bogue soit assigné au bon responsable.

Si vous pensez qu’il peut être erroné, vérifiez les dernières entrées du journal des modifications pour le paquet. Si vous n’êtes pas sûr à qui le bogue devrait être assigné, faites une meilleure supposition, en favorisant les responsables qui sont prompts à répondre aux questions de Bugzilla.

En savoir plus sur les gestionnaires de paquets 
  • La base de donnée responsable Mageia, modifiez les rpm que vous désirez rechercher (nous avons aussi une page texte des mainteneurs ou une liste deux auteurs pour chaque paquet)
    • Dans ce cas, vous devrez interroger en utilisant le nom de SRPM (source RPM), vous pouvez le découvrir en utilisant ces commandes :
      • En supposant que vous avez ce paquet installé sur votre système : rpm -q --qf '%{SOURCERPM}\n' <nom-du-paquet>
      • Si le paquet n’est pas installé, vous pouvez utiliser urpmq, qui interrogera la base de données urpmi et devrait fonctionner indépendamment du fait que le paquet soit installé ou non (utiliser rpm directement lorsque le paquet est déjà installé sur votre système vous permet d’économiser du temps (et la bande passante) pour télécharger les fichiers de synthèse urpmi à partir des dépôts en ligne : urpmq --sourcerpm <package-name>
  • Un site qui contribue et qui utilise la même api que le script greasemonkey.

Il vous montre la liste des auteurs quand il n’y a pas de mainteneur. Il fonctionne aussi bien pour les RPMs que pour les SRPMs.

  • Sophie
    • Vous pouvez utiliser l’interface web Sophie afin de trouver toutes les informations relatives aux paquets rpm, y compris le développeur d’un paquet.
    • Si vous êtes familier avec l’utilisation d'IRC vous pouvez interroger le robot Sophie directement, consulter notre page Sophie pour plus d’informations sur la manière d’utiliser le robot sur IRC. L’utilisation du robot Sophie sur IRC est le moyen le plus rapide d’obtenir des informations sur n’importe quel paquet, donc ce peut être une bonne idée d’apprendre à l’utiliser.
  • Sur certains canaux IRC, vous pouvez aussi trouver mbot, en utilisant, « maint <package> » retournera les mêmes informations que le site contrib.

Suivi des bogues

Lorsqu’un même paquet fait l’objet de plusieurs comptes rendus de bogue, il devient plus facile de suivre tous ces rapports dans un seul. Ceci peut être fait en ouvrant un rapport de bogue et en le rendant dépendant « Dépend » en mettant <les numéros de tous les rapports de bogue ouverts> dans le champ « Depends on » dans Bugzilla. De cette façon, lorsque l’état de l’un de ces rapports est modifié, le rapport de bogue du pisteur est également modifié, ce qui permet d’avoir une vue d’ensemble des bogues d’un même paquet (idéalement, cela se produit pour les paquets core/important).


Comment créer un pisteur TRACKER ?

  • Ajouter [TRACKER] dans le summary et dans les mots-clés.
  • dans le pisteur :
    • un suivi des bogues pour la bonne exécution de l’implémentation
    • un bogue pour faire le suivi du bogue dans l’implémentation.
  • N’ajoutez pas de demande d’amélioration dans un bogue de type blocker.
  • Ne mélangez pas des bogues techniques avec des bogues physiques (thème artwork/oxygène).

Liste des bogues TRACKER

Demandes d’évolution

Les demandes d’amélioration valables sont des demandes de conditionnement d’un produit, ou des demandes d’amélioration du code des applications maintenues par l’équipe de développement de Mageia. Pour traiter les demandes d’extension, vérifiez si le rapport est un doublon, puis vérifiez si la demande est compréhensible telle quelle. Si ce n’est pas le cas, réglez le rapport sur NEEDINFO et demandez au contributeur de vous donner des précisions. Une fois que le rapport est suffisamment compréhensible, définissez la gravité sur amélioration enhancement et la priorité sur normal et assignez le bogue au responsable du paquet.

D’autre part, s’il s’agit d’une demande d’amélioration à faire directement en amont, vous devez fermer le bogue comme INVALID' et demander à l’utilisateur de leur faire directement un compte-rendu.

La plupart des requêtes ne seront résolues qu’en cauldron pour les prochaines versions de Mageia (comme les requêtes liées au programme d’installation), alors vous devez essayer de mettre la version à cauldron la majeure partie du temps, sauf les bogues demandant, par exemple, un paquet backport.

Nouvelles demandes de paquetages

  • Vérifier que les demandes de paquets sont conformes. déposer une demande de paquets ?
  • Vérifiez que le logiciel est un logiciel libre que nous pouvons ajouter à la distribution.
  • Si vous le souhaitez, ajoutez des empaqueteurs ou des groupes d’empaqueteurs qui pourraient être intéressés en CC; par exemple, le groupe de maintenance de KDE pour une application KDE, ou un empaqueteur qui aime les jeux pour un nouveau paquet de jeu.
  • Assigner collectivement à tous les empaqueteurs (c’est la convention) : pkg-bugs@ml.mageia.org, avec le commentaire suivant :
Assigning this package request to all packagers collectively. On a voluntary basis, one of them might, if there are no license or other legal issues, want to integrate it to the distribution and maintain it for bug and security fixes. You might also want to join the packager team to maintain this piece of software :

voir Devenir un empaqueteur de Mageia

Tableau blanc (Whiteboard)

  • FOR_ERRATA7 : doit être ajouté à la page erratas de Mageia 7.
  • IN_ERRATA7 : a été ajouté à la page erratas de Mageia 7.
  • FOR_RELNOTES7 : doit être ajouté à la page Mageia 7 Notes de version.
  • IN_RELNOTES7 : a été ajouté à la page Mageia 7 Notes de version.
  • FOR_ERRATA6 : doit être ajouté à la page erratas de Mageia 6.
  • IN_ERRATA6 : a été ajouté à la page des erratas de Mageia 6.
  • check : pour la fermeture d’un bogue
  • cauldron : pour les demandes de paquets, quand le paquet existe déjà dans cauldron – également lorsque la version cauldron d’un paquet est demandée pour être rétroportée pour stable.
  • MGA5TOO, MGA6TOO : (pour les bogues qui sont déposés contre cauldron, mais qui existent aussi dans Mageia 5, 6)
  • Seulement dans : MGA5 ou seulement dans : MGA5,MGA6 : Les rapports de bogue qui ne sont valides que pour une (des) version(s) stable(s) donnée(s) mais qui ne sont ni corrigés ni pertinents dans cauldron. Cette information nous aide lorsque la fin de vie End Of Life est atteinte, à savoir que nous pouvons fermer ces bogues sans les affecter à une version supérieure.
    • (MGA5) : Pour les bogues d’installation, pour montrer qu’ils étaient toujours valables pour la version finale de Mageia 5.
  • 6<Étape du développement> : peut-être que cela aidera à garder les informations à jour, à demander à d’autres personnes de confirmer ou d’invalider les bogues, à avoir une liste des « nouveaux » bogues depuis la sixième version et pourquoi aucune autre application n’a été trouvée ?
  • OK : Pour que le bénéficiaire le mette sur le formulaire lorsqu’il accepte la mission, mais ne peut pas définir un statut déjà attribué à ASSIGNED.
  • start7 :pour les bogues *drak* qui ont un correctif disponible : s’appliquent et risquent de tout casser juste après la sortie de Mga6, lorsque Mga7 cauldron est entamé.

Les astuces du formulaire de l’équipe d’Assurance Qualité

Voir la Liste des mots-clés du formulaire utilisés par l’équipe d’assurance qualité.

Remarques importantes

Besoin de débattre

Que faut-il faire avec :

  • Si des correctifs sont disponibles, comment allons-nous faire en sorte que les empaqueteurs corrigent les bogues dans les paquets non maintenus ?

Traqueurs de bogues fréquents en amont

Retour vers le portail de la Brigade anti-bogues

Retrieved from "https://wiki.mageia.org/mw-en/index.php?title=Guide_de_triage_de_bogues-fr&oldid=56675"