---
authors:
  - 
    author: 'Dag-Erling Smørgrav'
  - 
    author: 'Hiten Pandya'
  - 
    author: 'Mark Linimon'
description: 'Эти рекомендации описывают рекомендуемые методы обработки отчётов о проблемах FreeBSD (PR — Problem Reports).'
tags: ["PR", "guideline", "bugs", "maintenance", "BugZilla", "FreeBSD"]
title: 'Руководство по обработке отчётов о проблемах с помощью Bugzilla'
trademarks: ["freebsd", "general"]
---

= Руководство по обработке отчётов о проблемах с помощью Bugzilla
:doctype: article
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:
:images-path: articles/pr-guidelines/

ifdef::env-beastie[]
ifdef::backend-html5[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
:imagesdir: ../../../images/{images-path}
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[.abstract-title]
Аннотация

Эти рекомендации описывают рекомендуемые методы работы с отчётами о проблемах FreeBSD (PR), отправленных в Bugzilla. Хотя они разработаны для команды сопровождения базы данных FreeBSD Bugzilla mailto:freebsd-bugbusters@FreeBSD.org[freebsd-bugbusters@FreeBSD.org], эти рекомендации следует соблюдать всем, кто работает с отчётами о проблемах FreeBSD.

'''

toc::[]

[[intro]]
== Введение

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

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

Примечание: в этой статье под термином «PR» понимается «отчёт о проблеме в Bugzilla» (Bugzilla Problem Report).

[[pr-lifecycle]]
== Жизненный цикл отчёта о проблеме

[NOTE]
====
Данный раздел устарел и переписывается по состоянию на январь 2026 года.
====
* Репортер отправляет отчёт об ошибке на веб-сайте. Ошибка находится в состоянии `Needs Triage`.
* Джейн Рэндом БагБастер подтверждает, что отчёт об ошибке содержит достаточно информации для её воспроизведения. Если нет, она взаимодействует с отправителем, чтобы получить необходимые данные. На этом этапе ошибке присваивается статус `Open`.
* Джо Рандом Коммиттер проявляет интерес к отчёту и назначает его себе, или Джейн Рандом БагБастер решает, что Джо лучше всего подходит для его решения и назначает его Джону. Ошибка должна быть переведена в состояние `In Discussion`.
* Джо кратко общается с инициатором (убедившись, что всё заносится в журнал аудита) и определяет причину проблемы.
* Джо засиживается всю ночь и создает патч, который, как он считает, исправляет проблему, и отправляет его в ответном сообщении, прося автора проверить его. Затем он устанавливает состояние отчёта в `Patch Ready`.
* После нескольких итераций и Джо, и автор патча остаются довольны результатом, и Джо фиксирует его в `-CURRENT` (или напрямую в `-STABLE`, если проблема отсутствует в `-CURRENT`), обязательно указывая в логе коммита ссылку на отчёт о проблеме (а также упоминая автора, если он предоставил патч целиком или частично) и, если необходимо, запускает отсчёт для MFC. Ошибка переводится в состояние `Needs MFC`.
* Если исправление не требует переноса в стабильную ветку (MFC), Джо закрывает отчёт с пометкой `Issue Resolved`.

[NOTE]
====
Многие отчётов отправляются с очень небольшим количеством информации о проблеме, а некоторые либо очень сложны для решения, либо лишь поверхностно затрагивают более крупную проблему; в таких случаях крайне важно получить всю необходимую информацию для решения проблемы. Если проблему внутри нельзя решить или она возникла снова, необходимо переоткрыть отчёт.
====

[[pr-states]]
== Состояние отчёта о проблеме

[NOTE]
====
Данный раздел устарел и переписывается по состоянию на январь 2026 года.
====
Важно обновлять состояние отчёта о проблеме при выполнении определённых действий. Состояние должно точно отражать текущий статус работы над проблемой.

.Небольшой пример, когда следует изменить состояние PR
[example]
====
Когда работа над PR завершена и ответственные разработчики уверены в исправлении, они отправят обновление в PR и изменят его состояние на «feedback». На этом этапе автор должен оценить исправление в своём контексте и ответить, была ли действительно устранена проблема.
====

Отчёт о проблеме может находиться в одном из следующих состояний:

open (открыто)::
Начальное состояние; проблема была указана и требует рассмотрения.

analyzed (проанализировано)::
Проблема была рассмотрена, и решение находится в разработке.

feedback (обратная связь)::
Дальнейшая работа требует дополнительной информации от инициатора или сообщества; возможно, информации относительно предлагаемого решения.

patched (исправлено)::
Патч был закоммичен, но что-то (MFC или, возможно, подтверждение от автора) ещё ожидается.

suspended (приостановлено)::
Проблема не решается из-за недостатка информации или ресурсов. Это отличный вариант для тех, кто ищет проект для реализации. Если проблему не удастся решить вовсе, она будет закрыта, а не приостановлена. Документационный проект использует статус «приостановлено» для пунктов списка пожеланий, требующих значительного объёма работы, на который у участников сейчас нет времени.

closed (закрыто)::
Проблемный отчёт закрывается, когда все изменения внедрены, задокументированы и протестированы, или когда исправление проблемы прекращено.

[NOTE]
====
Состояние "исправлено" (patched) напрямую связано с обратной связью, поэтому вы можете перейти сразу в состояние "закрыто", если автор не может протестировать исправление, и оно работает в ваших собственных тестах.
====

[[pr-types]]
== Типы отчётов о проблемах

При обработке отчётов о проблемах, будь вы разработчиком с прямым доступом к базе данных отчётов или участником, который просматривает базу данных и отправляет ответы с исправлениями, комментариями, предложениями или запросами на изменения, вы столкнетесь с несколькими различными типами PR.

* crossref:pr-guidelines[pr-unassigned, Неназначенные PR]
* crossref:pr-guidelines[pr-assigned, Назначенные PR]
* crossref:pr-guidelines[pr-dups, Дублирующие PR]
* crossref:pr-guidelines[pr-stale, Устаревшие PR]
* crossref:pr-guidelines[pr-misfiled-notpr, Несвязанные с ошибками PR]

Следующие разделы описывают, для чего используется каждый из различных типов PR, когда PR относится к одному из этих типов и как обрабатывается каждый из различных типов.

[[pr-unassigned]]
== Неназначенные PR

Когда поступают PR, они изначально назначаются на обобщённого исполнителя. Такие исполнители всегда начинаются с префикса `freebsd-`. Точное значение по умолчанию зависит от категории; в большинстве случаев оно соответствует определённому списку рассылки FreeBSD. Вот текущий список, с наиболее распространёнными значениями в начале:

[[default-assignees-common]]
.Назначенные по умолчанию исполнители — наиболее распространённые
[cols="1,1,1", options="header"]
|===
| Тип
| Категории
| Назначенный по умолчанию

|базовая система
|bin, conf, gnu, kern, misc
|freebsd-bugs

|специфичные от архитектуры
|arm, amd64, i386, mips
|freebsd-_arch_

|специфичные от архитектуры: powerpc
|powerpc64
|freebsd-ppc

|специфичные от архитектуры: riscv64
|riscv64
|freebsd-risc

|коллекция портов
|ports
|freebsd-ports-bugs

|документация, поставляемая с системой
|docs
|freebsd-doc

|веб-страницы FreeBSD (за исключением документации)
|Website
|freebsd-www
|===

[[default-assignees-other]]
.Назначенные по умолчанию - другие
[cols="1,1,1", options="header"]
|===
| Тип
| Категории
| Назначенный по умолчанию

|усилия по продвижению
|advocacy
|freebsd-advocacy

|проблемы с Java Virtual Machine(TM)
|java
|freebsd-java

|соответствие стандартам
|standards
|freebsd-standards

|библиотеки потоков
|threads
|freebsd-threads

|подсистема man:usb[4]
|usb
|freebsd-usb
|===

Не удивляйтесь, если обнаружите, что автор PR назначил ему неверную категорию. Если вы исправите категорию, не забудьте также исправить назначение. (В частности, наши авторы, похоже, с трудом понимают, что даже если их проблема проявилась на системе i386, она может быть общей для всей FreeBSD и, следовательно, более уместна в `kern`. Обратное, конечно, тоже верно.)

Некоторые PR могут быть переназначены с этих общих ответственных любым человеком. Существует несколько типов ответственных: специализированные почтовые рассылки, почтовые алиасы (используются для определённых элементов с ограниченным интересом) и отдельные лица.

Для назначений, которые являются списками рассылки, используйте полную форму при назначении (например, `freebsd-foo` вместо `foo`); это позволит избежать дублирования писем, отправляемых в список рассылки.

[NOTE]
====
Поскольку список людей, которые добровольно согласились быть ответственными по умолчанию за определённые типы PR, меняется так часто, эта информация гораздо лучше подходит для https://wiki.freebsd.org/AssigningPRs[вики FreeBSD].
====

Вот примерный список таких объектов; возможно, он не полный.

[[common-assignees-base]]
.Общие ответственные исполнители — базовая система
[cols="1,1,1,1", options="header"]
|===
| Тип
| Предполагаемая категория
| Предполагаемый исполнитель
| Тип Назначенного

|проблема, специфичная для архитектуры ARM(R)
|arm
|freebsd-arm
|список рассылки

|проблема, специфичная для архитектуры MIPS(R)
|kern
|freebsd-mips
|список рассылки

|проблема, специфичная для архитектуры PowerPC(R)
|kern
|freebsd-ppc
|список рассылки

|проблема с Advanced Configuration and Power Management (man:acpi[4])
|kern
|freebsd-acpi
|список рассылки

|проблема со встроенными или компактными системами FreeBSD (например, NanoBSD/PicoBSD/FreeBSD-arm)
|kern
|freebsd-embedded
|список рассылки

|проблема с драйверами FireWire(R)
|kern
|freebsd-firewire
|список рассылки

|проблема с кодом файловой системы
|kern
|freebsd-fs
|список рассылки

|проблема с подсистемой man:geom[4]
|kern
|freebsd-geom
|список рассылки

|проблема с подсистемой man:ipfw[4]
|kern
|freebsd-ipfw
|список рассылки

|подсистема man:jail[8]
|kern
|freebsd-jail
|список рассылки

|проблема с эмуляцией Linux(R) или SVR4
|kern
|freebsd-emulation
|список рассылки

|проблема со стеком сетевых протоколов
|kern
|freebsd-net
|список рассылки

|проблема с подсистемой man:pf[4]
|kern
|freebsd-pf
|список рассылки

|проблема с подсистемой man:scsi[4]
|kern
|freebsd-scsi
|список рассылки

|проблема с подсистемой man:sound[4]
|kern
|freebsd-multimedia
|список рассылки

|проблемы с подсистемой man:wlan[4] и беспроводными драйверами
|kern
|freebsd-wireless
|список рассылки

|проблема с man:sysinstall[8] или man:bsdinstall[8]
|bin
|freebsd-sysinstall
|список рассылки

|проблема со скриптами запуска системы (man:rc[8])
|kern
|freebsd-rc
|список рассылки

|проблема с функциональностью VIMAGE или VNET и связанным кодом
|kern
|freebsd-virtualization
|список рассылки

|проблема с эмуляцией Xen
|kern
|freebsd-xen
|список рассылки
|===

[[common-assignees-ports]]
.Общие ответственные исполнители — Коллекция портов
[cols="1,1,1,1", options="header"]
|===
| Тип
| Предполагаемая категория
| Предполагаемый исполнитель
| Тип Назначенного

|проблема с фреймворком портов (__не__ с отдельным портом!)
|ports
|portmgr
|alias

|порт, который поддерживается apache@FreeBSD.org
|ports
|apache
|список рассылки

|порт, который поддерживается autotools@FreeBSD.org
|ports
|autotools
|alias

|порт, который поддерживается doceng@FreeBSD.org
|ports
|doceng
|alias

|порт, который поддерживается eclipse@FreeBSD.org
|ports
|freebsd-eclipse
|список рассылки

|порт, который поддерживается gecko@FreeBSD.org
|ports
|gecko
|список рассылки

|порт, который поддерживается gnome@FreeBSD.org
|ports
|gnome
|список рассылки

|порт, который поддерживается hamradio@FreeBSD.org
|ports
|hamradio
|alias

|порт, который поддерживается haskell@FreeBSD.org
|ports
|haskell
|alias

|порт, который поддерживается java@FreeBSD.org
|ports
|freebsd-java
|список рассылки

|порт, который поддерживается kde@FreeBSD.org
|ports
|kde
|список рассылки

|порт, который поддерживается mono@FreeBSD.org
|ports
|mono
|список рассылки

|порт, который поддерживается office@FreeBSD.org
|ports
|freebsd-office
|список рассылки

|порт, который поддерживается perl@FreeBSD.org
|ports
|perl
|список рассылки

|порт, который поддерживается python@FreeBSD.org
|ports
|freebsd-python
|список рассылки

|порт, который поддерживается ruby@FreeBSD.org
|ports
|freebsd-ruby
|список рассылки

|порт, который поддерживается secteam@FreeBSD.org
|ports
|secteam
|alias

|порт, который поддерживается vbox@FreeBSD.org
|ports
|vbox
|alias

|порт, который поддерживается x11@FreeBSD.org
|ports
|freebsd-x11
|список рассылки
|===

PR портов, у которых есть сопровождающий, являющийся коммиттером портов, могут быть переназначены кем угодно (но обратите внимание, что не каждый коммиттер FreeBSD обязательно является коммиттером портов, поэтому нельзя ориентироваться только на адрес электронной почты.)

Для других PR (запросов на включение изменений) не перераспределяйте их между участниками (кроме себя), если вы не уверены, что назначенный участник действительно хочет отслеживать PR. Это поможет избежать ситуации, когда никто не занимается исправлением конкретной проблемы, потому что все предполагают, что назначенный участник уже работает над ней.

[[common-assignees-other]]
.Общие ответственные исполнители — Прочие
[cols="1,1,1,1", options="header"]
|===
| Тип
| Предполагаемая категория
| Предполагаемый исполнитель
| Тип Назначенного

|проблема с базой данных отчётов о проблемах
|bin
|bugmeister
|alias

|проблема с https://bugs.freebsd.org/submit/[веб-формой] Bugzilla.
|doc
|bugmeister
|alias
|===

[[pr-assigned]]
== Назначенные PR

Если в PR поле `responsible` содержит имя пользователя разработчика FreeBSD, это означает, что PR передан этому конкретному человеку для дальнейшей работы.

Назначенные PR не должны изменяться никем, кроме назначенного исполнителя или bugmeister. Если у вас есть комментарии, отправьте последующее сообщение. Если по какой-либо причине вы считаете, что PR должен изменить состояние или быть переназначен, отправьте сообщение назначенному исполнителю. Если назначенный исполнитель не ответит в течение двух недель, снимите назначение с PR и действуйте по своему усмотрению.

[[pr-dups]]
== Дублирующие PR

Если вы обнаружили несколько PR, описывающих одну и ту же проблему, выберите тот, который содержит наибольшее количество полезной информации, и закройте остальные, явно указав номер заменяющего PR. Если в нескольких PR содержится неперекрывающаяся полезная информация, добавьте всю недостающую информацию в один из них в виде последующего сообщения, включая ссылки на остальные PR; затем закройте другие PR (которые теперь полностью заменены).

[[pr-stale]]
== Устаревшие PR

PR считается устаревшим, если он не изменялся более шести месяцев. Для обработки устаревших PR примените следующую процедуру:

* Если PR содержит достаточно деталей, попробуйте воспроизвести проблему в `-CURRENT` и `-STABLE`. Если удастся, отправьте уточнение с вашими находками и попытайтесь найти, кому можно назначить задачу. Установите состояние "analyzed" (проанализировано), если это уместно.
* Если PR описывает проблему, которая, как вам известно, является результатом ошибки использования (неправильной конфигурации или иной), отправьте комментарий с объяснением, что сделал не так автор, затем закройте PR с причиной "Ошибка пользователя" или "Ошибка конфигурации".
* Если PR описывает ошибку, которая, как вам известно, была исправлена в обеих ветках `-CURRENT` и `-STABLE`, закройте его с сообщением, указывающим, когда она была исправлена в каждой из веток.
* Если PR описывает ошибку, которая, как вам известно, исправлена в `-CURRENT`, но не в `-STABLE`, попытайтесь выяснить, когда планируется перенос исправления (MFC), или найдите кого-то (возможно, себя?), кто сможет это сделать. Установите статус "patched" и назначьте задачу тому, кто займётся переносом исправления (MFC).
* В других случаях попросите автора подтвердить, сохраняется ли проблема в более новых версиях. Если автор не ответит в течение месяца, закройте PR с пометкой "Истекло время ожидания ответа".

[[pr-misfiled-notpr]]
== Не связанные с ошибками PR

Разработчики, которые сталкиваются с PR, которые, по их мнению, должны были быть отправлены в {freebsd-bugs} или какой-либо другой список, должны закрыть PR, сообщив отправителю в комментарии, почему это не является PR и куда следует отправить сообщение.

Адреса электронной почты, которые Bugzilla использует для входящих PR, были опубликованы как часть документации FreeBSD, объявлены и перечислены на веб-сайте. Это означает, что спамеры их обнаружили.

Всякий раз, когда вы закрываете один из этих PR, пожалуйста, выполните следующее:

* Установите компонент в значение `junk` (в разделе `Поддерживающие сервисы`).
* Установить Responsible в `nobody@FreeBSD.org`.
* Установите состояние `Issue Resolved`.

Установка категории в `junk` делает очевидным отсутствие полезного содержимого в PR и помогает уменьшить беспорядок в основных категориях.

[[references]]
== Для дальнейшего ознакомления

Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон.

* extref:{problem-reports}[Как писать отчёты о проблемах в FreeBSD]-рекомендации для авторов отчётов.