Rapporter des bugs à propos de Firefox OS

Cet article est un guide pour aider à rapporter des bugs à propos du projet Firefox OS, incluant Gaia et B2G.

Bugzilla

Comme pour la plupart des projets Mozilla, nous utilisons Bugzilla pour le suivi des bugs et des problèmes. Vous pouvez remplir un bug sur Bugzilla quand vous en trouvez un — nous avons un produit distinct pour Firefox OS, qui contient les composants pour tout ce qui concerne Gaia, Gonk et Gecko. Utilisez ce composant pour remplir les bugs concernant Firefox OS, Gaia, etc.

Note : La page B2G QA Wiki (ressource anglophone) contient également quelques ressources utiles pour la gestion des bugs Firefox OS ; les pages les plus utiles sont Bugzilla Usage (EN) et Incoming bug triage for Firefox OS (EN).

Remplir des bugs

Pour remplir un bug valide, vous pouvez suivre les recommandations pour l'écriture d'un bug (voir aussi Rapporter un bug sur le blog technique mozfr).
Vous pouvez également utiliser ce modèle sur Bugzilla et vous référer aux instructions ci-dessous pour compléter le bug.

Champs obligatoires et optionnels

Quand vous remplissez un nouveau bug, certains champs sont obligatoires :

Champ	Description
Component	Choisissez la catégorie à laquelle le bug devrait être rattaché. Si vous n'avez aucune idée de la catégorie dans laquelle devrait se trouver le problème, vous pouvez mettre "General".
Summary	Indiquez une brève description du bug.
Description	Décrivez clairement la situation. Un bon bug doit contenir les étapes de reproduction (STR — Steps to reproduce), le résultat attendu (Expected Result), et le résultat actuel (Actual Result). Mentionnez également la fréquence de reproduction (Reproduction Frequency), c'est-à-dire le nombre de fois que le bug se manifeste si vous répétez les étapes indéfiniment.
Build Information	Rendez vous dans Paramètres > Informations > Plus d'informations et rajouter les informations suivantes au bug: Version du système, Numéro de compilation, Version de la plate-forme, Identifiant de version, Canal de mise à jour et Informations Git. (Si vous êtes sur un ordinateur de type Mac/Linux, avec adb et git installés, vous pouvez lancer ce script et coller la sortie écran du script dans le bug.)
Screenshots	Veuillez attacher une capture d'écran qui pourra aider à analyser le bug. (Sur le téléphone de développement Flame, maintenir appuyés les boutons d'Allumage et de Volume bas simultanément à peu près 2 secondes jusqu’à ce que le téléphone affiche une notification de capture d'écran. Ensuite transférez l'image sur votre ordinateur en utilisant l'USB.)
Video	Si votre bug contient des changements à l'écran, difficilement captables via une capture d'écran, veuillez filmer une vidéo. Vous pouvez transférer le fichier en attachement du bug. Vous pouvez aussi transférer la vidéo sur YouTube et copier/coller le lien dans le bug.
ADB logs	Si adb est installé sur votre ordinateur, veuillez le connecter au téléphone et lancer la commande : adb logcat Veuillez joindre la sortie d'écran de cette commande dans un fichier de type texte et le joindre au bug.

Les champs suivants sont optionnels :

Champ	Description
Depends/Block	Montre la dépendance entre les bugs.
Keywords	Mots-clés pour bugzilla. Les groupes spécifiques vont l'utiliser pour le suivi.
Whiteboard	Contient les tags. Ajoutez n'importe quel tag pour le suivi. Vous ne devriez pas supprimer les tags dans autres sans autorisation.
See Also	De temps en temps, deux problèmes sont liés et vous pouvez le spécifier ici.
Flags	Flags pour tracker les statuts ; le flag le plus utilisé dans les bugs Firefox OS est blocking-b2g. Si un bug est flaggé en tant que "blocking-b2g", cela signifie que nous devrions y consacrer plus d'attention car celui-ci menace de bloquer la sortie.
Security	Si un bug est relatif à la sécurité des données personnelles, à des pertes de profits et d'autres problèmes de ce genre, vous devriez cocher la case. Ainsi, cela ne sera visible que par les employés concernés.

Pour trouver plus d'informations sur les champs de bugzilla, vous pouvez regarder la page Bugzilla Fields (EN) sur Bugzilla.

Ouvrir des bugs de traduction

Lorsque vous rencontrez une phrase non traduite, cela peut vouloir dire deux choses :

Le traducteur n'a pas traduit la phrase. N'ouvrez pas de bug dans ce cas !
Le traducteur ne peut pas traduire la phrase suite à un problème de traduction automatique (l12y). Veuillez ouvrir un bug dans ce cas.

Comment déterminer les bugs de traduction automatique (l12y)

Dans Firefox OS, allez dans Paramètres > Informations > Plus d'informations et activez le Menu développeurs.
Allez dans Paramètres > Développeurs et cochez Pseudo-localization.
Allez dans Paramètres > Langue et défilez vers le bas pour choisir anglais accentué.
Regardez de nouveau la phrase non traduite. Si celle-ci apparaît en anglais normal et non en anglais accentué, il paraît plus probable que cela soit causé par un problème de traduction automatique (l12y).
Dans Bugzilla, ouvrez un bug pour le produit (product) 'Firefox OS'. Choisissez le composant (Component) pour lequel la phrase non traduite apparaît. Ajoutez 'l12y' dans le champ Mots-clés (Keyword).
Veuillez remplir tous les champs obligatoires.

Mots-clés fréquemment utilisés

Le tableau qui suit décrit les différents mot-clés que vous pourrez trouver pour les bugs Firefox OS.

Vous devez toujours indiquer, les Versions/Systèmes/Plate-forme(s) utilisés pour vérifier le bug, dans les commentaires du bug, avant de changer le Status à Verified. Si les bug est ouvert pour plusieurs plate-formes, et que vous n'avez qu'une plate-forme pour le tester, faites le test, nottez dans le bug, mais ne changez surtout pas le Status à Verified. Toutes les plate-formes doivent être testées avant de changer le Status à Verified.

Enfin, si d'autres bugs sont marqués comme doublon (duplicate) du bug que vous vérifiez, assurez vous de les tester et de le mentionner aussi. Souvent des développeurs signalent comme doublon, des bugs qui sont similaires mais pas identiques, et ceux-ci peuvent être oubliés si non testés.

Mot-clé	Description
meta	Indique que ce bug est un bug de suivi. Mozilla utilise cette étiquette pour suivre plusieurs bugs ou les différentes implémentations nécessaires à un scénario d'utilisation. Les développeurs ne sont pas censés apporter de correctifs pour ce type de bug (mais pour les bugs qui le composent). Il faut garder à l'esprit que ces meta-bugs sont utilisés par les chefs de projets et les équipes de qualité pour le suivi.
qablocker	Utilisé pour des bugs qui bloquent la possibilité de faire des tests (manuels ou automatiques) et qui doivent être corrigés pour la prochaine Beta ou version.
qawanted	Utilisé pour des bugs pour lesquels on souhaite avoir plus d'informations, pouvoir les reproduire, identifier le scénario, ou indiquer qu'ils sont dupliqués (au cas où on n'a pas trouvé le bug original). Le champ whiteboard contient une étiquette pour le progrès de l'équipe qualité sur ce point. Le mot-clé qawanted doit être retiré une fois ce travail terminé.
regression	Indique que le problème avait été réglé précédemment mais est survenu à nouveau (une régression logicielle). Le bug en question étant un nouveau bug permettant d'indiquer qu'il y a eu une régresion. Ce type de bug peut également faire référence aux problèmes non-identifiés dans les vérifications et dans les smoke tests, qui se produisent dans les versions compilées actuelles mais qui ne se produisaient pas avant. Suivre ces bugs permet d'identifier les points qui sont fragiles et dont les tests devraient être améliorés/augmentés.
regressionwindow-wanted	Indique que le bug est une régression et qu'il serait utile de connaître à partir de quand (et éventuellement jusqu'à quand) le bug s'est produit. Cela permet d'aider à identifier le code qui a pu introduire la régression.
steps-wanted	Indique un bug pour lequel les étapes de reproduction n'ont pas été suffisamment détaillées ou expliquées. On souhaite que quelqu'un identifie précisément les étapes pour reproduire le bug.
verifyme	Signifie que ce bug peut être vérifié avec la dernière version de B2G par quelqu'un d'autre que la personne de l'équipe qualité indiquée. Ce bug nécessite une configuration matérielle spécifique, indiquée pour vérifier la correction. Il faut alors tenter de reproduire le bug, si la résolution est effective (Fixed est correct), il faut marquer le Status à Verified. Dans les commentaires du bug et avant de changer le statut à Verified, veillez à toujours indiquer la version (build), le système d'exploitation et la plate-forme utilisés pour vérifier le bug. Si le bug est indiqué sur trois plates-formes et qu'il en reste une à vérifier, vous pouvez ajouter un commentaire dans le bug avec ces informations mais pas le marquer comme vérifié. Toutes les plates-formes doivent être testées avant de passer le statut d'un bug à Verified. Enfin, si d'autres bugs ont été identifiés comme des duplicata du bug que vous vérifiez, assurez vous également de vérifier ces bugs et de les commenter. Souvent, des développeurs indiquent des bugs liés (mais pas identiques) comme duplicatas, ce qui fait que ces derniers sont parfois sous-estimés pour la vérification.
crash	Ajouté ce mot-clé si vous rencontrez un crash dans Firefox OS.

Note : Pour plus d'informations sur la gestion des bugs lors du développement de Gaia, lire la page soumettre un correctif (patch) pour Gaia.

Voir aussi

Rapporter un bogue sur Bugzilla (traduction d'un article de Liz Henry)