Bug Reporting FAQ

Материал из openSUSE.

Эта статья содержит фрагменты на иностранном языке . Вы можете помочь проекту, переведя её до конца.

Bugzilla

Основные правила регистрации ошибок

Этот документ описывает как использовать bugzilla на bugzilla.novell.com.

Какие поля должны быть заполнены при регистрации ошибки? Что я могу изменять, а что нет?

• Component: (Компонент системы)
  Замечание: Не все ошибки, возникающие в процессе установки относятся к YaST, это могут быть ошибки ядра или других приложений.
• Platform: (Платформа)
  Используйте “all" если вы считаете что данная ошибка не зависит от платформы, в противном случае указывайте свою платформу.
• Summary: (Pезюме)
  Люди, читающие резюме должны четко понять что происходит, какого рода эта ошибка.
• Bug description: (Описание ошибки)
  Опишите все детали возникновения ошибки. Не следует ссылаться на резюме (например, See Summary), поскольку резюме может быть изменено.
• How to Reproduce?: (Как воспроизводить?)
  Этот пункт настолько важен, что заслуживает отдельного описания: см. Вопрос: 1.1.5
• Severity: (Серьезность)
  Правильно оценивайте важность ошибки. Используйте обозначение “blocker" только в том случае, если Вы считает что выпуск продукта с данной ошибкой невозможен.
• Оставшиеся поля
  Оставшиеся поля лучше всего оставить как есть.

Получу ли я какой-либо ответ после сообщения об ошибке?

Да, если Ваши персональные данные не были изменены, Вы будете информированы обо всех изменениях по электронной почте.

Какие поля я должен изменять, а какие нет?

Как не разработчик Вы имеете право добавлять коментарии или добавлять себя в СС. Если ошибка находится в состоянии “NEEDINFO" не забудьте перевести ее в статус “ASSIGNED" после предоставления всей необходимой информации.

Что делать если такая же или подобная ошибка зарегистрирована для более поздней версии SUSE Linux?

Я предлагаю поменять версию пакета (программы) и добавить комментарий вида "This bug was reported for SUSE Linux x.y and still fails for SUSE Linux u.v. I'm adjusting the version". Если ошибка уже закрыта, Вы должны повторно открыть её.

Почему люди рассердились на меня за то, что я в поле "how to reproduce" указал "Install SUSE x.y-Beta-z".

Потому что это абсолютно бесполезная информация. Она никоим образом не поможет воспроизвести ошибку. Мы можем сказать, что это ошибка установки, поскольку Вы выбрали соответствующий компонент в Bugzilla , и мы можем сказать, что релиз, который Вы установили - следующий за этим.

То что мы действительно должны знать - это что Вы сделали, и как Вы это сделали. Например: "boot from CD1, select "Installation", select language "Klingon", leave the installation settings as they are, confirm installation, watch as your hard disk goes up in flames."

И, поверьте, это не придирки к мелочам. Мы имеем огромное количество инсталляционных настроек и массу путей установки. Потребуется огромное количество времени для того что бы восстановить Вашу последовательность действий из лог файла. Вы обладаете уже готовой информаций, введите ее в это поле.

Конечно, мы не требуем слишком глубокого уровня детализации ошибки, когда Вы сообщаете об ошибке в тексте помощи, в одном из заключительных этапов конфигурации аппаратных средств - но в описании последовательности действий, приводящей к ошибке, мы действительно нуждаемся.

В описании ошибки я написал "see subject" и получил неадекватный, на мой взгляд, ответ. Но ведь мой subject действительно все объясняет! Разве это не придирки к оформлению ошибки?

Нет, нисколько.

Subject изменяется все время. Проблема, о которой Вы сообщили, могла быть только вершиной айсберга - реальная проблема может быть совершенно в другом месте, и уточнение места возникновения ошибки приведет к тому, что Ваш первоначальный Subject будет потерян. Таким образом, должно быть достаточно очевидно, что Subject не является удачным местом для хранения сообщения об ошибке.

К тому же, это плохой стиль - свалить все виды информации в subject, а потом сослаться на subject. Это банальная лень. Достаточно один раз должным образом заполнить все необходимые поля и людям, работающим с ошибкой, не придется искать необходимую информацию снова и снова.

Ко всему прочему: Subject должен быть кратким, а описание ошибки настолько полным, насколько это необходимо.

Статус ошибки NEEDINFO

Что означает статус ошибки NEEDINFO и что необходимо с ним делать?

NEEDINFO означает, что человек, работающий над этой ошибкой, нуждается в дополнительной информации, как правило от человека, зарегистрировавшего ошибку.

Если зарегистрированная вами ошибка переведена в статус NEEDINFO, просмотрите последние комментарии на предмет вопросов или запросов дополнительной информации (например, логов и т.д.). Обнаружив такой комментарий, пожалуйста, ответьте на вопросы или предоставьте необходимую информацию и поменяйте статус ошибки на ASSIGNED - кликните на Accept bug (изменить статус на ASSIGNED) на соответствующей странице Bugzilla.

Разве я не становлюсь владельцем ошибки, когда меняю статус с NEEDINFO на ASSIGNED?

Нет, владелец ошибки остается прежним, меняется только статус. Вы можете спокойно менять статус без опасений стать владельцем ошибки.

Почему так важно менять статус ошибки с NEEDINFO до ASSIGNED? Разве это не должен делать владелец ошибки?

Нет, это зона ответственности отвечающего на вопросы или предоставляющего необходимую информацию.

Владельцы ошибок используют статус NEEDINFO, чтобы эффективнее работать с действительно актуальными ошибками (чей статус установлен в ASSIGNED, NEW или REOPENED) , или для ошибок, отмеченных лишь однажды, чтобы не пропустить важной информации - ошибки со статусом NEEDINFO не указываются в их to-do list открытых ошибок.

This is why it is important that the bug status is set away from NEEDINFO to some other status - the bug owner might overlook the mail Bugzilla sends automatically for comment added to a bug, and then this bug might remain in status NEEDINFO for an indefinite period of time.

Our maintainers receive so many generated mails that at peak times (like during a Beta phase) they cannot reasonably react to each one individually, so at a certain point they have to resort to bug status lists - and then chances are that it is overlooked that some requested information is now available and work on a bug can resume.

So it is in the own interest of each bug reporter to change the bug status away from NEEDINFO after the questions are answered.

Of course, sometimes you can be lucky and the bug owner realizes that the requested information is now available and sets the bug status to ASSIGNED himself, but relying on luck is usually not a good tactic.

Please note that bugs which are assigned to the BNC-Screening-Team (mainly YaST- and X11-related problems) initially or during the process should not be set from NEEDINFO to ASSIGNED by the reporter or the person the information was requested from. This is because a change of this status almost always involves a reassignment which is done by this team. Changing this status might cause the specific bug to appear on the wrong listing and might therefore be not handled (reassigned) efficiently. Thank you for taking this into account.

Статусы ошибок VERIFIED / CLOSED

Должен ли я изменять статус ошибки на VERIFIED или CLOSE если я вижу, что проблема решена в новой версии ПО или обновлении?

[TBD]

YaST

Эта секция была перемещена в Bugs/YaST

Ошибки ядра

Эта секция была перемещена в Bugs/Kernel

Ошибки документации SUSE Linux

Сообщайте об ошибках документации SUSE Linux в Bugzilla (компонент: "Documentation"), а так же в Список опечаток в документации SUSE Linux 10.0, Список опечаток в документации SUSE Linux 10.1, Список опечаток в документации openSUSE 10.2.

Бета - тестирование

Я бы хотел участвовать в бета тестировании SUSE Linux. С кем мне связаться?

openSUSE - это открытая система. Достаточно подписаться на рассылку openSUSE Project Mailing Lists и сообщать о найденных ошибках как описано здесь Submit a Bug.

Я бы хотел участвовать в бета-тестировании других продуктов, например SLES или SLED. К кому мне обратиться?

Не все программы имеют бета версию, но, если бета действительно существует, она может находиться здесь: The Novell Beta Program.

Какого рода обратную связь вы ожидаете?

Мы будем рады любым отзывам, как положительным, так и отрицательным, а также ждем предложения по усовершенствованию продукта.

Положительная обратная связь: мы будем рады услышать о том, что система успешно установилась и работает, что определенные области системы были успешно протестированы и не содержат ошибок. Пожалуйста, напишите об этом в рассылку mailto:openSUSE@opensuse.org. Все положительные отзывы фиксируются в testdb.

Отрицательная обратная связь: для регистрации всех проблем, с которыми вы сталкиваетесь по мере использования продукта, мы используем Bugzilla. Пожалуйста, создавайте отдельное сообщение об ошибке для каждой проблемы, которую вы нашли. Перед регистрацией ошибки ознакомьтесь с соответствующими разделами данного ЧАВО.

Мы будем рады услышать ваши идеи по улучшению продукта. Обычно их называют feature requests. Для регистрации этих идей используются специальные страницы Package Wishlist и Feature Wishlist.

Что такое betatestdb.suse.de?

Это инструмент, позволяющий посмотреть какие пакеты прошли бета тестирование и каков его результат. Betatestdb позволяет получать не только отрицательную обратную связь (что-то сломалось) через Bagzilla, но и положительную (пакет устойчив и корректно работает).

Betatestdb хранит детальные тесткейсы для большого числа пакетов. Тесткейсы описывают последовательность действий для проверки той или иной функциональности проверяемого пакета. Пожалуйста, следуйте этим инструкциям при тестировании и занесите результаты в betatestdb.

Note: Для наиболее удобного просмотра и поиска пакетов, мы рассортировали их по категориям.