openSUSE:Сообщить об ошибке FAQ

Ошибки

Сообщить об ошибке - FAQ - Поиск ошибок - Самые досадные ошибки - Тестирование - Bug Day

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 открытых ошибок.

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

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

Таким образом, каждый отправитель дефекта сам заинтересован в изменении статуса дефекта с NEEDINFO после того, как будут получены ответы на вопросы.

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

Пожалуйста отметьте, что дефекты, которые назначены на BNC-Screening-Team (главным образом YaST- и связаны с проблемами X11) первоначально или в течение процесса не должны менять статус с NEEDINFO на ASSIGNED отправителем или человеком требующим информации. Дело в том, что изменение этого статуса почти всегда включает переназначение, которое сделано посредством данной группы. Изменение этого статуса может заставить специфический дефект, появиться в неправильном листинге и, следовательно, может не прооперировано (переназначено) эффективно. Благодарю вас за понимание.

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

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

[TBD]

YaST

Эта секция была перемещена в openSUSE:Сообщить об ошибке 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.

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

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

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

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

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

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

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

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

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