#use wml::debian::template title="Debian BTS — информация для разработчика" NOHEADER=yes NOCOPYRIGHT=true #include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc" #use wml::debian::translation-check translation="40a57e26c62893be7c80d82f1772999f68d51179" maintainer="Lev Lamberov"
Сначала сообщение об ошибке, которое отправил пользователь,
отправляется как обычное почтовое сообщение на адрес submit@bugs.debian.org
, сообщение должно содержать
строку Package
(дополнительную информацию см. в инструкции по отправке отчётов об
ошибках). Здесь ему присваивается номер,
затем происходит отправка подтверждения о его
получении пользователю, после чего оно пересылается в список
debian-bugs-dist
. Если строка
Package
содержит имя пакета, и для этого пакета известен сопровождающий, то
ему также будет отправлена копия этого сообщения.
Строка Subject
будет содержать добавление вида
Bug#
nnn:
, а поле Reply-To
будет включать как отправителя сообщения, так и адрес
nnn@bugs.debian.org
.
X-Debian-PR: quiet
Сообщения об ошибках Debian должны быть закрыты после исправления проблемы. Проблемы в пакетах могут считаться исправленными только после того, как пакет, в котором ошибка исправлена, попадает в архив Debian.
Обычно закрывать сообщение об ошибке должен тот, кто послал сообщение, или сопровождающий(ие) соответствующего пакета. Есть исключения из этого правила, например, если в сообщении об ошибке пакет не указан или указан общий псевдопакет. Также сообщение об ошибке может быть закрыто любым участником, если эта ошибка касается осиротевшего пакета, или если сопровождающий пакет забыл закрыть это сообщение об ошибке. Очень важно указать версию, в которой ошибка была исправлена. Если есть сомнения, не закрывайте ошибку, а сначала попросите совета в списке рассылки debian-devel.
Сообщения об ошибках должны закрываться путём отправки письма по
адресу nnn-done@bugs.debian.org
. Тело сообщения
должно содержать объяснение того, как исправлена ошибка.
При работе с сообщениями об ошибках, полученными от системы отслеживания
ошибок, для закрытия ошибки достаточно нажать кнопку Ответить (Reply) в своей
почтовой программе, а затем в поле Кому
(To) поставить
адрес nnn-done@bugs.debian.org
вместо
nnn@bugs.debian.org
(адрес nnn-close
является псевдонимом
адреса nnn-done
).
Когда вы закрываете ошибку, где применимо, проставляйте строку
Version
в псевдозаголовке
вашего сообщения, чтобы система отслеживания ошибок знала, какой из выпусков
пакета содержит исправление.
Человек, закрывший ошибку, человек, который отправил сообщение об этой
ошибке, и список рассылки debian-bugs-closed
будут извещены
об изменении состояния ошибки. Отправителю сообщения и в список рассылки
также будет направлено содержимое сообщения, посланного по адресу
nnn-done
.
После пересылки сообщения об ошибке, в поле Reply-To
системой
отслеживания ошибок будут включены адрес отправителя и адрес ошибки
(nnn@bugs.debian.org
). Пожалуйста, имейте в виду, что это
два разных адреса.
Любой разработчик, желающий ответить на сообщение об ошибке, просто
отвечает на сообщение, не меняя заголовок Reply-To
. Это
не приведёт к закрытию ошибки.
Не используйте ответить всем
(reply to all) или followup
в вашей почтовой программе, если вы не хотите исправить список
получателей вручную. В частности, смотрите, чтобы вы не отправляли последующие
сообщения на адрес submit@bugs.debian.org
.
Для того чтобы сообщения попали в систему отслеживания ошибок, они могут быть отправлены на следующие адреса:
@bugs.debian.org
— такие сообщения также высылаются
сопровождающему пакета и пересылаются на адрес debian-bugs-dist
,
но не тому, кто прислал отчёт об ошибке;
-submitter@bugs.debian.org
— эти сообщения также высылаются
тому, кто прислал отчёт об ошибке, и пересылаются на адрес debian-bugs-dist
,
но не сопровождающему пакета;
-maintonly@bugs.debian.org
— эти сообщения высылаются только
сопровождающему пакета, не тому, кто прислал отчёт об ошибке, и
не на адресdebian-bugs-dist
;
-quiet@bugs.debian.org
— эти сообщения лишь
добавляются в систему отслеживания ошибок (как и все приведенные выше) и
не высылаются больше никому.
Более подробно о том, как с помощью заголовков сообщения подавить отправку подтверждений или отправить по какому-то адресу копию сообщения об ошибке, см. инструкцию по составлению сообщений об ошибках.
Система отслеживания ошибок записывает уровень важности каждого сообщения
об ошибке. По умолчанию этот уровень имеет значение normal
, но
его можно перекрыть, явно указав уровень важности в строке Severity
в псевдозаголовке при отправке сообщения (см.
инструкции по созданию сообщений об ошибках),
или использовав команду severity
сервера управления запросами.
Уровни важности могут принимать следующие значения:
critical
grave
serious
mustили
required) или, по мнению сопровождающего пакета или человека, ответственного за выпуск в целом, не позволяет включить этот пакет в выпуск дистрибутива.
important
normal
minor
wishlist
Определённые уровни важности рассматриваются как блокирующие выпуск, что означает, что ошибка окажет влияние на возможность включения пакета в стабильный выпуск Debian. На данный момент это уровни critical, grave и serious. Полное описание правил установки этих уровней важности см. в списке блокирующих выпуск ошибок для следующей версии дистрибутива.
Каждая ошибка может иметь несколько меток из списка ниже. Эти метки отображаются на странице списка ошибок пакета, а также в полном журнале ошибки.
Метки могут быть установлены путём включения строки Tags
в
псевдозаголовке при отправке сообщения об ошибке (см.
инструкции по созданию сообщений об ошибках),
или при использовании команды tags
сервера управления запросами. Метки могут
разделяться запятыми, пробелами или и теми, и другими.
В настоящий момент метки могут принимать следующие значения:
patch
wontfix
moreinfo
Это не работает. Что не работает?
unreproducible
help
newcomer
.newcomer
pending
fixed
fixed.
security
upstream
confirmed
fixed-upstream
fixed-in-experimental
d-i
ipv6
lfs
l10n
a11y
ftbfs
Некоторая информация о метках, относящихся к конкретному дистрибутиву: метки -ignore позволяют игнорировать ошибку с целью разрешить пакету попасть в тестируемый дистрибутив. Метки выпуска указывают, что ошибка не должна попасть в архив до тех пор, пока она не будет исправлена во всех присвоенных выпусках. Метки выпуска также указывают, что данная ошибка есть только в заданных выпусках. (Другими словами, ошибки нет ни в одном выпуске, не присвоенном данной ошибке; в противном случае применяются обычные правила found/fixed.)
Метки выпуска не должны использоваться, если желаемого
эффекта можно достичь установкой правильной версии, так как
их требуется добавлять и удалять вручную. Если не уверены, что требуется
метка выпуска, обратитесь к администраторам Debian BTS
(
Когда разработчики пересылают сообщения об ошибках разработчикам первоначальных пакетов с исходными текстами (из которых и получаются пакеты Debian), они должны пометить это в системе отслеживания ошибок следующим образом:
Убедитесь, что поле Кому (To)
вашего сообщения авторам содержит
только адрес(а) автора(ов); поместите адрес отправителя сообщения об ошибке и адреса
nnn-forwarded@bugs.debian.org
и
nnn@bugs.debian.org
в поле Копия (CC)
.
Попросите автора сохранять при ответе адрес
nnn-forwarded@bugs.debian.org
в поле Копия (CC)
,
для того чтобы система отслеживания ошибок сохранила этот ответ вместе с первоначальным
сообщением об ошибке. Эти сообщения только сохраняются, но не пересылаются; чтобы послать
обычное сообщение, пошлите его также на
nnn@bugs.debian.org
.
Когда система отслеживания ошибок получает сообщение на адрес
nnn-forwarded
, она отмечает соответствующую ему
ошибку как пересланную на адрес(а) в поле Кому (To)
этого
сообщения, если только ошибка уже не помечена как пересланная.
Вы также можете управлять информацией переслано на
(forwarded to)
путём отправки сообщений на адрес
control@bugs.debian.org
.
В случаях, когда ответственным за исправление ошибки является человек, не являющийся сопровождающим пакета (например, если пакет сопровождается несколькими людьми), может быть полезно отметить это в системе отслеживания ошибок. С этой целью ошибка может иметь ответственного за исправление.
Ответственный за исправление может быть указан в поле Owner
псевдозаголовка сообщения об ошибке (см. \
инструкции по составлению сообщения об ошибке), или с помощью команд сервера управления owner
и
noowner
.
То, что сопровождающий пакета указан неправильно, обычно вызвано тем,
что сопровождающий недавно сменился, а новый сопровождающий ещё не
выложил новую версию пакета с изменённым управляющим полем
Maintainer
. Это будет исправлено при выкладывании пакета.
Кроме того, сопровождающие архива могут изменить запись о сопровождающем
пакета вручную, например если пересборка или новое выкладывание пакета
в скором времени не ожидается. По поводу таких изменений связывайтесь с
override-change@debian.org
.
Существует возможность переназначить сообщения об ошибках на другие пакеты;
переоткрыть ошибочно закрытые сообщения об ошибках; изменить указанную в
сообщениях информацию о пересылке (если есть); изменить уровень важности или
название сообщения; изменить ответственного за исправление ошибки; слить несколько
сообщений или, наоборот, разделить их; записать версии пакетов, в которых были найдены
ошибки и в которых они были исправлены. Всё это делается путём отправки
почтовых сообщений на control@bugs.debian.org
.
Формат этих сообщений описывается в другом
документе, доступном на сайте, или в файле bug-maint-mailcontrol.txt
.
Текстовую версию этого документа можно получить, написав слово help
в сообщении по адресу, указанному выше.
Система отслеживания ошибок даёт возможность отправителям ошибок, разработчикам и
другим заинтересованным третьим лицам подписаться на отдельные ошибки. Эта возможность
может быть использована желающими держать ошибку на виду, не подписываясь на
пакет через Систему отслеживания
пакетов Debian. Все сообщения, принятые
на nnn@bugs.debian.org
, посылаются подписчикам.
Подписаться на сообщения об ошибке можно, выслав электронное письмо на адрес
nnn-subscribe@bugs.debian.org
. Тема и текст письма
игнорируются. Когда сообщение обработается, пользователям придёт запрос на подтверждение,
на который они должны ответить, чтобы сообщения о данной ошибке начали приходить
к ним.
Можно также отписаться от сообщений об ошибке. Это можно сделать, послав письмо
на адрес nnn-unsubscribe@bugs.debian.org
. Тема и
текст письма вновь игнорируются. Пользователям придёт запрос на подтверждение,
на который они должны ответить, если они хотят отписаться от сообщений об ошибках.
По умолчанию адрес, на который будет произведена подписка, берётся из поля
From
. Если вы хотите подписать другой адрес, вы должны закодировать этот адрес
в запросе о подписке. Такой запрос должен иметь форму:
nnn-subscribe-
localpart=
example.com@bugs.debian.org
.
В этом примере запрашивается подписка адреса localpart@example.com
на ошибку nnn. Знак @
должен быть заменён на знак
=
. Подобным образом делается и отписка:
nnn-unsubscribe-
localpart=
example.com@bugs.debian.org
.
В обоих случаях тема и текст письма будут пересланы на адрес внутри запроса для подтверждения.
Сообщения, которые приходят на submit
или bugs
,
и у которых Тема (Subject) начинается с Bug#
nnn,
будут считаться посланными на адрес nnn@bugs.debian.org
.
Оба этих варианта оставлены для обратной совместимости при пересылке со
старых адресов и отлавливают последующие сообщения, отправляемые на
submit
по ошибке (например, при использовании Ответить всем (Reply to
All)).
Похожая схема функционирует и для адресов maintonly
,
done
, quiet
и forwarded
,
обрабатывая сообщения с соответствующей Темой (Subject) как посланные на
nnn-что-то@bugs.debian.org
.
Обычные сообщения, полученные по адресам forwarded
и
done
— т.е. не содержащие номер ошибки в
адресе — и без номера ошибки в Теме (Subject), будут отмечены как
хлам
(junk) и оставлены на несколько недель, но никак не будут обработаны.
X-Debian-PR: quiet
Она использовалась для того, чтобы система отслеживания ошибок не
делала дальнейшую пересылку сообщений, пришедших на адрес
debian-bugs
и у которых есть строка
X-Debian-PR: quiet
в реальном заголовке.
Теперь эта строка игнорируется. Отправляйте ваше сообщение
на адрес quiet
или nnn-quiet
(или
maintonly
или nnn-maintonly
).