Wiki » Politique en matière de bogues-fr

Introduction

Cet article décrit le processus de gestion des rapports de bogues pour Mageia. Le but de ce document est de clarifier les responsabilités de toutes les parties concernées (rapporteurs, membres de la Brigade anti-bogues et mainteneur des paquets), et de couvrir toutes les éventualités possibles afin que l’on sache toujours quelles actions doivent être entreprises afin de résoudre chaque bogue et par qui.

Définition

Un bogue est défini comme un cas dans lequel un composant de la distribution Mageia Linux (ou d’autres composants couverts par Mageia Bugzilla), ne remplit pas sa ou ses fonctions prévues.

Procédure

Des bogues peuvent être signalés sur Mageia par tout utilisateur de la distribution. Notre objectif est de gérer tous les bogues déposés pour Mageia. Cela ne signifie pas nécessairement que tous les bogues seront résolus de la manière jugée la meilleure par le déclarant ; bien que nous visions ce résultat dans la mesure du faisable, nous reconnaissons que cela peut parfois ne pas être possible. Nous nous efforcerons, autant que faire se peut, de traiter correctement les bogues non valides ou mal dirigés et de résoudre ceux qui sont valides. Cela signifie que les problèmes légitimes dans les paquets supportés doivent être corrigés dans la mesure du réalisable. Lorsque les problèmes ne peuvent être résolus, une explication complète des circonstances est requise. L’un ou l’autre de ces éléments constitue une résolution. Lorsque les problèmes sont en double, invalides, ne relèvent pas d’un système de résolution de bogues ou sont impossibles à reproduire, ils doivent porter la mention RESOLVED avec le statut approprié et une explication complète par le mainteneur du paquet ou un membre de la brigade anti-bogues. Ces résultats constituent également une résolution. Aucun autre résultat ne peut être considéré comme constituant une résolution.

Comptes rendus

Les rapports de bogues sont traités à l’aide de Bugzilla. La distribution et le produit doivent être choisis par le déclarant. Un rapport de bogue doit inclure une analyse complète du problème et, le cas échéant, une description détaillée des étapes nécessaires pour reproduire le souci. Toutes les indications pertinentes sur l’environnement pour reproduire le problème – des éléments matériels spécifiques, des paquetages logiciels particuliers ou des paramètres de configuration précis – doivent également être inclus. Les corrections suggérées, y compris les correctifs, sont toujours les bienvenues mais ne sont pas obligatoires.

Tri

Tous les bogues seront initialement sous la responsabilité de la brigade anti-bogues. Pendant le triage, la brigade anti-bogues a deux responsabilités essentielles. Celle-ci doit décider si un problème nécessite ou non une action de la part du responsable du paquet.

Problèmes ne nécessitant pas d’action de la part du mainteneur du paquet

Les cas suivants ne requièrent aucune action de la part du mainteneur du paquet. Les cas suivants ne requièrent aucune action de la part du mainteneur du paquet. Lorsqu’un problème ne nécessite pas l’intervention du mainteneur du paquet, il incombe à l’équipe de bug de le résoudre.

• Le bogue est un //doublon// d’un rapport existant. Cela signifie que le même problème a déjà signalé sur le même produit dans la même version. Les signalements d’un même problème dans des versions //différentes// ne sont pas considérés comme des doublons. La brigade anti-bogue doit mettre les doublons sur le statut RESOLVED DUPLICATE. Cela équivaut à la résolution du problème.

• Le problème ne constitue pas un bogue tel que défini ci-dessus. Ce serait le cas, par exemple, lorsqu’un rapport de bogue demande la création d’une fonctionnalité supplémentaire dans un logiciel non maintenu par l’équipe de développement de Mageia, ou lorsqu’un bogue est déposé à la suite d’une erreur de l’utilisateur. Les membres de l’escouade des bogues doivent définir les problèmes qui ne correspondent pas à la définition d’un bogue comme suit : RESOLVED INVALID ou RESOLVED WONTFIX, sauf en cas de demandes légitimes de perfectionnement (qui sont décrites dans une section distincte ci-dessous). Cela constitue une solution au problème.

• Le problème n’est pas un doublon et répond à la définition d’un bogue, mais il serait préférable de le traiter plus avant dans la chaîne de développement. Certains problèmes ne peuvent être résolus de manière raisonnable en ce qui concerne les paquets de distribution. De tels problèmes incluent, par exemple, des bogues fondamentaux dans le code d’une application. Dans ce cas, les membres de la brigade anti-bogues demanderont au déclarant de signaler le bogue au niveau approprié de la chaîne de développement via la méthode la plus recommandée pour signaler les bogues du projet en question (par exemple, demandez-lui de signaler le bogue à GNOME Bugzilla), au cas où il s’agirait d’un bogue qui serait mieux géré par l’équipe de développement GNOME. Une fois cela fait, les membres de la brigade anti-bogues (ou le déclarant) doivent définir le rapport de bogue Mageia sur le statut RESOLVED REPORTEDUPSTREAM, avec un lien direct vers le rapport source qui doit être placé dans le champ URL de Bugzilla. Dans le cas où les bogues appartiennent à Cauldron, cela constitue une résolution du problème, en supposant qu’une fois le problème résolu en amont, la version mise à jour sera intégrée à Mageia dans un délai raisonnable. Dans le cas des bogues déposés sur les versions stables, cela ne constitue qu’une résolution temporaire du problème, car les nouvelles versions ne sont pas intégrées systématiquement aux versions stables. Une fois le problème corrigé en amont, la brigade anti-bogues ou le déclarant initial peut ré-ouvrir le bogue, et il sera alors réévalué pour déterminer s’il est envisageable de fusionner la correction en amont pour faire une mise à jour officielle, de la version Mageia affectée.

Problèmes nécessitant une action de la part du mainteneur du paquet

Les problèmes qui n’entrent pas dans les catégories ci-dessus – c’est-à-dire les problèmes qui répondent à la définition d’un bogue, qui n’ont jamais été signalés auparavant, qui peuvent être reproduits et qui peuvent être résolus de manière raisonnable au niveau de l’empaquetage de la distribution sont des problèmes valables nécessitant une action du mainteneur du paquet. Dans ces cas, la responsabilité de la brigade anti-bogues est de s’assurer que tous les renseignements pertinents (tels qu’énoncés dans la section Rapports ci-dessus) ont été fournis par le déclarant, d’établir les champs Priority et Severity de manière adaptée et de s’assurer qu’ils sont attribués au mainteneur approprié.

La brigade anti-bogues ne devrait en aucun cas assigner des rapports de bogue aux mainteneurs sans s’assurer au préalable de recevoir toute l’information nécessaire.

Lorsque toutes les informations nécessaires sur un bogue sont présentes dans le rapport initial, le bogue peut être immédiatement attribué au mainteneur approprié. À ce stade, le bogue devient la responsabilité du mainteneur.

Lorsque des informations nécessaires manquent dans le rapport initial, les membres de la brigade anti-bogues doivent ajouter le mot-clé NEEDINFO et un commentaire pour informer le déclarant des informations supplémentaires requises et expliquer les étapes nécessaires pour produire ces informations ou un lien pour les expliquer. Tant que cette étape n’est pas franchie, ce bogue demeure sous la responsabilité de la brigade anti-bogue. Aussitôt que ces mesures sont appliquées, le bogue relève de la responsabilité du déclarant jusqu’à ce qu’il fournisse les renseignements supplémentaires requis. Si cette information n’est pas reçue dans un délai raisonnable, ou si le déclarant répond qu’il n’est pas en mesure de fournir l’information demandée, le responsable du paquet pourra alors s’abstenir et la brigade anti-bogues devra traiter le problème en conséquence.

La brigade anti-bogues doit également définir les champs Priority et Severity de manière appropriée pour chaque bogue. Les responsables de la maintenance utiliseront ces champs pour établir l’ordre de priorité de leur charge de travail, leur précision est donc primordiale.

• Le champ Priority reflète l’urgence avec laquelle le bogue doit être corrigé, c’est-à-dire qu’il dépend de l’importance du bogue dans le contexte de la distribution dans son ensemble.
• Le champ Severity reflète la gravité du bogue dans le cadre du paquet.

Ainsi, un bogue critique dans un paquet rarement utilisé peut être d’une gravité critical mais d’une priorité low, et un bogue mineur mais très visible dans un paquet couramment utilisé peut être d’une gravité minor mais d’une priorité release_blocker.

Niveaux de Priorité

• La priorité release_blocker (bloqueur de version) est surtout pertinente pour les bogues déposés sur les instantanés de stabilisation et les versions candidates, et ne devrait être utilisée que pour les problèmes suffisamment critiques qui affecteraient sérieusement la qualité globale de la version si elle était disponible sans que le problème soit résolu. En outre (aucun bogue n’est release_blocker pour une distribution déjà publiée).
• La high (haute priorité) devrait être utilisée pour les problèmes qui sont suffisamment critiques pour que leur résolution soit prioritaire par rapport à la résolution d’autres problèmes, mais qui ne répondent pas aux critères de release_blocker.
• La low (faible priorité) devrait être utilisée pour les bogues qui sont suffisamment banals et/ou dont l’impact est suffisamment limité pour que la résolution d’autres problèmes ait la priorité.
• La normal (priorité normale) devrait être utilisé pour toutes les autres demandes.

Niveaux de Gravité

• Le niveau critical (critique) doit être utilisé pour les bogues qui rendent un paquet inutilisable (par exemple, les plantages qui affecteraient la majorité des utilisations d’un paquet, ou l’incapacité totale à installer ou exécuter le paquet).
• Le niveau major (important) doit être utilisé pour les problèmes qui rendent une fonctionnalité significative du paquet inutilisable ou instable.
• Le niveau minor (mineur) devrait être utilisé pour les questions 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.
• Le niveau enhancement (perfectionnement) devrait être utilisé pour les progrès qui ne sont pas des corrections de bogues, et les demandes de paquets.
• Le niveau normal (normal) devrait être utilisé pour toutes les autres questions.

Une fois que la brigade anti-bogues a fini de trier un bogue, ils peuvent ajouter le mot-clé Triaged à ce bogue.

Détermination du mainteneur

Lorsqu’un problème nécessite une action de la part du mainteneur du paquet et que toutes les informations appropriées ont été fournies par le mainteneur du paquet (avec l’aide de la brigade anti-bogue), il incombe au mainteneur du paquet de résoudre ce problème. Les mainteneurs peuvent marquer un bogue comme étant RESOLVED FIXED une fois qu’ils ont identifié un correctif et l’ont engagé dans SVN, mais pour les versions stables, leur responsabilité dépasse ce cadre. Pour les paquets supportés, ils doivent également s’assurer qu’une mise à jour officielle est publiée, conformément à la politique de support après publication. Il est souhaitable qu’un lien soit affiché dans le rapport de bogue original vers le rapport de bogue de la demande de mise à jour (lorsque les deux sont différents), pour permettre aux utilisateurs de suivre l’état de la mise à jour. Pour les paquets non supportés, il est souhaitable que le mainteneur publie un paquet mis à jour directement dans le référentiel approprié.

L’éventail des actions possibles requises pour résoudre les bogues dépasse, bien entendu, la portée de ce document. Une fois que le paquet corrigé est disponible dans le référentiel approprié, il est de la responsabilité du mainteneur de mettre le bogue le status RESOLVED FIXED.

Capacité des Mainteneurs à court-circuiter le processus de tri

Il y a un cas ou l’on peut déroger au processus ci-dessus. Il est acceptable qu’un mainteneur de paquet court-circuite le processus de triage. Si un bogue n’a pas encore été entièrement trié mais que le responsable du paquet concerné est confiant sur sa capacité à résoudre le problème, il peut prendre en charge le bogue. À ce stade, le mainteneur a accepté la responsabilité de corriger le problème tel qu’il a été signalé et/ou d’obtenir des informations supplémentaires du déclarant. Le bogue n’est plus la responsabilité de la brigade anti-bogues, malgré le fait que le processus de triage n’a pas encore été complètement terminé. Le mainteneur ne peut alors pas assigner le bogue de nouveau à la brigade anti-bogues.

VERIFIED et CLOSED

L’état VERIFIED est considéré comme inutile pour notre processus de gestion des bogues et il n’est donc pas nécessaire d’utiliser ces états sur le Mageia Bugzilla. Lorsque le mainteneur considère qu’un problème a été corrigé, il sera marqué RESOLVED FIXED. Si le déclarant ou la brigade anti-bogues souhaite vérifier la clôture, ils peuvent le faire : s’ils confirment que le bogue a été corrigé, laissez simplement la valeur RESOLVED FIXED; s’ils constatent qu’il n’est pas corrigé, ils peuvent rouvrir le bogue.

Demandes d’amélioration

Un cas particulier dans le processus de suivi des bogues de Mageia sont les demandes d’amélioration. Les demandes d’amélioration valides incluent les demandes de fonctionnalités supplémentaires dans les logiciels écrits ou maintenus par les développeurs Mageia, et les suggestions d’améliorations dans les packages actuels des logiciels qui ne sont ni écrits ni maintenus par des développeurs Mageia. Les demandes de fonctionnalités supplémentaires dans les logiciels qui ne sont pas écrites ou maintenues par les développeurs Mageia ne sont pas considérées comme des demandes d’amélioration valides, et sont couvertes au paragraphe ci-dessus Problèmes ne nécessitant pas d’action de la part du mainteneur du paquet.

La responsabilité de la brigade anti-bogues dans le cas de demandes d’amélioration se limite à s’assurer que le déclarant fournit une explication complète et compréhensible de la demande d’entité, et que le champ Gravité est correctement défini sur la valeur de l’amélioration. À ce stade, la brigade anti-bogues devrait attribuer le rapport de bogue au mainteneur approprié.

Le mainteneur n’est pas obligé d’accueillir une demande d’amélioration. Celles-ci ne constituent pas de « bogues » au sens de la définition ci-dessus et, par conséquent, notre politique n’est pas de les résoudre dans tous les cas. Le mainteneur peut choisir d’accepter ou non la demande. Si le mainteneur choisit d’accepter la demande, il doit ajouter un commentaire à cet effet. Une fois la demande implémentée dans un paquet disponible dans le référentiel approprié, il doit définir le statut du bogue sur RESOLVED FIXED. Si le mainteneur décide de ne pas accepter la demande, il doit ajouter un commentaire expliquant sa décision et définir le statut du bogue sur le statut RESOLVED WONTFIX. L’un ou l’autre de ces résultats constitue une résolution du problème.

Retous ver le portail de la Brigade anti-bogues