Руководство по обработке отчетов о проблемах

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

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

Важно обновлять состояние PR при выполнении определённых действий. Состояние должно точно отражать текущий статус работы над PR.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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