diff options
Diffstat (limited to 'documentation/content/ru/articles/pr-guidelines/_index.adoc')
| -rw-r--r-- | documentation/content/ru/articles/pr-guidelines/_index.adoc | 372 |
1 files changed, 141 insertions, 231 deletions
diff --git a/documentation/content/ru/articles/pr-guidelines/_index.adoc b/documentation/content/ru/articles/pr-guidelines/_index.adoc index 4ee096306b..10c764f08a 100644 --- a/documentation/content/ru/articles/pr-guidelines/_index.adoc +++ b/documentation/content/ru/articles/pr-guidelines/_index.adoc @@ -1,12 +1,16 @@ --- -title: Рекомендации по работе с сообщениями о проблемах authors: - - author: Dag-Erling Smørgrav - - author: Hiten Pandya -trademarks: ["freebsd", "opengroup", "general"] + - + author: 'Dag-Erling Smørgrav' + - + author: 'Hiten Pandya' +description: 'Эти рекомендации описывают рекомендуемые методы обработки отчётов о проблемах FreeBSD (PR — Problem Reports).' +tags: ["PR", "guideline", "bugs", "maintenance", "BugZilla", "FreeBSD"] +title: 'Руководство по обработке отчетов о проблемах' +trademarks: ["freebsd", "general"] --- -= Рекомендации по работе с сообщениями о проблемах += Руководство по обработке отчетов о проблемах :doctype: article :toc: macro :toclevels: 1 @@ -40,7 +44,7 @@ endif::[] [.abstract-title] Аннотация -Это руководство описывает рекомендуемую практику обработки сообщений об ошибках FreeBSD (Problem Reports - PR). Хотя эти рекомендации предназначены для Группы поддержки базы данных сообщений о проблемах FreeBSD (PR Database Maintenance Team) mailto:freebsd-bugbusters@FreeBSD.org[freebsd-bugbusters@FreeBSD.org], им должны следовать все, кто работает с этими сообщениями. +Эти рекомендации описывают рекомендуемые методы работы с отчетами о проблемах FreeBSD (PR). Хотя они разработаны для команды сопровождения базы данных PR FreeBSD mailto:freebsd-bugbusters@FreeBSD.org[freebsd-bugbusters@FreeBSD.org], эти рекомендации следует соблюдать всем, кто работает с PR FreeBSD. ''' @@ -49,102 +53,93 @@ toc::[] [[intro]] == Введение -GNATS является системой управления неисправностями (сообщениями об ошибках), которая используется в Проекте FreeBSD. Так как тщательное отслеживание заметных изъянов в программном обеспечении важно для обеспечения качества FreeBSD, правильное использование GNATS необходимо для дальнейшего развития Проекта. +Bugzilla — это система управления задачами, используемая проектом FreeBSD. Поскольку точный учёт неисправленных программных ошибок важен для качества FreeBSD, правильное использование данного ПО критически необходимо для развития проекта. -Доступ к GNATS даётся разработчикам FreeBSD, а также более широкому сообществу. Для того, чтобы поддерживать целостность базы данных и единства работы с пользователями, были выработаны рекомендации, покрывающие общие вопросы управления проблемами, такие, как написание отклика, обработку уже закрытых вопросов и так далее. +Доступ к Bugzilla предоставлен всему сообществу FreeBSD. Для поддержания согласованности в базе данных и обеспечения единообразного взаимодействия с пользователями были установлены руководящие принципы, охватывающие общие аспекты управления ошибками, такие как предоставление последующих действий, обработка запросов на закрытие и так далее. [[pr-lifecycle]] -== Жизненный цикл сообщения о проблеме +== Жизненный цикл отчета о проблеме -* Респондент посылает PR при помощи утилиты man:send-pr[1] и получает подтверждающее сообщение. -* Среднестатистический коммиттер (Вася) проявляет интерес к PR и назначает его самому себе, или другой любитель ошибок (Петя) решает, что лучше всех с описанной проблемой справится именно Вася, и назначает её Васе. -* Вася связывается с Респондентом (при этом вся переписка должна фиксироваться) и выясняет причину появления проблемы. Затем он документирует причину в журнале аудита, и переводит PR в состояние "analyzed" (проанализировано). -* Вася проводит бессонную ночь и выпускает патч, который, по его мнению, решает означенную проблему, и затем посылает её ответом, прося Респондента протестировать его. Затем он переводит PR в состояние "feedback". -* Через несколько таких итераций Вася и Респондент удовлетворяются получающимся патчем, и Вася переносит его в дерево `-CURRENT` (или непосредственно в `-STABLE`, если этой проблемы в `-CURRENT` не наблюдается), при этом при выполнении коммита в сопутствующем сообщении делается ссылка на сообщение о проблеме (а также упоминается Респондент, если он предоставил весь или часть патча), и, если это нужно, начинается отсчёт для MFC. -* Если патчу не нужно выполнение MFC, Вася закрывает PR. -* Если патч требует выполнения MFC, Вася оставляет Сообщение о проблеме в состоянии "patched" до выполнения операции MFC, а затем закрывает его. +* Репортер отправляет отчет об ошибке на веб-сайте. Ошибка находится в состоянии `Needs Triage`. +* Джейн Рэндом БагБастер подтверждает, что отчёт об ошибке содержит достаточно информации для её воспроизведения. Если нет, она взаимодействует с отправителем, чтобы получить необходимые данные. На этом этапе ошибке присваивается статус `Open`. +* Джо Рандом Коммиттер проявляет интерес к PR и назначает его себе, или Джейн Рандом БагБастер решает, что Джо лучше всего подходит для его решения и назначает PR Джону. Ошибка должна быть переведена в состояние `In Discussion`. +* Джо кратко общается с инициатором (убедившись, что всё заносится в журнал аудита) и определяет причину проблемы. +* Джо засиживается всю ночь и создает патч, который, как он считает, исправляет проблему, и отправляет его в ответном сообщении, прося автора PR проверить его. Затем он устанавливает состояние PR в `Patch Ready`. +* После нескольких итераций и Джо, и автор патча остаются довольны результатом, и Джо фиксирует его в `-CURRENT` (или напрямую в `-STABLE`, если проблема отсутствует в `-CURRENT`), обязательно указывая в логе коммита ссылку на отчёт о проблеме (а также упоминая автора, если он предоставил патч целиком или частично) и, если необходимо, запускает отсчёт для MFC. Ошибка переводится в состояние `Needs MFC`. +* Если исправление не требует переноса в стабильную ветку (MFC), Джо закрывает PR с пометкой `Issue Resolved`. [NOTE] ==== -Многие PR присылаются с очень слабым описанием проблемы, а некоторые из них либо очень сложно решить, либо являются вершиной айсберга другой, более широкой проблемы; в этих случаях очень важно получить всю информацию, требуемую для решения проблемы. Если описанная проблема не может быть решена, или проявится снова, необходимо повторно открыть PR. -==== - -[NOTE] -==== -Адрес "электронной почты" может оказаться недоступным. В этом случае ответьте на PR обычным образом и попросите Респондента (в своём сообщении) предоставить рабочий адрес электронной почты. Обычно это происходит в случаях использования man:send-pr[1] в системах с выключенной или неустановленной почтовой системой. +Многие PR отправляются с очень небольшим количеством информации о проблеме, а некоторые либо очень сложны для решения, либо лишь поверхностно затрагивают более крупную проблему; в таких случаях крайне важно получить всю необходимую информацию для решения проблемы. Если проблему внутри нельзя решить или она возникла снова, необходимо переоткрыть PR. ==== [[pr-states]] -== Состояние сообщений о проблемах +== Состояние отчета о проблеме -При выполнении некоторых действий очень важно обновлять состояние PR. Это состояние должно в точности отражать текущее состояние работы над PR. +Важно обновлять состояние PR при выполнении определённых действий. Состояние должно точно отражать текущий статус работы над PR. -.Маленький пример того, когда именно нужно менять состояние PR +.Небольшой пример, когда следует изменить состояние PR [example] ==== - -Когда PR находится в работе и ответственный разработчик(и) удовлетворён получающимся решением, то он отвечает на PR и меняет его состояние на "feedback". В этот момент Респондент должен изучить исправление в своей ситуации и ответить, действительно ли был устранён дефект. +Когда работа над PR завершена и ответственные разработчики уверены в исправлении, они отправят обновление в PR и изменят его состояние на «feedback». На этом этапе автор должен оценить исправление в своём контексте и ответить, была ли действительно устранена проблема. ==== -Сообщение о проблеме может находится в одном из следующих состояний: +Отчет о проблеме может находиться в одном из следующих состояний: -[.glosslist] -open:: - Начальное состояние; проблема была поставлена и её необходимо рассмотреть. +open (открыто):: +Начальное состояние; проблема была указана и требует рассмотрения. -analyzed:: - Проблема была рассмотрена, ищется её решение. +analyzed (проанализировано):: +Проблема была рассмотрена, и решение находится в разработке. -feedback:: - Дальнейшая работа требует дополнительной информации от Респондента или сообщества; возможно помещение информации о предлагаемом решении. +feedback (обратная связь):: +Дальнейшая работа требует дополнительной информации от инициатора или сообщества; возможно, информации относительно предлагаемого решения. -patched:: - Патч был перенесён в дерево исходных текстов, но что-то (выполнение MFC или, возможно, подтверждение Респондента) ещё требуется доделать. +patched (исправленно):: +Патч был закоммичен, но что-то (MFC или, возможно, подтверждение от автора) ещё ожидается. -suspended:: - Работа над проблемой была остановлена из-за отсутствия информации или необходимых ресурсов. Это первый кандидат для тех, кто ищет проект для работы над ним. Если проблема вообще не может быть решена, она будет закрыта, а не приостановлена. Проект создания документации использует suspended для желательных нововведений, которые требуют значительной работы, для которой ни у кого пока нет времени. +suspended (приостановлено):: +Проблема не решается из-за недостатка информации или ресурсов. Это отличный вариант для тех, кто ищет проект для реализации. Если проблему не удастся решить вовсе, она будет закрыта, а не приостановлена. Документационный проект использует статус «приостановлено» для пунктов списка пожеланий, требующих значительного объема работы, на который у участников сейчас нет времени. -repocopy (устаревшее):: - Решение проблемы зависит от завершения операции копирования репозитория (внутренние операции репозитория CVS). - -closed:: - Сообщение о проблеме было закрыто, когда все изменения были перенесены, задокументированы и протестированы, либо когда исправление проблемы было отвергнуто. +closed (закрыто):: +Проблемный отчет закрывается, когда все изменения внедрены, задокументированы и протестированы, или когда исправление проблемы прекращено. [NOTE] ==== -Состояние "patched" напрямую связано с предлагаемыми решениями, так что вы можете перейти сразу к состоянию "closed", если Респондент не может протестировать патч, либо на ваших тестовых прогонах он работает. +Состояние "исправлено" (patched) напрямую связано с обратной связью, поэтому вы можете перейти сразу в состояние "закрыто", если автор не может протестировать исправление, и оно работает в ваших собственных тестах. ==== [[pr-types]] -== Типы сообщений о проблемах +== Типы отчетов о проблемах -При обработке сообщений об ошибках, либо в качестве разработчика, имеющего непосредственный доступ к базе данных GNATS, либо в качестве контрибутора, который просматривает базу данных и посылает свои отклики с патчами, комментариями, пожеланиями или запросами на изменение, вы будете иметь дело с несколькими различными типами PR. +При обработке отчетов о проблемах, будь вы разработчиком с прямым доступом к базе данных отчетов или участником, который просматривает базу данных и отправляет ответы с исправлениями, комментариями, предложениями или запросами на изменения, вы столкнетесь с несколькими различными типами PR. -* <<pr-unassigned>> -* <<pr-assigned>> -* <<pr-dups>> -* <<pr-stale>> -* <<pr-misfiled>> +* 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, когда PR относится к одному из этих типов и как обрабатывается каждый из различных типов. [[pr-unassigned]] == Неназначенные PR -По прибытии сообщениям о проблемах устанавливаются общие назначения (generic assignee). Они всегда предваряются префиксом `freebsd-`. Точное название назначения (assignee) зависит от категории и в большинстве случаев оно соответствует определенному списку рассылки FreeBSD. Далее следует текущий перечень назначений (assignee), составленный в порядке от общих к частным: +Когда поступают PR, они изначально назначаются на обобщённого исполнителя. Такие исполнители всегда начинаются с префикса `freebsd-`. Точное значение по умолчанию зависит от категории; в большинстве случаев оно соответствует определённому списку рассылки FreeBSD. Вот текущий список, с наиболее распространёнными значениями в начале: + [[default-assignees-common]] -.Назначения по умолчанию - наиболее общие +.Назначенные по умолчанию исполнители — наиболее распространенные [cols="1,1,1", options="header"] |=== | Тип -| Категория -| Назначение по умолчанию +| Категории +| Назначенный по умолчанию |базовая система |bin, conf, gnu, kern, misc |freebsd-bugs -|специфичные для архитектуры +|специфичные от архитектуры |alpha, amd64, arm, i386, ia64, powerpc, sparc64 |freebsd-_arch_ @@ -156,20 +151,20 @@ closed:: |docs |freebsd-doc -|страницы сайта FreeBSD (за исключением документации) -|www +|веб-страницы FreeBSD (за исключением документации) +|Website |freebsd-www |=== [[default-assignees-other]] -.Назначения по умолчанию - остальные +.Назначенные по умолчанию - другие [cols="1,1,1", options="header"] |=== | Тип -| Категория -| Назначение по умолчанию +| Категории +| Назначенный по умолчанию -|в защиту FreeBSD (advocacy efforts) +|усилия по продвижению |advocacy |freebsd-advocacy @@ -181,7 +176,7 @@ closed:: |standards |freebsd-standards -|тредовые библиотеки +|библиотеки потоков |threads |freebsd-threads @@ -190,27 +185,27 @@ closed:: |freebsd-usb |=== -Не удивляйтесь, если обнаружите, что автор PR присвоил ему неправильную категорию. Если вы исправите категорию, то не забудьте также подправить и назначение. (В частности, для посылающих PR является трудностью понять, что если проблема возникает на системе с архитектурой i386, то она также может быть общей для всех архитектур FreeBSD, и поэтому более подходящей будет категория `kern`. Несомненно, обратное также справедливо). +Не удивляйтесь, если обнаружите, что автор PR назначил ему неверную категорию. Если вы исправите категорию, не забудьте также исправить назначение. (В частности, наши авторы, похоже, с трудом понимают, что даже если их проблема проявилась на системе i386, она может быть общей для всей FreeBSD и, следовательно, более уместна в `kern`. Обратное, конечно, тоже верно.) -Назначения некоторых PR могут быть переопределены из общих любым лицом, имеющим соответствующие привилегии. Существует несколько типов назначений: специализированные списки рассылки; почтовые алиасы (расширяемые в списки электронных адресов заинтересованных людей) и назначения отдельным лицам. +Некоторые PR могут быть переназначены с этих общих ответственных любым человеком. Существует несколько типов ответственных: специализированные почтовые рассылки, почтовые алиасы (используются для определённых элементов с ограниченным интересом) и отдельные лица. -Если назначением является список рассылки, пожалуйста, выполняя переназначение, используйте длинную форму (например, `freebsd-foo` вместо `foo`); благодаря этому сообщение, посылаемое в список рассылки, не будет дублироваться. +Для назначений, которые являются списками рассылки, используйте полную форму при назначении (например, `freebsd-foo` вместо `foo`); это позволит избежать дублирования писем, отправляемых в список рассылки. [NOTE] ==== -Так как список лиц добровольно согласившихся принимать назначения для некоторых типов PR изменяется часто, то наиболее подходящим местом для его размещения является http://wiki.freebsd.org/AssigningPRs[FreeBSD wiki]. +Поскольку список людей, которые добровольно согласились быть ответственными по умолчанию за определённые типы PR, меняется так часто, эта информация гораздо лучше подходит для https://wiki.freebsd.org/AssigningPRs[вики FreeBSD]. ==== -Ниже приведен (возможно, неполный) перечень назначений. +Вот примерный список таких объектов; возможно, он не полный. [[common-assignees-base]] -.Общие назначения - базовая система +.Общие ответственные исполнители — базовая система [cols="1,1,1,1", options="header"] |=== | Тип | Предполагаемая категория -| Предполагаемое назначение -| Тип назначения +| Предполагаемый исполнитель +| Тип Назначенного |проблема, специфичная для архитектуры ARM(R) |arm @@ -232,12 +227,12 @@ closed:: |freebsd-acpi |список рассылки -|проблема с драйверами ATM +|проблема с драйверами Asynchronous Transfer Mode (ATM) |kern |freebsd-atm |список рассылки -|проблема с встраиваемой системой или минимальным дистрибутивом FreeBSD (например, NanoBSD/PicoBSD/FreeBSD-arm) +|проблема со встроенными или компактными системами FreeBSD (например, NanoBSD/PicoBSD/FreeBSD-arm) |kern |freebsd-embedded |список рассылки @@ -247,7 +242,7 @@ closed:: |freebsd-firewire |список рассылки -|проблема в исходном коде файловой системы +|проблема с кодом файловой системы |kern |freebsd-fs |список рассылки @@ -262,7 +257,7 @@ closed:: |freebsd-ipfw |список рассылки -|проблема с драйверами ISDN +|проблема с драйверами Integrated Services Digital Network (ISDN) |kern |freebsd-isdn |список рассылки @@ -277,7 +272,7 @@ closed:: |freebsd-emulation |список рассылки -|проблема с сетевым стеком +|проблема со стеком сетевых протоколов |kern |freebsd-net |список рассылки @@ -292,27 +287,27 @@ closed:: |freebsd-scsi |список рассылки -|проблема с звуковой подсистемой (man:sound[4]) +|проблема с подсистемой man:sound[4] |kern |freebsd-multimedia |список рассылки -|проблема с подсистемой man:wlan[4] или с драйвером беспроводного устройства +|проблемы с подсистемой man:wlan[4] и беспроводными драйверами |kern |freebsd-wireless |список рассылки -|проблема с man:sysinstall[8] или с man:bsdinstall[8] +|проблема с man:sysinstall[8] или man:bsdinstall[8] |bin |freebsd-sysinstall |список рассылки -|проблема с системными стартовыми скриптами (man:rc[8]) +|проблема со скриптами запуска системы (man:rc[8]) |kern |freebsd-rc |список рассылки -|проблемы в работе VIMAGE, VNET, или проблемы в их коде +|проблема с функциональностью VIMAGE или VNET и связанным кодом |kern |freebsd-virtualization |список рассылки @@ -324,260 +319,175 @@ closed:: |=== [[common-assignees-ports]] -.Общие назначения - коллекция портов +.Общие ответственные исполнители — Коллекция портов [cols="1,1,1,1", options="header"] |=== | Тип | Предполагаемая категория -| Предполагаемое назначение -| Тип назначения +| Предполагаемый исполнитель +| Тип Назначенного -|проблема с инфраструктурой системы портов (__не__ с конкретным портом!) +|проблема с фреймворком портов (__не__ с отдельным портом!) |ports |portmgr -|алиас +|alias -|порт, у которого мейнтейнер apache@FreeBSD.org +|порт, который поддерживается apache@FreeBSD.org |ports |apache |список рассылки -|порт, у которого мейнтейнер autotools@FreeBSD.org +|порт, который поддерживается autotools@FreeBSD.org |ports |autotools -|алиас +|alias -|порт, у которого мейнтейнер doceng@FreeBSD.org +|порт, который поддерживается doceng@FreeBSD.org |ports |doceng -|алиас +|alias -|порт, у которого мейнтейнер eclipse@FreeBSD.org +|порт, который поддерживается eclipse@FreeBSD.org |ports |freebsd-eclipse |список рассылки -|порт, у которого мейнтейнер gecko@FreeBSD.org +|порт, который поддерживается gecko@FreeBSD.org |ports |gecko |список рассылки -|порт, у которого мейнтейнер gnome@FreeBSD.org +|порт, который поддерживается gnome@FreeBSD.org |ports |gnome |список рассылки -|порт, у которого мейнтейнер hamradio@FreeBSD.org +|порт, который поддерживается hamradio@FreeBSD.org |ports |hamradio -|алиас +|alias -|порт, у которого мейнтейнер haskell@FreeBSD.org +|порт, который поддерживается haskell@FreeBSD.org |ports |haskell -|алиас +|alias -|порт, у которого мейнтейнер java@FreeBSD.org +|порт, который поддерживается java@FreeBSD.org |ports |freebsd-java |список рассылки -|порт, у которого мейнтейнер kde@FreeBSD.org +|порт, который поддерживается kde@FreeBSD.org |ports |kde |список рассылки -|порт, у которого мейнтейнер mono@FreeBSD.org +|порт, который поддерживается mono@FreeBSD.org |ports |mono |список рассылки -|порт, у которого мейнтейнер office@FreeBSD.org +|порт, который поддерживается office@FreeBSD.org |ports |freebsd-office |список рассылки -|порт, у которого мейнтейнер perl@FreeBSD.org +|порт, который поддерживается perl@FreeBSD.org |ports |perl |список рассылки -|порт, у которого мейнтейнер python@FreeBSD.org +|порт, который поддерживается python@FreeBSD.org |ports |freebsd-python |список рассылки -|порт, у которого мейнтейнер ruby@FreeBSD.org +|порт, который поддерживается ruby@FreeBSD.org |ports |freebsd-ruby |список рассылки -|порт, у которого мейнтейнер secteam@FreeBSD.org +|порт, который поддерживается secteam@FreeBSD.org |ports |secteam -|алиас +|alias -|порт, у которого мейнтейнер box@FreeBSD.org +|порт, который поддерживается vbox@FreeBSD.org |ports |vbox -|алиас +|alias -|порт, у которого мейнтейнер x11@FreeBSD.org +|порт, который поддерживается x11@FreeBSD.org |ports |freebsd-x11 |список рассылки |=== -PR для портов, у которых мейнтейнером является коммиттер порта, могут быть переназначены любым лицом (только учтите, что не каждый FreeBSD коммиттер в обязательном порядке является коммиттером портов, поэтому вы не должны судить только по почтовому адресу). +PR портов, у которых есть сопровождающий, являющийся коммиттером портов, могут быть переназначены кем угодно (но обратите внимание, что не каждый коммиттер FreeBSD обязательно является коммиттером портов, поэтому нельзя ориентироваться только на адрес электронной почты.) + +Для других PR (запросов на включение изменений) не перераспределяйте их между участниками (кроме себя), если вы не уверены, что назначенный участник действительно хочет отслеживать PR. Это поможет избежать ситуации, когда никто не занимается исправлением конкретной проблемы, потому что все предполагают, что назначенный участник уже работает над ней. -Для остальных PR, пожалуйста не переназначайте их другим людям (за исключением себя), если вы не уверены, что человек действительно будет работать над ними. Это поможет избежать ситуации, когда решение проблемы игнорируется другими людьми, так как подразумевается, что некто уже над ней работает. [[common-assignees-other]] -.Общие назначения - остальные +.Общие ответственные исполнители — Прочие [cols="1,1,1,1", options="header"] |=== | Тип | Предполагаемая категория -| Предполагаемое назначение -| Тип назначения +| Предполагаемый исполнитель +| Тип Назначенного -|неполадки с самой GNATS(man:send-pr[1]) +|проблема с базой данных PR |bin |bugmeister -|алиас +|alias -|неполадки с веб интерфейсом GNATS -|www +|проблема с https://bugs.freebsd.org/submit/[веб-формой] Bugzilla. +|doc |bugmeister -|алиас +|alias |=== [[pr-assigned]] -== Назначение PR +== Назначенные PR -Если в PR в заполненном поле `responsible` указано имя разработчика FreeBSD, это значит, что PR взята этим человеком для дальнейшей работы. +Если в PR поле `responsible` содержит имя пользователя разработчика FreeBSD, это означает, что PR передан этому конкретному человеку для дальнейшей работы. -Уже назначенное PR не должно трогаться никем, кроме администраторов GNATS (bugmeister) и того, кому эта проблема назначена. Если у вас есть комментарии, напишите отклик. Если по какой-то причине вы думаете, что PR должна изменить своё состояние или её необходимо назначить кому-то другому, пошлите сообщение тому, кто назначен ответственным. Если этот человек не ответит в течение двух недель, смените назначение PR, а дальше действуйте по своему усмотрению. +Назначенные PR не должны изменяться никем, кроме назначенного исполнителя или bugmeister. Если у вас есть комментарии, отправьте последующее сообщение. Если по какой-либо причине вы считаете, что PR должен изменить состояние или быть переназначен, отправьте сообщение назначенному исполнителю. Если назначенный исполнитель не ответит в течение двух недель, снимите назначение с PR и действуйте по своему усмотрению. [[pr-dups]] -== Повторные PR +== Дублирующие PR -Если вы обнаружите, что один и тот же вопрос описывается более чем в одном PR, выберите то, что содержит максимальный объём полезной информации и закройте все остальные, чётко указав номер более полного PR. Если несколько PR содержат не пересекающуюся информацию, перенесите всю недостающую информацию в какой-либо отклик, включая ссылки на остальные PR; затем закройте другие PR (которые теперь полностью перекрыты). +Если вы обнаружили несколько PR, описывающих одну и ту же проблему, выберите тот, который содержит наибольшее количество полезной информации, и закройте остальные, явно указав номер заменяющего PR. Если в нескольких PR содержится неперекрывающаяся полезная информация, добавьте всю недостающую информацию в один из них в виде последующего сообщения, включая ссылки на остальные PR; затем закройте другие PR (которые теперь полностью заменены). [[pr-stale]] -== Просроченные PR - -PR считается простроченным, если оно не модифицировалось в течение более полугода. При обработке просроченных PR используйте следующую процедуру: - -* Если PR достаточно подробна, попытайтесь воспроизвести проблему в дереве `-CURRENT` и `-STABLE`. Если вам это удалось, напишите отклик, описывающий ваши изыскания и попытайтесь найти кого-то, кому эту проблему можно назначить. Если это подходит, измените состояние на "analyzed". -* Если PR описывает проблему, которая, как вы знаете, является результатом неправильного использования (некорректная настройка или что-то ещё), напишите отклик, в котором опишите, что автор исходного сделал не так, а затем закройте PR с описанием "User error" или "Configuration error". -* Если в PR описывается ошибка, которая, как вы знаете, была исправлена как в `-CURRENT`, так и `-STABLE`, закройте его с сообщением, указывающим на даты исправлений в каждой ветке. -* Если PR описывает ошибку, которая, по вашим данным, была исправлена в `-CURRENT`, но не в `-STABLE`, попытайтесь выяснить, когда человек, исправивший эту ошибку, планирует выполнить MFC, либо попробуйте найти для этого кого-то ещё (может, это будете вы сами?). Измените состояние сообщения на "patched" и переназначьте его кому-либо, кто будет делать MFC. -* В остальных случаях запросите у автора исходного сообщения подтверждения того, что проблема всё ещё присутствует в новых версиях. Если автор не отвечает в течение месяца, закройте PR с пометкой "Feedback timeout". - -[[pr-misfiled]] -== Незаполненные PR - -GNATS требовательно подходит к формату присылаемых сообщений об ошибках. Вот почему много PR заканчивают жизнь в состоянии "misfiled", если посылающий забыл заполнить поле или ввёл неправильные данные в некоторые поля PR. Этот раздел поможет предоставить основной объём необходимых подробностей для разработчиков FreeBSD, который может помочь им закрыть или повторно заполнить эти PR. - -Если система GNATS не может понять, что делать с сообщением об ошибке, которое достигло базы данных, она определяет `gnats-admin` в качестве ответственного за PR и помещает сообщение в категорию `pending`. Теперь это PR в состоянии "misfiled" и оно не будет появляться в списках сообщений об ошибках, если только кто-то специально не запросит перечень всех незаполненных PR. Если у вас есть доступ к машинам в кластере FreeBSD, можете воспользоваться командой `query-pr` для просмотра списка PR, которые были некорректно сформированы: - -[source,shell] -.... -% 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:`. -* Автор PR отправил копию (Cc:) в список рассылки, а кто-нибудь ответил на этот пост вместо сообщения, сформированного GNATS. В копии, отосланной в список рассылки, нету тега категория/PRномер. (Вот почему мы рекомендуем посылающим _не_ делать подобных движений). -* При заполнении шаблона man:send-pr[1] посылающий забыл указать правильное значение для категории или класса PR. -* При заполнении шаблона man:send-pr[1] посылающий установил значение поля Confidential в `yes`. (Так как мы позволяем каждому зеркалировать GNATS при помощи rsync, информация о PR-ах является общедоступной. Сообщения, касающиеся безопасности, не следует слать через GNATS, их необходимо отправлять на адрес команды офицеров безопасности). -* Это не реальное PR, а какое-то случайное сообщение, посланное на адрес mailto:bug-followup@FreeBSD.org[bug-followup@FreeBSD.org] или mailto:freebsd-gnats-submit@FreeBSD.org[freebsd-gnats-submit@FreeBSD.org]. - -[[pr-misfiled-followups]] -== Отклики неправильно оформлены как новые PR +== Устаревшие PR -К наиболее массовой категории неправильно оформленных PR относятся те, у которых неверна тема письма, и именно они на самом деле требует самых больших усилий от разработчиков. Это не настоящие PR, описывающие отдельные ошибки. Когда по одному из адресов, который "прослушивает" GNATS на предмет обработки входящих сообщений, принимается ответ на существующее PR, то тема ответа должна быть всегда в таком виде: +PR считается устаревшим, если он не изменялся более шести месяцев. Для обработки устаревших PR примените следующую процедуру: -[.programlisting] -.... -Subject: Re: category/number: старая тема -.... - -Большинство почтовых программ, когда вы отвечаете на оригинальное почтовое сообщение с PR, будут добавлять часть "`Re:`". Часть "`category/number:`" является соглашением, специфичным для GNATS, которое вы должны выполнить, вручную поставив его в тему письма с откликом. - -Все разработчики FreeBSD, имеющие прямой доступ к базе данных GNATS, могут регулярно проверять наличие таких PR и перемещать заинтересовавшие их в отклики к оригинальному PR (послав корректный отклик на сообщение об ошибке на адрес {bugfollowup}). Затем неправильно оформленное PR может быть закрыто с примерно таким пояснением: - -[.programlisting] -.... -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, на которое отвечает неправильно оформленный отклик, легко выполняется следующим образом: - -[source,shell] -.... -% query-pr -q -y "some text" -.... - -После того, как вы обнаружили оригинальное PR и неправильно оформленный отклик на него, воспользуйтесь параметром `-F` команды `query-pr` для сохранения полного текста всех относящихся к делу PR в файле формата почтового ящика UNIX(R), то есть: - -[source,shell] -.... -% query-pr -F 52458 52474 > mbox -.... - -Теперь вы можете использовать любую почтовую программу для просмотра всех PR, которые вы сохранили в файле [.filename]#mbox#. Скопируйте текст всех неверно оформленных PR в отклике на оригинальное сообщение о проблеме, и обязательно включите правильный заголовок `Subject:`. После этого закройте неверно оформленное PR. Когда вы закрываете такие PR, помните, что автор получает оповещение по почте о том, что его PR сменило состояние на "closed". В пояснении обязательно описывайте в подробностях, почему это состояние изменилось. Обычно подойдёт примерно следующий текст: - -[.programlisting] -.... -Followup to ports/45364 misfiled as a new PR. -This was misfiled because the subject did not have the format: - - Re: ports/45364: ... -.... - -В этом случае автор неправильно оформленного PR будет знать, чего необходимо избегать при отправке отклика на существующее PR. - -[[pr-misfiled-format]] -== Некорректные PR с отсутствующими полями - -Ко второму типу неправильно оформленных PR обычно относят те, что являются результатом забывчивости авторов, которые не заполнили все необходимые поля при написании первоначального PR. - -Отсутствие или ошибочное задание полей "category" или "class" может привести к появлению некорректного сообщения. Разработчики могут использовать man:edit-pr[1] для смены значений категории или класса этих неправильно оформленных PR на более подходящие и сохранить PR. - -Другой распространённой причиной появления неправильно оформленных PR являются вопросы форматирования, квотирование, изменение или удаление шаблона `send-pr`, как по вине пользователя, редактирующего шаблон, так и почтовых программ, которые проделывают странные вещи с обычными текстовыми сообщениями. Это изредка случается и может быть исправлено программой `edit-pr`, что требует некоторых усилий со стороны разработчика, корректирующего PR, однако в большинстве случаев это можно сделать относительно легко. +* Если PR содержит достаточно деталей, попробуйте воспроизвести проблему в `-CURRENT` и `-STABLE`. Если удастся, отправьте уточнение с вашими находками и попытайтесь найти, кому можно назначить задачу. Установите состояние "analyzed" (проанализировано), если это уместно. +* Если PR описывает проблему, которая, как вам известно, является результатом ошибки использования (неправильной конфигурации или иной), отправьте комментарий с объяснением, что сделал не так автор, затем закройте PR с причиной "Ошибка пользователя" или "Ошибка конфигурации". +* Если PR описывает ошибку, которая, как вам известно, была исправлена в обеих ветках `-CURRENT` и `-STABLE`, закройте его с сообщением, указывающим, когда она была исправлена в каждой из веток. +* Если PR описывает ошибку, которая, как вам известно, исправлена в `-CURRENT`, но не в `-STABLE`, попытайтесь выяснить, когда планируется перенос исправления (MFC), или найдите кого-то (возможно, себя?), кто сможет это сделать. Установите статус "patched" и назначьте задачу тому, кто займётся переносом исправления (MFC). +* В других случаях попросите автора подтвердить, сохраняется ли проблема в более новых версиях. Если автор не ответит в течение месяца, закройте PR с пометкой "Истекло время ожидания ответа". [[pr-misfiled-notpr]] -== Неправильные PR, которые на самом деле не являются сообщениями об ошибках - -Иногда пользователь желает сообщить об ошибке и посылает GNATS по электронной почте обычное сообщение. Скрипты GNATS работает с сообщениями об ошибках, которые форматированы при помощи шаблона man:send-pr[1]. Они не могут обрабатывать любые сообщения электронной почты. Вот почему сообщения об ошибках, посылаемые на адрес mailto:freebsd-gnats-submit@FreeBSD.org[freebsd-gnats-submit@FreeBSD.org], должны быть оформлены по шаблону команды `send-pr`, хотя сообщения по электронной почте можно послать на {freebsd-bugs}. - -Разработчики, которые видят PR, выглядящие так, будто они должны были быть посланы в адрес {freebsd-bugs} или какого-то другого списка рассылки, должны закрыть PR, проинформировав его автора в протоколе изменения состояния о причинах, по которых это не является настоящим PR и куда следует посылать сообщения. +== Не связанные с ошибками PR -Электронный адрес, который использует GNATS для приёма поступающих PR, опубликован в документации к FreeBSD, объявлялся и указан на Web-сайте. Это значит, что спамеры его увидели. Спам-сообщения, достигшие GNATS, немедленно определяются в категорию "pending" и остаются там до тех пор, пока кто-нибудь их не пересмотрит. Закрытие любого из таких сообщений при помощи man:edit-pr[1] весьма раздражает, потому что GNATS отвечает автору, а адрес отправителя спам-почты никогда не бывает настоящим. Для каждого закрытого PR будут приходить сообщения о невозможности доставки. +Разработчики, которые сталкиваются с PR, которые, по их мнению, должны были быть отправлены в {freebsd-bugs} или какой-либо другой список, должны закрыть PR, сообщив отправителю в комментарии, почему это не является PR и куда следует отправить сообщение. -На данный момент с установкой некоторых фильтров против спама, проверяющих все добавления в базу данных GNATS, количество спама, достигающего состояния "pending", весьма мало. +Адреса электронной почты, которые Bugzilla использует для входящих PR, были опубликованы как часть документации FreeBSD, объявлены и перечислены на веб-сайте. Это означает, что спамеры их обнаружили. -Все разработчики, имеющие доступ к машинам кластера FreeBSD.org, приглашаются к проверке неправильно оформленных PR и немедленному закрытию тех, что являются почтовым спамом. Когда вы закрываете такое PR, пожалуйста, сделайте следующее: +Всякий раз, когда вы закрываете один из этих PR, пожалуйста, выполните следующее: -* Выставьте Category в `junk`. -* Установите Confidential в `no`. -* Установите Responsible в `gnats-admin`. -* Смените State в `closed`. +* Установите компонент в значение `junk` (в разделе `Поддерживающие сервисы`). +* Установить Responsible в `nobody@FreeBSD.org`. +* Установите состояние `Issue Resolved`. -Для PR категории junk не выполняется резервное копирование, следовательно, перевод спам сообщений в эту категорию обозначает, что мы не желаем хранить их или тратить дисковое пространство на них. Если вы просто закрываете их без смены категории, они остаются как в главной базе, так и во всех копиях базы, зеркалируемых через CVSup. +Установка категории в `junk` делает очевидным отсутствие полезного содержимого в PR и помогает уменьшить беспорядок в основных категориях. [[references]] -== Дополнительная литература +== Для дальнейшего ознакомления -Это перечень ресурсов, относящихся к качественному написанию и обработке сообщений об ошибках. Несомненно, этот список не является полным. +Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон. -* extref:{problem-reports}[Как писать Сообщения об ошибках FreeBSD]-руководство для авторов PR. +* extref:{problem-reports}[Как писать отчёты о проблемах в FreeBSD]-рекомендации для авторов отчётов. |