BugZappers/BugStatusWorkFlow/fr

In other languages: English (en) español (es) français (fr) 中文（中国大陆） (zh-cn) [edit]

Flux de travail pour un bogue

Bug workflow diagram

Ce diagramme de flux d'état d'un bogue est le résultat de la relance du triage de bogues qui a démarré en janvier 2008. Ce flux de travail a été approuvé lors de la réunion du 24 janvier 2008 . S'agissant d'un flux de travail, ce ne sont pas des règles strictes et rapides qui s'imposent à tous. L'intention est plutôt d'apporter une plus grande uniformité et prédictibilité dans la vie d'un bogue. Si vous avez des raisons valables de ne pas respecter ces règles, alors ne vous gênez pas. Le processus décrit est celui qui est suivi par l'équipe de triage.

Ce document ne s'applique qu'aux bogues conventionnels – c'est à dire qu'il ne s'applique pas aux cas d'utilisation spéciaux de Bugzilla comme les demandes de revue de paquets.

Mis à jour le 17 mars 2009 pour prendre en compte les changements apportés par la représentation de NEEDINFO (BESOIN D'INFO).

Mis à jour en mars 2010 pour prendre en compte No Frozen Rawhide Implementation.

États et indications de résolution

NEW

Lorsqu'un utilisateur signale un bogue, le rapport commence automatiquement dans l'état NEW (NOUVEAU). L'équipe de triage commence par regarder les bogues dans cet état. À partir de là, elle change l'état en :

• NEW: mais avec l'indication Triaged (trié): le bogue est bien défini et trié.
• CLOSED: mais avec une indication duplicate (doublon), ce n'est pas un bogue, ça ne fait pas partie de Fedora, etc.
• NEW mais avec l'indication needinfo : plus d'informations sont attendues du rapporteur avant d'être Triaged (trié).

Needinfo

L'indication needinfo (besoin d'informations) est ajoutée par les trieurs de bogues ou par les mainteneurs lorsque une information adéquate est manquante pour avancer vers la résolution du bogue. Si cette information est apportée par la suite, le trieur efface l'indication et met le bogue dans l'état NEW mais cette fois-ci avec l'indication Triaged. Si l'information n'est pas apportée, les bogues marqués needinfo sont éligibles à la fermeture – c'est à dire au passage à l'état CLOSED INSUFFICIENT_DATA (FERMÉ DONNÉES_INSUFFISANTES) par l'équipe de triage après que l'ensemble de conditions suivantes ont été satisfaites :

1. le bogue a reçu l'indication needinfo dès le début par un trieur ou un mainteneur,
2. l'information réclamée n'a pas été apportée,
3. le bogue a conservé l'indication needinfo pendant 30 jours d'affilé.

Un message standard est utilisé par tous les trieurs pour les bogues remplissant les critères de fermeture. Les messages standards sont visibles sur la page BugZappers/StockBugzillaResponses.

Parce que needinfo est une indication et pas un état, ces bogues peuvent être dans l'état NEW, ASSIGNED, etc, selon le cas.

Triaged

L'indication Triaged est ajoutée une fois que l'équipe de triage pense que le bogue est complètement décrit pour donner lieu à une action. Il contient:

• le produit (product) correct,
• le composant (component) correct,
• suffisamment d'informations pour permettre aux mainteneurs du paquet de rechercher une solution,
• suffisamment d'informations pour effectuer une recherche avec l'amont ou pour trouver une solution,
• applicable release blocker or tracker bugs.

Le rapporteur doit aussi inclure un ou plus des renseignements suivants (si applicables) :

• une description claire par étapes de la manière dont le bogue est apparu,
• une description claire des étapes à suivre pour reproduire le bogue,
• la pile d'appels pour un plantage,
• les divers journaux,
• le message AVC (Acces Vector Cache) pour SELinux

Reportez-vous à Remplir un rapport de bogue ou une demande d'amélioration pour plus d'information.

ASSIGNED

Les mainteneurs individuels ou les équipes de mainteneurs d'un composant sont libres d'utiliser l'état ASSIGNED (assigné) de la manière la plus appropriée à leur flux de travail spécifique. Dans le cas d'un mainteneur individuel, il peut soit placer tous les bogues dans l'état ASSIGNED, soit n'y en placer aucun, soit ne placer que ceux sur lesquels il est en train de travailler. Lorsqu'il s'agit d'une équipe, l'état ASSIGNED peut être utilisé pour indiquer qu'un mainteneur particulier du groupe s'est vu assigner ce bogue.

Pour les versions antérieures à Fedora 13, cet état était utilisé pour indiquer qu'un bogue avait été trié (ce qui est aujourd'hui assuré par l'ajout de l'indication triaged).

ON_DEV

L'état ON_DEV (en développement) est facultatif. Il est utilisé pour montrer que quelqu'un est en train de travailler sur la résolution du bogue. Cela est particulièrement utile s'il existe une équipe de maintenance pour un paquet.

POST

• Cet état est en premier lieu utilisé par les développeurs qui travaillent sur la virtualisation et le noyau.
• Un bogue est passé à l'état POST (posté) – depuis l'état ASSIGNED – lorsqu'un correctif a été attaché à l'entrée de Bugzilla et que le gate keeper (gardien à l'entrée) attend que le correctif ait reçu trois ACKS (approbations). Par conséquent, l'état POST indique qu'un correctif est prêt mais qu'il n'est pas encore appliqué.
• Une fois que le correctif a été appliqué, le bogue passe à l'état MODIFIED (modifié).

MODIFIED

Lorsqu'un mainteneur dispose d'un correctif pour un bogue dans le CVS (système de contrôle de version), le bogue doit être placé dans l'état MODIFIED (modifié) . Cela indique que le correctif est vérifié dans le CVS et a pu être soumis pour compilation dans la nouvelle version du paquet. L'ajout d'un lien dans koji est très utile pour les testeurs aventuriers et pour le rapporteur à l'origine du bogue pour vérifier que le correctif convient. L'utilisation de l'état MODIFIED pour les bogues de Rawhide , ou pour les bogues de Branched en dehors du chemin critique, qui sont en dehors des dates de gel, est facultatif ; un mainteneur peut choisir de l'utiliser pour demander au rapporteurs de vérifier le paquet corrigé pour s'assurer que le correctif fonctionne avant de fermer le bogue, mais peut aussi aller directement à l'état CLOSED RAWHIDE (ou CLOSED ERRATA pour les bogues de Branched) lors de la soumission d'un correctif, ou passer un bogue de MODIFIED à CLOSED si aucun rapporteur ne semble vouloir ou pouvoir confirmer le correctif.

ON_QA

Un bogue passe automatiquement par l'état ON_QA (en assurance qualité) lorsqu'un paquet mis à jour est soumis à bodhi pour un bogue particulier et que le paquet se trouve dans le dépôt testing. Cela indique au rapporteur du bogue qu'un correctif pour ce bogue est disponible et qu'il doit être testé. Après le test du paquet, le testeur ou le rapporteur à l'origine du bogue doivent remettre leurs résultats de test dans bodhi et ajouter un commentaire à Bugzilla.

VERIFIED

L'état VERIFIED (vérifié) indique que le bogue dispose d'un correctif confirmé disponible dans un paquet mis à jour. Un correctif est considéré comme « confirmé » grâce aux commentaires des utilisateurs dans Bodhi ou dans Bugzilla, ou il peut être confirmé par les rapporteurs du bogue et les trieurs via des tests préalables. La version de Fedora pour le bogue et celle pour le paquet mis à jour doivent être identiques. Les interventions des utilisateurs telles que des solutions de contournement ou des corrections appliqués manuellement, ne satisfont pas aux exigences pour le passage dans cet état car elle ne sont pas incluses dans un paquet.

L'état VERIFIED est le dernier état qui est défini manuellement avant que le bogue ne soit fermé automatiquement par Bodhi.

CLOSED

Une fois que le bogue a été corrigé et que son correctif a été inclus dans un paquet mis à jour dans Rawhide, ou dans le dépôt updates, il doit être fermé (CLOSED) . Pour une version stable ou Branched, l'indication de résolution ERRATA doit être utilisée. Pour Rawhide, l'indication de résolution RAWHIDE doit être utilisée.

L'indication de résolution doit correspondre à la version pour laquelle le bogue a été rapporté. En conséquence, un bogue rapporté pour une version stable ne peut être fermé comme fixed (corrigé) si le correctif n'a été apporté qu'à la version Rawhide. Un bogue rapporté pour une version stable ne peut être fermé avec l'indication de résolution ERRATA si le correctif a seulement été apporté à une version stable différente. L'indication correcte de résolution dans une telle situation est NEXTRELEASE, assortie d'un commentaire explicatif.

L'indication de résolution DEFERRED (différée) n'est pas utilisable pour Fedora – elle est utilisée seulement par le processus de RHEL) .

Dans le cas de Rawhide, les mainteneurs peuvent choisir CLOSED RAWHIDE dès qu'ils ont soumis un correctif dans le CVS, et si l'on se trouve en dehors des périodes de gel ; Le processus MODIFIED est facultatif.

• Un bogue peut être fermé avec l'indication DUPLICATE (doublon) par un trieur ou un mainteneur à tout moment s'il on découvre l'existence d'un autre bogue identique.
• Des bogues peuvent être fermés avec l'indication INSUFFICIENT_DATA (données insuffisantes) par un trieur ou un mainteneur s'il semble impossible, ou très improbable, que le rapporteur apporte l'information nécessaire.
• Des bogues peuvent être fermés avec l'indication NOTABUG (ce n'est pas un bogue) par les trieurs lors de l'étape de triage s'il devient évident qu'il ne s'agit pas de véritable bogues dans Fedora (p. ex. le matériel du rapporteur est défaillant), ou par un mainteneur.
• Les indications de résolution CANTFIX, WONTFIX et WORKSFORME sont réservées aux mainteneurs et sont auto-explicatifs.
• L'indication de résolution CURRENTRELEASE (version courante) est réservée au cas où le bogue est rapporté avant la parution de la version, et par conséquent reconnu comme étant à corriger avec la version finale. Par exemple, un bogue est rapporté pour la version Fedora 42 alors que cette dernière est encore dans l'étape de pré-version, et reste ouvert lors de la parution de la version ; si après la parution de la version Fedora 42 le rapporteur refait sa vérification est découvre que le bogue a été réellement corrigé, il utilise l'indication de résolution CURRRENTRELEASE.

• L'indication de résolution NEXTRELEASE (prochaine version) est réservée aux mainteneurs. Elle est utilisée si un bogue a été rapporté pour une version donnée mais ne sera corrigé que dans une version ultérieure – par exemple, si un bogue est rapporté dans la version stable courante, mais que le mainteneur pense que le correctif ne peut être apporté dans des conditions de sécurité, ou vaut la peine d'être corrigé, seulement pour Rawhide et les versions à venir, mais pas pour la version pour laquelle le bogue a été rapporté.
• L'indication de résolution UPSTREAM (amont) peut être utilisée par les mainteneurs pour indiquer qu'ils s'attendent à ce que le bogue soit finalement corrigé par le développement amont, et repris naturellement dans Fedora par le processus normal de mise à jour. Dans l'idéal, un commentaire devrait être ajouté avec un lien vers le rapport de bogue de l'amont.

Si cela est indiqué comme tel par le mainteneur, Bodhi pour fermer automatiquement un bogue lorsque le paquet passe du dépôt updates-testing (mis à jour en test) au dépôt updates.

FAILS_QA, RELEASE_PENDING

Les états FAILS_QA (échec assurance qualité) et RELEASE_PENDING (version imminente) ne sont pas utilisés par Fedora (ils sont utilisés dans le processus de RHEL).

Priority et Severity

Le champ severity (sévérité) est utilisé pour indiquer le degré de sévérité d'un bogue, d'un point de vue objectif. Il est défini à l'origine par le trieur et sa définition définitive demeure sous le contrôle de l'attributaire du bogue et/ou des mainteneurs du paquet. Si l'attributaire, ou un mainteneur du paquet, change le degré de sévérité initiale défini par le trieur, l'équipe de triage ne peut plus changer ce champ.

Le champ priority (priorité) peut être utilisé, selon leur choix par les mainteneurs pour suivre l'ordre dans lequel ils désirent traiter les bogues relatifs à leur(s) paquet(s). Ils peuvent, pour le définir, prendre en compte le degré de sévérité, ou appliquer une autre méthode ; cela reste à leur seule discrétion. Ils peuvent aussi l'ignorer totalement. Personne d'autre qu'un mainteneur (ou une équipe) responsable d'un bogue particulier ne devrait toucher à ce champ à n'importe quel moment.

Par conception, les rapporteurs n'ont pas accès aux champs severity ou priority. Le champ priority n'existe que pour le besoin de l'équipe de développement, et c'est ordinairement le cas que, seuls les trieurs et les mainteneurs ont une vue d'ensemble satisfaisante de tous les problèmes pour pouvoir décider de la sévérité d'un bogue donné.

Severity

Les valeurs possibles du champ severity doivent être attribuées selon les critères suivants :

• Urgent : le bogue rend le système entier inutilisable (ou il s'agit d'un bogue touchant à la sécurité, qui est par définition urgent).
• High (haute) : le bogue rend le programme en question inutilisable, ou concerne une violation des recommandations pour les paquets (problème de licence, bibliothèque liée, etc.).
• Medium (intermédiaire) : un bogue réel qui rend l'utilisation du programme plus difficile, au moins une partie du programme est disponible ; des solutions de contournement sont disponibles.
• Low (basse) : toute autre chose – problème cosmétique, cas d'espèce (avec des configurations qui s'écartent des configurations par défaut, etc.).

Le niveau de sévérité urgent ne doit pas être utilisé pour des bogues spécifiques au matériel : un bogue qui affecte la distribution tout entière mais qui ne concerne qu'un unique type de matériel doit être classé en priorité haute. Par exemple, si un bogue empêche X.org de fonctionner correctement sur un chipset (jeu de composants) graphique particulier, le niveau de sévérité high doit être utilisé, pas urgent.

Pour la plupart des paquets, la majorité des problèmes sont vraisemblablement de sévérité medium. Il ne s'agit pas de règles strictes et les trieurs et les mainteneurs doivent faire appel à leur bon sens pour définir le champ severity. Il existe des cas qui nécessitent du bon sens – par exemple, un bogue qui n'affecte pas seulement le programme dans lequel il apparaît mais moins que le système entier.

Voir aussi

• La page A Bug's Life Cycle pour des définitions des autres états et indications de résolution. Lorsque cette dernière est en contradiction avec la présente page, dans le cas de Fedora et EPEL, c'est cette page qui prévaut : dans le cas de Red Hat Enterprise Linux et autres produits Red Hat, la page référencée prévaut.