BugZappers/BugStatusWorkFlow/fr

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

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écrite est celui qui est suivi par l'équipe de triage.

Ce document ne s'applique qu'aux bogues 'conventionnels' – c.-à-d. 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 résolutions

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),cantfix ( 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 à être mis dans 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 soulution,
• 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

This optional state is used to show that someone is working on fixing this bug. This is especially useful if there exists a team of maintainers for a package.

POST

• This state is primarily used by developers working on virtualization and the kernel.
• A bug is moved to the POST state (from ASSIGNED) when a patch has been attached to the bugzilla entry and the gate keeper is waiting for the patch to receive three ACKS. Therefore, POST means "a patch is ready, but not yet applied".
• After the patch is applied to the package the bug state changes to MODIFIED.

MODIFIED

When a maintainer has a fix for a bug checked into CVS the bug should be placed in the MODIFIED state. This is an indication that the fix is checked into CVS and has potentially been submitted to be built in a new package. Adding a link to package in koji is very helpful for adventuresome testers and the original bug reporter to verify the fix.

The use of MODIFIED for Rawhide bugs, or non-critical-path Branched bugs outside of freeze times, is optional; a maintainer may choose to use it to ask the reporters to test the fixed package to make sure the fix works before closing the bug, but can also go direct to CLOSED RAWHIDE (or CLOSED ERRATA for Branched bugs) on committing a fix, or change a MODIFIED bug to CLOSED if no reporter appears willing or able to confirm the fix.

ON_QA

A bug automatically transitions to this state when an updated package is submitted to bodhi for a particular bug and the package is in the testing repo. This tells the bug reporter that a fix for the bug is available and that they should test the package. After testing the package the bug tester or original reporter should put feedback in bodhi and add a comment to the Bugzilla.

VERIFIED

The VERIFIED state indicates that a bug has a confirmed fix available in an updated package. A fix is considered confirmed due to user's comments in Bodhi or Bugzilla, or it may be confirmed by bug reporters and triagers through first-hand tests. The release of Fedora must match for both the bug report and the updated package. User intervention, such as workarounds or manually-applied patches, do not meet the requirements for this state, as they are not contained in a package.

VERIFIED is the final state that is manually set before the bug is automatically closed by Bodhi.

CLOSED

Once a bug has been fixed and included in a new package in rawhide or the updates repo it should be closed. For a stable or Branched release, the resolution ERRATA should be used. For Rawhide, the resolution RAWHIDE should be used.

Note that the resolution must match the release against which the bug is filed. Therefore, a bug reported for a stable release cannot be closed as 'fixed' if a fix is shipped only in Rawhide. A bug in one stable release cannot be closed as 'fixed' - ERRATA - if a fix is shipped only in a different stable release. The correct resolution for these situations is NEXTRELEASE, with an explanation as a comment.

The DEFERRED resolution is not intended for use by Fedora (it is used in the RHEL process).

For Rawhide, maintainers can choose to move to CLOSED RAWHIDE as soon as they commit a fix to CVS, if outside a freeze period; the MODIFIED process is optional.

• Bugs can be closed as DUPLICATE by a triager or maintainer at any point when they are identified as a duplicate of another bug.
• Bugs can be closed as INSUFFICIENT_DATA by a triager or maintainer if it seems impossible or very unlikely that the reporter will be willing or able to provide sufficient information.
• Bugs can be closed as NOTABUG by triagers during the triage stage if it becomes clear they are not truly a bug in Fedora (e.g. the reporter's hardware is malfunctioning), or by the maintainer.
• The resolutions CANTFIX, WONTFIX, and WORKSFORME are for use by maintainers only, and are self-explanatory.
• The resolution CURRENTRELEASE is to be used in the case where a bug is reported before a release is made, and subsequently discovered to be fixed in the final release. For instance, a bug is reported against Fedora 41 while it is still in the pre-release stages, and remains open when the release is made; however, when the final Fedora 41 is made, the reporter re-tests and discovers the bug was actually fixed. In this case, the CURRENTRELEASE resolution is used.
• The resolution NEXTRELEASE is for use by maintainers only. It is used if a bug was filed for a given release, but will only be fixed for later releases - for instance, if a bug is filed in the current stable release, but the maintainer only thinks it safe or worthwhile to fix it in Rawhide and future releases, not the release on which it was reported.
• The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be eventually fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report.

If so designated by the maintainer, Bodhi can automatically close a bug when the package moves from the updates-testing repo to the updates repo.

FAILS_QA, RELEASE_PENDING

The FAILS_QA and RELEASE_PENDING bug states are not used by Fedora (they are used in the RHEL process).

Priority and Severity

The severity field is used to indicate how severe the bug is, objectively speaking. It is initially set by the triager, and ultimate control rests with the assignee of the bug and/or the package maintainer(s). If the assignee and/or package maintainer(s) change the initial severity level chosen by the triager, the triage team may not then change the field further.

The priority field may be used, at their choice, by maintainers to keep track of the order in which they wish to address bugs in their package(s). This may be done with relation to the severity setting, or by any other method the maintainer chooses, at the maintainer's sole discretion. It may also be entirely ignored, if the maintainer in question does not wish to use it. No-one other than the maintainer or team responsible for a particular bug should change this setting at any point.

Reporters have no access to set the severity or priority fields. This is by design. The priority field exists solely for the convenience of the development team, and it is usually the case that only triagers and maintainers have a sufficient overview of all issues correctly to determine the severity of any particular bug.

Severity

The values for the severity field should be assigned with reference to the following guidance:

• Urgent: the bug makes whole system unusable (or it is a security bug, which is per definition urgent)
• High: the bug makes the program in question unusable, or a major packaging guideline violation (license problem, bundled library, etc)
• Medium: a real bug which makes program more difficult to use, at least part of the program is available; possibly workarounds are available
• Low: anything else - cosmetic issues, corner cases with unusual (non-default) configurations, etc.

As a caveat, the urgent setting should not usually be used for hardware-specific bugs: a bug which causes the entire distribution to be affected but is restricted to a single specific type of hardware should usually be set to high. For instance, if a bug prevents X.org working correctly on a single particular graphics chipset, the high severity, not urgent, should be used.

For most packages, most issues are likely to be of medium severity. These are not hard and fast rules, and triagers (and maintainers) should use their best judgement in setting the severity field appropriately. There are obvious cases which require the exercise of judgement - for instance, a bug which affects more than just the program in which it occurs, but less than the 'whole system'.

See also

• A Bug's Life Cycle for definitions of other Bugzilla statuses and resolutions. Where that page comes into conflict with this one, in the case of Fedora and EPEL, this page takes precedence: in the case of Red Hat Enterprise Linux and other Red Hat products, that page takes precedence.