diff --git a/ru_RU.KOI8-R/articles/pr-guidelines/article.sgml b/ru_RU.KOI8-R/articles/pr-guidelines/article.sgml new file mode 100644 index 0000000000..190efd4f90 --- /dev/null +++ b/ru_RU.KOI8-R/articles/pr-guidelines/article.sgml @@ -0,0 +1,557 @@ + + + + + +%man; + +%mailing-lists; + +%freebsd; + +%trademarks; + + +]> + +
+ + + Рекомендации по работе с сообщениями о проблемах + + $FreeBSD$ + + + &tm-attrib.freebsd; + &tm-attrib.opengroup; + &tm-attrib.general; + + + + Это руководство описывает рекомендуемую практику обработки + сообщений об ошибках FreeBSD (Problem Reports - PR). Хотя эти + рекомендации предназначены для Группы поддержки базы данных сообщений + о проблемах FreeBSD (PR Database Maintenance Team) + freebsd-bugbusters@FreeBSD.org, им должны следовать все, + кто работает с этими сообщениями. + + + + + Dag-Erling + + Smørgrav + + + + Hiten + + Pandya + + + + + +
+ Введение + + GNATS является системой управления неисправностями (сообщениями об + ошибках), которая используется в Проекте FreeBSD. Так как тщательное + отслеживание заметных изъянов в программном обеспечении важно для + обеспечения качества FreeBSD, правильное использование GNATS необходимо + для дальнейшего развития Проекта. + + Доступ к GNATS даётся разработчикам FreeBSD, а также более широкому + сообществу. Для того, чтобы поддерживать целостность базы данных и + единства работы с пользователями, выработанные рекомендации покрывают + общие вопросы управления проблемами, такие, как написание отклика, + обработку уже закрытых вопросов и так далее. +
+ +
+ Жизненный цикл сообщения об ошибке + + + + Респондент посылает PR при помощи утилиты &man.send-pr.1; и + получает подтверждающее сообщение. + + + + Среднестатический коммиттер (Вася) проявляет интерес к PR и + назначает его самому себе, или другой любитель ошибок (Петя) решает, + что лучше всех с описанной проблемой справится именно Вася, и + назначает её Васе. + + + + Вася связывается с Респондентом (при этом вся переписка должна + фиксироваться) и выясняет причину появления проблемы. Затем он + документирует причину в журнале аудита, и переводит PR в состояние + analyzed (проанализировано). + + + + Вася проводит бессонную ночь и выпускает патч, которая, по его + мнению, решает означенную проблему, и затем посылает её ответом, + прося Респондента протестировать его. Затем он переводит PR в + состояние feedback. + + + + Через несколько таких итераций Вася и Респондент удавлетворяются + получающимся патчем, и Вася переносит его в дерево + -CURRENT (или непосредственно в + -STABLE, если этой проблемы в + -CURRENT не наблюдается), при этом при выполнении + коммита в сопутствующем сообщении делается ссылка на сообщение о + проблеме (а также упоминается Респондент, если он последний весь или + часть патча), и, если это нужно, начинается отсчёт для MFC. + + + + Если патчу не нужно выполнение MFC, Вася закрывает PR. + + + + Если патч требует выполнения MFC, Вася оставляет Сообщение о + проблеме в состоянии patched до выполнения операции + MFC, а затем закрывает его. + + + + + Многие PR присылаются с очень слабым описанием проблемы, а + некоторые из них либо очень сложно решить, либо являются вершиной + айсберга другой, более широкой проблемы; в этих случаях очень важно + получить всю информацию, требуемую для решения проблемы. Если + описанная проблема не может быть решена, или проявится снова, + необходимо повторно открыть PR. + + + + Адрес электронной почты может оказаться недоступным. + В этом случае ответьте на PR обычным образом и попросите Респондента + (в своём сообщении) предоставить рабочий адрес электронной почты. + Обычно это происходит в случаях использования &man.send-pr.1; в + системах с выключенной или неустановленной почтовой системой. + +
+ +
+ Состояние сообщений о проблемах + + При выполнении некоторых действий очень важно обновлять состояние + PR. Это состояние должно в точности отражать текущее состояние работы + над PR. + + + Маленький пример того, когда именно нужно менять + состояние PR + + Когда PR находится в работе и ответственный разработчик(и) + удовлетворён получающимся решением, то он отвечает на PR и меняет его + состояние на feedback. В этот момент Респондент должен + изучить исправление в своей ситуации и ответить, действительно ли был + устранён дефект. + + + Сообщение о проблеме может находится в одном из следующих + состояний: + + + + open + + + Начальное состояние; проблема была поставлена и её необходимо + рассмотреть. + + + + + analyzed + + + Проблема была рассмотрена, ищется её решение. + + + + + feedback + + + Дальнейшая работа требует дополнительной информации от + Респондента или сообщества; возможно помещение информации о + предлагаемом решении. + + + + + patched + + + Патч был перенесён в дерево исходных текстов, но + что-то (выполнение MFC или, возможно, подтверждение Респондента) + ещё требуется доделать. + + + + + suspended + + + Работа над проблемой была остановлена из-за отсутствия + информации или необходимых ресурсов. Это первый кандидат для + тех, кто ищет проект для работы над ним. Если проблема вообще не + может быть решена, она будет закрыта, а не приостановлена. Проект + создания документации использует suspended для + желательных нововведений, которые требуют + значительной работы, для которой ни у кого пока нет времени. + + + + + closed + + + Сообщение о проблеме было закрыто, когда все изменения были + перенесены, задокументированы и протестированы, либо когда + исправление проблемы было отвергнуто. + + + + + + Состояние patched напрямую связано с предлагаемыми + решениями, так что вы можете перейти сразу к состоянию + closed, если Респондент не может простестировать патч, + либо на ваших тестовых прогонах он работает. + +
+ +
+ Типы сообщений о проблемах + + При обработке сообщений об ошибках, либо в качестве разработчика, + имеющего непосредственный доступ к базе данных GNATS, либо в качестве + контрибутора, который просматривает базу данных и посылает свои + отклики с патчами, комментариями, пожеланиями или запросами на изменение, + вы будете иметь дело с несколькими различными типами PR. + + + + PR, которые уже кому-то + назначены. + + + + Повторы существующих PR. + + + + Заброшенные PR + + + + Некорректные PR + + + + В последующих разделах описывается, для чего предназначены те или + иные типы PR, условия отнесения PR к одному из этих типов, и какое + внимание нужно уделять каждому из этих типов. + +
+ Назначение PR + + Если в PR в заполненном поле responsible указано + имя разработчика FreeBSD, это значит, что PR взята этим человеком для + дальнейшей работы. + + Уже назначенное PR не должно трогаться никем, кроме того, кому эта + проблема назначена. Если у вас есть комментарии, напишите отклик. + Если по какой-то причине вы думаете, что PR должна изменить своё + состояние или её необходимо назначить кому-то другому, пошлите + сообщение тому, кто назначен ответственным. Если этот человек не + ответит в течение двух недель, смените назначение PR, а дальше + действуйте по своему усмотрению. +
+ +
+ Повторные PR + + Если вы обнаружите, что один и тот же вопрос описывается более чем + в одном PR, выберите то, что содержит максимальный объём полезной + информации и закройте все остальные, чётко указав номер более полного + PR. Если несколько PR содержат непересекающуюся информацию, перенесите + всю недостающую информацию в какой-либо отклик, включая ссылки на + остальные PR; затем закройте другие PR (которые теперь полностью + перекрыты). +
+ +
+ Просроченные PR + + PR считается простроченным, если оно не модифицировалось в течение + более полугода. При обработке просроченных PR испольщуйте следующую + процедуру: + + + + Если PR достаточно подробна, попытайтесь воспроизвести проблему + в дереве -CURRENT и -STABLE. + Если вам это удалось, напишите отклик, описывающий ваши изыскания + и попытайтесь найти кого-то, кому эту проблему можно назначить. + Если это подходит, измените состояние + на analyzed. + + + + Если PR описывает проблему, которая, как вы знаете, является + результатом неправильного использования (некорректная настройка или + что-то ещё), напишите отклик, в котором опишите, что автор + исходного сделал не так, а затем закройте PR с описанием + User error или Configuration + error. + + + + Если в PR описывается ошибка, которая, как вы знаете, была + исправлена как в -CURRENT, так и + -STABLE, закройте его с сообшением, указывающим + на даты исправлений в каждой ветке. + + + + Если PR описывает ошибку, которая, по вашим данным, была + исправлена в -CURRENT, но не в + -STABLE, попытайтесь выяснить, когда человек, + исправивший эту ошибку, планирует выполнить MFC, либо попробуйте + найти для этого кого-то ещё (может, это будете вы сами?). Измените + состояние сообщения на feedback и переназначьте его + кому-либо, кто будет делать MFC. + + + + В остальных случаях запросите у автора исходного сообщения + подтверждения того, что проблема всё ещё присутствует в новых + версиях. Если автор не отвечает в течение месяца, закройте PR с + пометкой Feedback timeout. + + +
+ +
+ Незаполненные PR + + GNATS требовательно подходит к формату присылаемых сообщений об + ошибках. Вот почему много PR заканчивают жизнь в состоянии + misfiled, если посылающий забыл заполнить поле или + ввёл неправильные данные в некоторые поля PR. Этот раздел поможет + предоставить основной объём необходимых подробностей для разработчиков + FreeBSD, который может помочь им закрыть или повторно заполнить + эти PR. + + Если система GNATS не может понять, что делать с сообщением об + ошибке, которое достигло базы данных, она определяет + gnats-admin в качестве ответственного за PR и + помещает сообщение в категорию pending. Теперь это + PR в состоянии misfiled и оно не будет появляться в + списках сообщений об ошибках, если только кто-то специально не запросит + перечень всех незаполненных PR. Если у вас есть доступ к машинам в + кластере FreeBSD, можете воспользоваться командой + query-pr для просмотра списка PR, которые были + некорректно сформированы: + + &prompt.user; query-pr -x -q -r gnats-admin + 52458 gnats-ad open serious medium Re: declaration clash f + 52510 gnats-ad open serious medium Re: lots of sockets in + 52557 gnats-ad open serious medium + 52570 gnats-ad open serious medium Jigdo maintainer update + + Как правило, PR вроде перечисленных выше оказываются незаполненными + по одной из следующих причин: + + + + Отклик на существующее PR, посланный по электронной почте, + имеет неверный формат заголовка Subject:. + + + + При заполнении шаблона &man.send-pr.1; посылающий забыл указать + правильное значение для категории или класса PR. + + + + Это не реальное PR, а какое-то случайное сообщение, посланное + на адрес bug-followup@freebsd.org или + freebsd-gnats-submit@freebsd.org. + + + +
+ Отклики неправильно оформлены как новые PR + + К наиболее массовой категории неправильно оформленных PR + относятся те, у которых неверна тема письма, и именно они на самом + деле требует самых больших усилий от разработчиков. Это не настоящие + PR, описывающие отдельные ошибки. Когда по одному из адресов, + который прослушивает GNATS на предмет обработки + входящих сообщений, принимается ответ на существуещее PR, то тема + ответа должна быть всегда в таком виде: + + Subject: Re: category/number: старая тема + + Большинство почтовых программ, когда вы отвечаете на оригинальное + почтовое сообщение с PR, будут добавлять часть + Re: . Часть + category/number:  является + соглашением, специфичным для GNATS, которое вы должны выполнить, + вручную поставив его в тему письма с откликом. + + Все разработчики FreeBSD, имеющие прямой доступ к базе данных + GNATS, могут регулярно проверять наличие таких PR и перемещать + заинтересовавшие их в отклики к оригинальному PR (послав корректный + отклик на сообщение об ошиюке на адрес + bug-followup@freebsd.org). Затем неправильно + оформленное PR может быть закрыто с примерно таким пояснением: + + Your problem report was misfiled. Please use the format +"Subject: category/number: original text" when following +up to older, existing PRs. I've added the relevant bits +from the body of this PR to kern/12345 + + Поиск по команде query-pr оригинального PR, + на которое отвечает неправильно оформленный отклик, легко выполняется + следующим образом: + + &prompt.user; query-pr -q -y "some text" + + После того, как вы обнаружили оригинальное PR и неправильно + оформленный отклик на него, воспользуйтесь параметром + команды query-pr для + сохранения полного текста всех относящихся к делу PR в файле формата + почтового ящика &unix;, то есть: + + &prompt.user; query-pr -F 52458 52474 > mbox + + Теперь вы можете использовать любую почтовую программу для + просмотра всех PR, которые вы сохранили в файле + mbox. Скопируйте текст всех неверно оформленных + PR в отклике на оригинальное сообщение о проблеме, и обязательно + включите правильный заголовок Subject:. После + этого закройте неверно оформленное PR. Когда вы закрываете такие PR, + помните, что автор получает оповещение по почте о том, что его PR + сменило состояние на closed. В пояснении обязательно + описывайте в подробностях, почему это состояние изменилось. Обычно + подойдёт примерно следующий текст: + + Followup to ports/45364 misfiled as a new PR. +This was misfiled because the subject didn't have the format: + + Re: ports/45364: ... + + В этом случае автор неправильно оформленного PR будет знать, + чего необходимо избегать при отправке отклика на существующее + PR. +
+ +
+ Некорректные PR с отсутствующими полями + + Ко второму типу неправильно оформленных PR обычно относят те, + что являются результатом забывчивости авторов, которые не заполнили + все необходимые поля при написании первоначального PR. + + Отсутствие или ошибочное задание полей category + или class может привести к появлению некорректного + сообщения. Разработчики могут использовать &man.edit-pr.1; для смены + значений категории или класса этих неправильно оформленных PR на + более подходящие и сохранить PR. + + Другой распространённой причиной появления неправильно + оформленных PR являются вопросы форматирования, квотирование, + изменение или удаление шаблона send-pr, как по + вине пользователя, редактирующего шаблон, так и почтовых программ, + которые проделывают странные вещи с обычными текстовыми сообщениями. + Это происходит не постоянно, и может быть исправлено программой + edit-pr; это требует некоторых усилий со стороны + разработчика, которые перевводит PR, однако в большинстве случаев + это можно сделать относительно легко. +
+ +
+ Неправильные PR, которые на самом деле не являются сообщениями + об ошибках + + Иногда пользователь желает сообщить об ошибке и посылает GNATS + по электронной почте обычное сообщение. Скрипты GNATS работает с + сообщениями об ошибках, которые форматированы при помощи шаблона + &man.send-pr.1;. Они не могут обрабатывать любые сообщения + электронной почты. Вот почему сообщения об ошибках, посылаемые на + адрес freebsd-gnats-submit@freebsd.org, должны + быть оформлены по шаблону команды send-pr, хотя + сообщения по электронной почте можно послать на &a.bugs;. + + Разработчики, которые видят PR, выглядящие так, будто они должны + были быть посланы в адрес &a.bugs.name; или какого-то другого + списка рассылки, должны закрыть PR, проинформировав его автора в + протоколе изменения состояния о причинах, по которых это не является + настоящим PR и куда следует посылать сообщения. + + Электронный адрес, который использует GNATS для приёма + поступающих PR, опубликован в документации к FreeBSD, объявлялся и + указан на Web-сайте. Это значит, что спамеры его увидели. Каждый + день несколько рекламных сообщений поступает в GNATS, которая + относит их к категории pending, пока кто-нибудь их не + пересмотрит. Закрытие любого из таких сообщений при помощи + &man.edit-pr.1; весьма раздражает, потому что GNATS отвечает автору, + а сейчас адрес отправителя спам-почты никогда не бывает настоящим. + Для каждого закрытого PR будут приходить сообщения о + невозможности доставки. + + На данный момент с установкой некоторых фильтров против спама, + проверяющих все добавления в базу данных GNATS, количество спама, + достигающего состояния pending, весьма мало. + + Все разработчики, имеющие доступ к машинам кластера FreeBSD.org, + приглашаются к проверке неправильно оформленных PR и немедленному + закрытию тех, что являются почтовым спамом. Когда вы закрываете + такое PR, хорошо бы заодно указать в качестве категории + junk. Ненужные PR не сохраняются, + так что перенос почтового спама в эту категорию ясно указывает на + то, что мы не собираемся его сохранять или тратить на него дисковое + пространство. +
+
+
+ +
+ Дополнительная литература + + Это перечень ресурсов, относящихся к качественному написанию и + обработке сообщений об ошибках. Несомненно, этот список не является + полным. + + + + Как писать + Сообщения об ошибках FreeBSD—руководство для авторов + PR. + + +
+