1. Введение GNATS является системой управления неисправностями (сообщениями об ошибках), которая используется в Проекте FreeBSD. Так как тщательное отслеживание заметных изъянов в программном обеспечении важно для обеспечения качества FreeBSD, правильное использование GNATS необходимо для дальнейшего развития Проекта.
Доступ к GNATS даётся разработчикам FreeBSD, а также более широкому сообществу. Для того, чтобы поддерживать целостность базы данных и единства работы с пользователями, выработанные рекомендации покрывают общие вопросы управления проблемами, такие, как написание отклика, обработку уже закрытых вопросов и так далее.
2. Жизненный цикл сообщения об ошибке
Респондент посылает PR при помощи утилиты send-pr(1) и получает подтверждающее сообщение.
Среднестатический коммиттер (Вася) проявляет интерес к PR и назначает его самому себе, или другой любитель ошибок (Петя) решает, что лучше всех с описанной проблемой справится именно Вася, и назначает её Васе.
Вася связывается с Респондентом (при этом вся переписка должна фиксироваться) и выясняет причину появления проблемы. Затем он документирует причину в журнале аудита, и переводит PR в состояние ''analyzed'' (проанализировано).
Вася проводит бессонную ночь и выпускает патч, которая, по его мнению, решает означенную проблему, и затем посылает её ответом, прося Респондента протестировать его. Затем он переводит PR в состояние ''feedback''.
Через несколько таких итераций Вася и Респондент удовлетворяются получающимся патчем, и Вася переносит его в дерево -CURRENT (или непосредственно в -STABLE, если этой проблемы в -CURRENT не наблюдается), при этом при выполнении коммитта в сопутствующем сообщении делается ссылка на сообщение о проблеме (а также упоминается Респондент, если он последний весь или часть патча), и, если это нужно, начинается отсчёт для MFC.
Если патчу не нужно выполнение MFC, Вася закрывает PR.
Если патч требует выполнения MFC, Вася оставляет Сообщение о проблеме в состоянии ''patched'' до выполнения операции MFC, а затем закрывает его.
Замечание: Многие PR присылаются с очень слабым описанием проблемы, а некоторые из них либо очень сложно решить, либо являются вершиной айсберга другой, более широкой проблемы; в этих случаях очень важно получить всю информацию, требуемую для решения проблемы. Если описанная проблема не может быть решена, или проявится снова, необходимо повторно открыть PR.
Замечание: Адрес ''электронной почты'' может оказаться недоступным. В этом случае ответьте на PR обычным образом и попросите Респондента (в своём сообщении) предоставить рабочий адрес электронной почты. Обычно это происходит в случаях использования send-pr(1) в системах с выключенной или неустановленной почтовой системой.
3. Состояние сообщений о проблемах
При выполнении некоторых действий очень важно обновлять состояние PR. Это состояние должно в точности отражать текущее состояние работы над PR.
Пример 1. Маленький пример того, когда именно нужно менять состояние PR
Когда PR находится в работе и ответственный разработчик(и) удовлетворён получающимся решением, то он отвечает на PR и меняет его состояние на ''feedback''. В этот момент Респондент должен изучить исправление в своей ситуации и ответить, действительно ли был устранён дефект.
Сообщение о проблеме может находится в одном из следующих состояний:
open
Начальное состояние; проблема была поставлена и её необходимо рассмотреть.
analyzed
Проблема была рассмотрена, ищется её решение.
feedback
Дальнейшая работа требует дополнительной информации от Респондента или сообщества; возможно помещение информации о предлагаемом решении.
patched
Патч был перенесён в дерево исходных текстов, но что-то (выполнение MFC или, возможно, подтверждение Респондента) ещё требуется доделать.
suspended
Работа над проблемой была остановлена из-за отсутствия информации или необходимых ресурсов. Это первый кандидат для тех, кто ищет проект для работы над ним. Если проблема вообще не может быть решена, она будет закрыта, а не приостановлена. Проект создания документации использует ''suspended'' для ''желательных'' нововведений, которые требуют значительной работы, для которой ни у кого пока нет времени.
closed
Сообщение о проблеме было закрыто, когда все изменения были перенесены, задокументированы и протестированы, либо когда исправление проблемы было отвергнуто.
Замечание: Состояние ''patched'' напрямую связано с предлагаемыми решениями, так что вы можете перейти сразу к состоянию ''closed'', если Респондент не может протестировать патч, либо на ваших тестовых прогонах он работает.
4. Типы сообщений о проблемах
При обработке сообщений об ошибках, либо в качестве разработчика, имеющего непосредственный доступ к базе данных GNATS, либо в качестве контрибутора, который просматривает базу данных и посылает свои отклики с патчами, комментариями, пожеланиями или запросами на изменение, вы будете иметь дело с несколькими различными типами PR.
PR, которые уже кому-то назначены.
Повторы существующих PR.
Заброшенные PR
Некорректные PR
В последующих разделах описывается, для чего предназначены те или иные типы PR, условия отнесения PR к одному из этих типов, и какое внимание нужно уделять каждому из этих типов.
4.1. Назначение PR
Если в PR в заполненном поле responsible указано имя разработчика FreeBSD, это значит, что PR взята этим человеком для дальнейшей работы.
Уже назначенное PR не должно трогаться никем, кроме того, кому эта проблема назначена. Если у вас есть комментарии, напишите отклик. Если по какой-то причине вы думаете, что PR должна изменить своё состояние или её необходимо назначить кому-то другому, пошлите сообщение тому, кто назначен ответственным. Если этот человек не ответит в течение двух недель, смените назначение PR, а дальше действуйте по своему усмотрению.
4.2. Повторные PR
Если вы обнаружите, что один и тот же вопрос описывается более чем в одном PR, выберите то, что содержит максимальный объём полезной информации и закройте все остальные, чётко указав номер более полного PR. Если несколько PR содержат не пересекающуюся информацию, перенесите всю недостающую информацию в какой-либо отклик, включая ссылки на остальные PR; затем закройте другие PR (которые теперь полностью перекрыты).
4.3. Просроченные PR
PR считается простроченным, если оно не модифицировалось в течение более полугода. При обработке просроченных PR используйте следующую процедуру:
Если PR достаточно подробна, попытайтесь воспроизвести проблему в дереве -CURRENT и -STABLE. Если вам это удалось, напишите отклик, описывающий ваши изыскания и попытайтесь найти кого-то, кому эту проблему можно назначить. Если это подходит, измените состояние на ''analyzed''.
Если PR описывает проблему, которая, как вы знаете, является результатом неправильного использования (некорректная настройка или что-то ещё), напишите отклик, в котором опишите, что автор исходного сделал не так, а затем закройте PR с описанием ''User error'' или ''Configuration error''.
Если в PR описывается ошибка, которая, как вы знаете, была исправлена как в -CURRENT, так и -STABLE, закройте его с сообщением, указывающим на даты исправлений в каждой ветке.
