Рабочий процесс статусов ошибок

В этом документе описаны рекомендуемые методы установки статуса в Bugzilla для ошибок и запросов на новые функции. Для трекеров предложений по изменениям используйте статус Bugzilla, описанный в Политике изменений.

Статусы

Изображение ниже представляет общую блок-схему для ошибок в типичном случае. Поток является двунаправленным: ошибка может вернуться к предыдущему статусу, если, например, предложенное исправление неполное.

Таблица ниже суммирует статусы. Более подробная информация, включая дополнительные ключевые слова, флаги и разрешения, приведена в следующих разделах.

Table 1. Bugzilla statuses
Status	Meaning
NEW	The default state. Generally indicates bug has not been actively investigated by the assignee.
ASSIGNED	Can be used by maintainers to indicate that the bug has been vetted and is assigned for work.
ON_DEV	Can be used by maintainers to indicate that work is actively in progress. This is especially useful if there exists a team of maintainers for a package.
POST	Indicates a fix is ready, but not applied. This is often used when a pull request is open upstream.
MODIFIED	Indicates a fix has been built in an update. Bodhi will set this status automatically when an update is created if the bug is associated with the update.
ON_QA	Indicates an update with a fix is in the testing repo. Bodhi will set this status automatically when an update reaches updates-testing if the bug is associated with the update.
VERIFIED	Indicates a bug has a confirmed fix in an update.
RELEASE_PENDING	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
CLOSED	Indicates the bug has been fixed or will not be fixed. The CLOSED status has different resolutions to indicate why the bug was closed. Bodhi will set this status automatically when an update reaches the updates repo if the bug is associated with the update.

Разрешения

Таблица ниже описывает разрешения, которые могут применяться к статусу CLOSED.

Table 2. Bugzilla resolutions
Resolution	Meaning
CANTFIX	Used by maintainers to indicate a bug that cannot be fixed.
CURRENTRELEASE	Indicates a bug reported in Branched prior to release and the fix is fixed for the final release.
DEFERRED	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
DUPLICATE	Indicates a bug is a duplicate of another.
EOL	Indicates a bug that was filed against a version that has reached End of Life.
ERRATA	Indicates a bug is fixed in a stable release.
FAILS_QA	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
INSUFFICIENT_DATA	Indicates that the bug reporter is unwilling or unable to provide sufficient information to diagnose or fix the bug.
NEXTRELEASE	Used by maintainers to indicate a bug that will only be fixed for later releases, not on the release reported.
NOTABUG	Indicates that the report is not a bug (e.g. is a hardware failure or a support question).
RAWHIDE	Indicates a bug is fixed in a Rawhide update.
RELEASE_PENDING	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
UPSTREAM	Used by maintainers to indicate that a bug is expected to be fixed upstream and naturally rolled into Fedora Linux in a subsequent update.
WONTFIX	Used by maintainers to indicate a bug that will not be fixed.
WORKSFORME	Used by maintainers to indicate a bug that cannot be reproduced.

Приоритет и серьёзность

Серьёзность

Поле Severity используется для указания важности ошибки. Значения для поля серьёзности должны назначаться в соответствии со следующими рекомендациями:

Urgent: ошибка делает всю систему непригодной для использования (или это ошибка безопасности, которая по определению является срочной)
High: ошибка делает рассматриваемую программу непригодной для использования, или это серьёзное нарушение рекомендаций по упаковке (проблема с лицензией, встроенная библиотека и т.д.)
Medium: реальная ошибка, которая затрудняет использование программы, по крайней мере часть программы доступна; возможно, существуют обходные пути
Low: всё остальное — косметические проблемы, пограничные случаи с необычными (нестандартными) конфигурациями и т.д.

Установка Urgent обычно не должна использоваться для ошибок, связанных с конкретным оборудованием: ошибка, которая затрагивает весь дистрибутив, но ограничена одним конкретным типом оборудования, обычно должна быть установлена как High. Например, если ошибка мешает корректной работе X.org на одном конкретном графическом чипсете, используйте серьёзность High, а не Urgent.

Для большинства пакетов большинство проблем, скорее всего, будут иметь серьёзность Medium. Это не жёсткие правила. Используйте своё лучшее суждение при установке поля серьёзности. Существуют очевидные случаи, требующие осмотрительности — например, ошибка, которая затрагивает не только программу, в которой она возникла, но и не всю 'систему'.

Приоритет

Поле Priority может использоваться по усмотрению сопровождающих для отслеживания порядка, в котором они хотели бы устранять ошибки в своих пакетах. Это может быть сделано с учётом установки серьёзности или любым другим методом, который выберет сопровождающий, на его усмотрение. Оно также может быть полностью проигнорировано, если соответствующий сопровождающий не желает его использовать. Никто, кроме сопровождающего или команды, ответственной за конкретную ошибку, не должен изменять эту настройку.

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