Bug Status Workflow

This document describes best practices for setting Bugzilla status for bugs and feature requests. For Change proposal trackers, use the Bugzilla status described in the Changes policy.

Statuses

The image below presents a general flow chart for bugs in the typical case. The flow is bi-directional: a bug can revert to a previous status if, for example, a proposed fix is incomplete.

The table below summarizes the statuses. More details, including additional keywords, flags, and resolutions are given in the following sections.

Table 1. Estados Bugzilla
Estado	Significado
NEW	El estado predeterminado. Indica, generalmente, un error que no ha sido investigado activamente por el asignado.
ASSIGNED	Puede ser utilizado por los mantenedores para indicar que el error ha sido examinado y asignado para trabajar.
ON_DEV	Puede ser usado por los mantenedores para indicar que el trabajo está activamente en marcha. Este es especialmente útil si existe un equipo de mantenedores para un paquete.
POST	Indica una corrección preparada, pero no aplicada. esto es utilizado, a menudo, cuando una solicitud de extracción está abierta upstream.
MODIFIED	Indica una corrección que ha sido compilada en una actualización. Bodhi establecerá este estado automáticamente cuando una actualización se crea si el error se asocia con la actualización.
ON_QA	Indica una actualización con una corrección en repositorio testing. Bodhi establecerá este estado automáticamente cuando una actualización alcanza updates-testing si el error está asociado con la actualización.
VERIFIED	Indica un error que tiene una corrección confirmada en una actualización.
RELEASE_PENDING	(No utilizada generalmente en Fedora. Utilizada por los flujos de trabajo Red Hat Enterprise Linux.)
CLOSED	Indica que el error ha sido corregido o no será corregido. El estado CLOSED tiene diferentes resoluciones para indicar porque el error fue cerrado. Bodhi establecerá este estado automáticamente cuando una actualización alcanza el repositorio updates si el error está asociado con la actualización.

Resolutions

The table below describes the resolutions that can apply to the CLOSED status.

Table 2. Resoluciones Bugzilla
Resolución	Significado
CANTFIX	Usado por los mantenedores para indicar un error que no puede ser corregido.
CURRENTRELEASE	Indica un error reportado en Branched antes del lanzamiento y la corrección fue corregifa para el lanzamiento final.
DEFERRED	(No utilizado generalmente en Fedora. Utilizado por los flujos de trabajo Red Hat Enterprise Linux.)
DUPLICATE	Indica que un error es un duplicado de otro.
EOL	Indica un error presentado contra una versión que ha alcanzado el Fin de Vida.
ERRATA	Indica un error que es corregido en un lanzamiento estable.
FAILS_QA	(No utilizado generalmente en Fedora. Utilizado por los flujos de trabajo Red Hat Enterprise Linux.)
INSUFFICIENT_DATA	Indica que el rerporte de error no está dispuesto o no puede proporcionar información suficiente para diagnosticar o corregir el error.
NEXTRELEASE	Utilizado por los mantenedores para indicar un error que solo será corregido en lanzamientos posteriores, no en el lanzamiento en que se ha informado.
NOTABUG	Indica que el reporte no es un error (por ejemplo, es iun fallo de hardware o una cuestión de soporte).
RAWHIDE	Indica un error que está corregido en una actualización Rawhide.
RELEASE_PENDING	No utilizado generalmente en Fedora. Utilizado por los flujos de trabajo Red Hat Enterprise Linux.)
UPSTREAM	Utilizado por los mantenedores para indicar que se espera que el error sea corregido upstream y naturalmente aplicado en Fedora Linux en una actualización subsiguiente.
WONTFIX	Utilizado por los mantenedores para indicar un error que no será corregido.
WORKSFORME	Utilizado por los mantenedores para indicar un error que no puede ser reproducido.

Priority and Severity

Severity

The Severity field is used to indicate the bug’s importance. 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.

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, use the High severity, not Urgent.

For most packages, most issues are likely to be of Medium severity. These are not hard and fast rules. Use your 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'.

Priority

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.

Want to help? Learn how to contribute to Fedora Docs ›