Как отправить Bug Report (Отчет об ошибке)

nobus	# 11 лет, 3 месяца назад (отредактировано 11 лет, 3 месяца назад)
Темы: 67 Сообщения: 1067 Участник с: 01 января 2010	Предлагается перевод следующей статьи. Я обратил внимание, что положение вещей может быть улучшено, если люди станут сообщать об ошибках в трекер ошибок Arch Linux (Arch Linux bug tracker). Вот несколько рекомендаций о том, что я лично хотел бы видеть в отчете об ошибке. Следование им сделает поиск и исправление ошибок меньшей работой для меня (и, как я полагаю, других разработчиков). 1. Проверьте, что об ошибке еще не было сообщено. Это включает в себя и проверку недавно закрытых сообщений об ошибках, так как ваша проблема может быть уже исправленной в процессе передачи на зеркала (mirrors). Это позволит предотвратить многочисленные сообщения об ошибке по одному и тому же вопросу (bug reports for the same issue), просто создающие больше работы для всех вовлеченных в этот процесс. 2. Предоставляйте всю необходимую информацию. В частности, не думайте, будто ошибка очевидна. Кажущаяся вам очевидной ошибка может не встречается в системах разработчиков, так что существенно необходима полная информация о связанных с ошибкой пакетах и подробная информация о том, как повторить ситуацию, в которой возникла ошибка. Мне всегда желательно увидеть как минимум точную версию связанного с ошибкой пакета (в том числе pkgver и pkgrel) и архитектуру, на которой происходит ошибка (i686 или x86_64). Не сообщайте просто о том, что это “текущая версия” пакета, так как такое сообщение окажется бесполезным за несколько дней в условиях rolling release дистрибутива. Чем больше точными вы будете в указании на конкретное обновление пакета, тем легче отследить изменения, который вызвали ошибку. 3. Привязывайте (свое сообщение) к значимой информации. Список из 50 пакетов, обновленных перед тем, как вы заметили эту ошибку, вероятно, содержит проблемный пакет, но в нем есть и много несвязанных (с ошибкой) обновлений. Сократите этот список как можно больше, прежде чем сообщать о проблеме выпуск. Чем больше время, потраченное мэйнтейнером пакета на фильтрацию (сообщения об ошибке) до только значимой информации, тем меньше времени на фактическое исправление ошибок. 4. Не сообщайте ошибки с помощью ссылок. Недостаточно предоставления ссылки на форум или список, который описывает ошибку. Вы все еще должны предоставлять подробную сводку информации. Это позволяет иметь всю информацию в одном месте, но также и предотвращает утрату информации об ошибке, если если ссылки окажутся “битыми”. 5. Один отчет об ошибке, одна проблема. Даже если у вас несколько проблем с данным пакетом, как правило, лучше создавать новое сообщение об ошибке по каждому вопросу. Это позволяет закрывать каждую ошибку как исправленную (поскольку невозможно исправить всё в одно и то же время) и предотвращает потерю данных сообщений о проблемах среди массы других. Исключением является ситуация, когда сообщается о многих незначительных проблемах, связанных с каким-либо пакетом, наряду с исправлением PKGBUILD, разом закрывающим их все. 6. Сообщайте об ошибке разработчиков (upstream bugs) самим разработчикам (upstream). Если ясно, что ошибка является ошибкой разработчиков кода, а не мейнтейнеров пакета, следует сообщать разработчикам. Было бы чудесно также сообщить на Arch bug tracker (если это ошибка, а не запрос об изменении функциональности (if it is a bug and not a feature request)) со ссылкой на сообщение авторам кода, так, чтобы мэйнтейнер пакета Arch смог отслеживать и применить исправление, когда оно будет доступно. Это не только сбережет мэйнтейнерам много времени (они имеют дело со многими ошибками), но также окажется полезным для разработчиков кода, которые услышат информацию об ошибке от человека, ее испытавшего. Исключением является glibc, не принимающий сообщения об ошибках от пользователей… 7. Отвечайте на все запросы. Это особенно важно для ошибок, которые не могут быть воспроизведены ответственными мэйнтейнерами Arch. Чем больше запросы остается без ответа, тем больше времени потребуется, чтобы отслеживать и исправить вашу ошибку. Если Вы более не можете повторить (ранее возникавшую) проблемы в силу, например, изменение аппаратного или программного обеспечения, сообщите нам и мы сможем закрыть сообщение об ошибке. 8. Не говорите “и у меня” (Do not “me too”). Существующие ссылки на голосование по сообщениям об ошибках вы можете использовать, чтобы показать, что такие проблемы возникли и у вас. Отправка сообщения “и у меня” в качестве комментария только захламляет трекер. Наконец, помните, что ошибка не существует, пока она не появится на трекере ошибок. Сообщения об ошибке в списки рассылки, на форумы, по IRC, Jabber и т.д. не считаются. Эти все средства хороши для отслеживания источника вашей ошибки, прежде чем сообщить о ней, но помните, что трекер ошибок имеет причины для своего существования. Оригинал: How To File A Bug Report Автор: Allan McRae Дата публикации оригинала: 12.05.2011 Говорила мама: "RTFM, сынок!"

# 11 лет, 3 месяца назад (отредактировано 11 лет, 3 месяца назад)

Сообщения: 1067

Участник с: 01 января 2010

Предлагается перевод следующей статьи.

Я обратил внимание, что положение вещей может быть улучшено, если люди станут сообщать об ошибках в трекер ошибок Arch Linux (Arch Linux bug tracker). Вот несколько рекомендаций о том, что я лично хотел бы видеть в отчете об ошибке. Следование им сделает поиск и исправление ошибок меньшей работой для меня (и, как я полагаю, других разработчиков).

1. Проверьте, что об ошибке еще не было сообщено. Это включает в себя и проверку недавно закрытых сообщений об ошибках, так как ваша проблема может быть уже исправленной в процессе передачи на зеркала (mirrors). Это позволит предотвратить многочисленные сообщения об ошибке по одному и тому же вопросу (bug reports for the same issue), просто создающие больше работы для всех вовлеченных в этот процесс.

2. Предоставляйте всю необходимую информацию. В частности, не думайте, будто ошибка очевидна. Кажущаяся вам очевидной ошибка может не встречается в системах разработчиков, так что существенно необходима полная информация о связанных с ошибкой пакетах и подробная информация о том, как повторить ситуацию, в которой возникла ошибка. Мне всегда желательно увидеть как минимум точную версию связанного с ошибкой пакета (в том числе pkgver и pkgrel) и архитектуру, на которой происходит ошибка (i686 или x86_64). Не сообщайте просто о том, что это “текущая версия” пакета, так как такое сообщение окажется бесполезным за несколько дней в условиях rolling release дистрибутива. Чем больше точными вы будете в указании на конкретное обновление пакета, тем легче отследить изменения, который вызвали ошибку.

3. Привязывайте (свое сообщение) к значимой информации. Список из 50 пакетов, обновленных перед тем, как вы заметили эту ошибку, вероятно, содержит проблемный пакет, но в нем есть и много несвязанных (с ошибкой) обновлений. Сократите этот список как можно больше, прежде чем сообщать о проблеме выпуск. Чем больше время, потраченное мэйнтейнером пакета на фильтрацию (сообщения об ошибке) до только значимой информации, тем меньше времени на фактическое исправление ошибок.

4. Не сообщайте ошибки с помощью ссылок. Недостаточно предоставления ссылки на форум или список, который описывает ошибку. Вы все еще должны предоставлять подробную сводку информации. Это позволяет иметь всю информацию в одном месте, но также и предотвращает утрату информации об ошибке, если если ссылки окажутся “битыми”.

5. Один отчет об ошибке, одна проблема. Даже если у вас несколько проблем с данным пакетом, как правило, лучше создавать новое сообщение об ошибке по каждому вопросу. Это позволяет закрывать каждую ошибку как исправленную (поскольку невозможно исправить всё в одно и то же время) и предотвращает потерю данных сообщений о проблемах среди массы других. Исключением является ситуация, когда сообщается о многих незначительных проблемах, связанных с каким-либо пакетом, наряду с исправлением PKGBUILD, разом закрывающим их все.

6. Сообщайте об ошибке разработчиков (upstream bugs) самим разработчикам (upstream). Если ясно, что ошибка является ошибкой разработчиков кода, а не мейнтейнеров пакета, следует сообщать разработчикам. Было бы чудесно также сообщить на Arch bug tracker (если это ошибка, а не запрос об изменении функциональности (if it is a bug and not a feature request)) со ссылкой на сообщение авторам кода, так, чтобы мэйнтейнер пакета Arch смог отслеживать и применить исправление, когда оно будет доступно. Это не только сбережет мэйнтейнерам много времени (они имеют дело со многими ошибками), но также окажется полезным для разработчиков кода, которые услышат информацию об ошибке от человека, ее испытавшего. Исключением является glibc, не принимающий сообщения об ошибках от пользователей…

7. Отвечайте на все запросы. Это особенно важно для ошибок, которые не могут быть воспроизведены ответственными мэйнтейнерами Arch. Чем больше запросы остается без ответа, тем больше времени потребуется, чтобы отслеживать и исправить вашу ошибку. Если Вы более не можете повторить (ранее возникавшую) проблемы в силу, например, изменение аппаратного или программного обеспечения, сообщите нам и мы сможем закрыть сообщение об ошибке.

8. Не говорите “и у меня” (Do not “me too”). Существующие ссылки на голосование по сообщениям об ошибках вы можете использовать, чтобы показать, что такие проблемы возникли и у вас. Отправка сообщения “и у меня” в качестве комментария только захламляет трекер.

Наконец, помните, что ошибка не существует, пока она не появится на трекере ошибок. Сообщения об ошибке в списки рассылки, на форумы, по IRC, Jabber и т.д. не считаются. Эти все средства хороши для отслеживания источника вашей ошибки, прежде чем сообщить о ней, но помните, что трекер ошибок имеет причины для своего существования.

Оригинал: How To File A Bug Report
Автор: Allan McRae
Дата публикации оригинала: 12.05.2011

Говорила мама: "RTFM, сынок!"

cucullus	# 11 лет, 3 месяца назад
Темы: 256 Сообщения: 3435 Участник с: 06 июня 2007	скорее “и у меня” ;) такие дела.

nobus	# 11 лет, 3 месяца назад
Темы: 67 Сообщения: 1067 Участник с: 01 января 2010	“И у меня” или “И я (поймал этот баг)”. Many thanks for cooperation. Говорила мама: "RTFM, сынок!"