Часто задаваемые вопросы по Bugzilla

From The Document Foundation Wiki
< QA‎ | Bugzilla‎ | FAQ
Jump to: navigation, search


Эта страница посвящена часто задеваемым вопросам по Bugzilla!

Для вопросов на общие темы о QA смотри ЧаВо по контролю качества.

Contents

Как подать запрос на расширение инфраструктуры для Bugzilla

Примечание: LibreOffice мигрирует в отдельный Bugzilla. Когда эта миграция завершиться, пока не ясно. Но все эти правила могут измениться.

Запрос на расширение функционала Bugzilla и другие запросы на улучшение инфраструктуры должны быть представлены как Предложения по улучшению для продукта Libreoffice и поданы администраторам Bugzilla через Управляющий Инженерный Комитет (ESC). Этот процесс является гарантией, что запрос является волей сообщества и ускорит его рассмотрение. Соответствующий член комитета должен быть поставлен в копию запроса для того, чтобы запрос появился на повестке дня ESC.

Как цитировать другие комментарии

Пожалуйста, избегайте излишнего цитирования! Это утомительно читать ненужные повторы. Только если вы не отвечаете на предыдущий комментарий, может быть полезно использовать функцию Bugzilla ответить ([reply]). Если вы думаете, что для понимания вашего сообщения необходимо цитирование, вы можете привести одну - две строки из комментария на который вы отвечаете, но не полную цитату.

Это также значит: пожалуйста, НИКОГДА не используйте интерфейс вашего почтового клиента для комментариев, используйте ответ на веб-странице ошибки в Bugzilla. Там у вас больше информации, которую вы не видите в последнем комментарии в интерфейсе почтового клиента.

Как цитировать в Bugzilla другие ошибки связанные с Libreoffice

Чтобы получить ссылку на ошибку в вашем комментарии, просто напишите что-то подобное Bug 12345, где 12345 номер ошибки, на которую вы хотите дать ссылку. Не используйте диез (#), или другие лишние знаки в номере ошибки.

Вообще, в большинстве случаев, полезно привести полностью поле резюме (Summary) той ошибки, на которую вы ссылаетесь. Просто вставив его Copy/Paste.

Как интерпретировать информацию Target в поле Whiteboard

target:3.7.0 в поле Whiteboard в настоящее время (2012-08-10) значит, что исправление было отправлено в код для master ветки, первая публикация версии, где будет доступно это исправление -- это 4.0.0.x. Если вам интересно, почему исправление до сих пор не вошло в код поддерживаемых версий (3.5, 3.6), имейте терпение! Чтобы избежать регрессии, исправление должно быть рассмотрено другими разработчиками, до того, как может быть интегрировано в текущую версию. Это займет некоторое время. Пока ошибка не получила статус FIXED можно надеяться, что она войдёт в текущую ветку кода.

Что делать с конами сообщений об ошибках

Иногда человек создающий отчет об ошибке случайно создаёт несколько клонов (абсолютно одинаковых) сообщений. Пожалуйста, не маркируйте их как DUPLICATES. Большое количество дублирующих ошибок должно быть индикатором, который показывает, что проблема затрагивает многих пользователей. Чтобы сохранить эту функцию, клоны необходимо закрывать как RESOLVED - INVALID с комментарием "Clone of Bug xxxxx", где ххххх - ссылка на оригинальное сообщение от которого пошли клоны.

Как использовать прикреплённые документы в нескольких отчетах от ошибках

Скриншот
Screenshot, please delete "Details " after copy&paste "Attachment ..." from Window heading to comment!

Прикрепление одного и того же документа к разным отчетам об ошибках не является необходимым, а иногда и бесполезно. Вы можете создать ссылку с текстом "attachment 12345 from Bug 6789" (где 12345 номер прикрепления, а 6789 номер ошибки) в тексте комментария или сообщения об ошибке. Таким образом вы очень просто получите ссылку на скачивание прикреплённого файла и укажете где можно найти дополнительную интересную информацию об ошибке, связанную с этим документом. Как показано на скриншоте, наведя курсор мыши на ссылку в оригинальной ошибке, вы увидите номер прикреплённого файла. Или вы можете скопировать его со страницы Bugzilla Attachment Details Info (Детальная информация о прикреплённом файле на Bugzilla). Комментарий к которому был прикреплён файл, чаще всего имеет важную информацию, поэтому, не забывайте указывать ссылку на оригинальную ошибку.

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

Как добавить ошибку в Самые Раздражающие Ошибки (MAB)

Существует специальная страница, посвящённая этому вопросу: Most Annoying Bugs.

Как подтверждать исправление ошибки

Если вы пытаетесь повторить ошибку в версии, для которой исправление ошибки должно быть включено в код (смотри Как интерпретировать информацию Target в поле Whiteboard) и вы видите, что ошибка отсутствует, вы можете изменить статус ошибки в Bugzilla на VERIFIED, который показывает, что исправление было подтверждено.

Если после того как исправление было включено в код вы всё равно можете её воспроизвести следуйте инструкциям Как заново открыть ошибку.

Как подать отчет с обратной трассировкой

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

  • Как текст в комментарии.
    • Преимущества:
      • информация обратной трассировки может быть показана при запросах.
    • Недостатки:
      • Строки из обратной трассировки могут создавать нежелательные результаты в запросах.
      • Плохая читаемость информации обратной трассировки в комментариях.
  • Как прикреплённый текстовый документ
    • Преимущества:
      • Не мешает чтению отчета об ошибке и комментариев.
      • Если есть новые данные, имеется возможность пометить вложение как устаревшее.
      • Не создаёт нежелательных результатов в запросах.
    • Недостатки:
      • Не появляется в запросах.

Как сделать упоминание прикреплённого файла или отчета об ошибке

Самый простой и надёжный способ - это написать Bug 47712 (как пример) вместо <https://bugs.documentfoundation.org/show_bug.cgi?id=47712>. Когда отчет или комментарий будет показан, Bugzilla автоматически подставит ссылку вместо текста.

Также и с прикреплённым файлом, вы должны писать attachment 61814 вместо <https://bugs.documentfoundation.org/attachment.cgi?id=61814>.

Как найти дополнительную информацию об отчетах

Ниже представлены несколько полезных запросов:

Для пользователей 64-битной операционной системы

Так как, запустить 32-битное приложение на 64-битной операционной системе возможно, выбор архитектуры может быть несколько запутанным в Bugzilla. В общем случае, пожалуйста, указывайте ту архитектуру, для которой была сделана сборка LibreOffice. Эта информация, к сожалению, не отображается в приложении, однако:

  • Пользователи Windows:
  • Windows users: в настоящее время, официально для Wndows существует только 32-битная версия, используйте "x86 (IA32)". Не забывайте, пожалуйста указывать архитектуру операционной системы.
  • для пользователей Linux: чаще всего вы используете туже самую архитектуру для пакета, что и ваша система. Если же ваша система имеет пакеты смешанной архитектуры, обратитесь к справочному руководству вашего пакетного менеджера Wikipedia logo v3.svg. Узнать архитектуру системы можно набрав
    uname -i
    
    . Если появляется что-то типа i386 или i686, то это 32-битная система, если x86_64, то 64-битная. Ниже приведены команды для то, чтобы узнать архитектуру приложения в распространённых операционных систем:
    • Debian и Ubuntu подобные дистрибутивы:
      dpkg --list 'libreoffice'
      
    • Fedora, Red Hat, CentOS и подобные дистрибутивы:
      yum info libreoffice
      
    • OpenSUSE:
      zypper info libreoffice
      
  • Mac OS users: ...

Как заново открыть ошибку

Смотри Детали отчета об ошибке!

Как отметить ошибку как дубликат

Скриншот поля статуса

Если вы находите, что ошибка (для примера, tdf#40691) является дубликатом другой (tdf#37195), вы можете отметить её как DUPLICATE, вставив номер оригинальной ошибки (37195) в поле, когда вы нажимаете Mark as Duplicate. О том, что ошибка помечена дубликатом нет необходимости извещать репортёра и людей в поле копия ошибки tdf#37195. Bugzilla самостоятельно отправляет извещение о всех изменениях в tdf#37195 и репортёрам в дублирующей ошибке.

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

Как закрыть отчет об ошибке, если ошибку больше нельзя воспроизвести

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

Примечание: Явное исправление ошибок является более надёжным решением, чем то когда ошибка случайно пропала. Эта разница должна быть видна в статусе.

Также, версия в которой ошибка больше не появляется, должна быть отмечена с ключевым словом Target в поле Whiteboard. Пожалуйста, укажите подробности вашего тестирования, особенно важно это сделать, если это ваш первый контакт с данной ошибкой (вы до этого не воспроизводили её). Возможно:

  • вы не совсем точно выполняете пошаговую инструкцию репортёра;
  • это может быть связано с конкретными условиями выполнения программы, которые ещё не были изучены.

How to assign a bug (QA Team only)

It has become a de-facto standard in 2011 (decided by ESC) to proceed as following:

  • User Account of Friendly Expert (or known developer for the issue) will be inserted to CC by an experienced user, Status remains (or becomes) New
  • Developer accepts bug by
    • adding himself to Assigned to and
    • changing Status to ASSIGNED
or does not accept bug

The following queries will have to be modified!

Ошибка до сих пор присутствует, хотя статус FIXED

Вы не можете быть уверены, что исправление ошибки интегрировано в новую версию, даже если стоит статус FIXED. Пожалуйста смотрите информацию target в поле Whiteboard и эту статью

RC Version vanished?

You filed a Bug and can not find it with "Search by Version" (for example using a link you bookmarked)? Reason might be that you discovered the bug with the last Release Candidate before the release. If the LibreOffice Release version is bit by bit identical to the last RC, the RC version from Version Picker will be changed to Release Version (for Example: 3.4.2 RC to 3.4.2 release by the administrator

Bugzilla Voting?

Currently the Engineering Steering Committee does not believe that a simple Voting will bring enough new information. That does not mean that there is a fundamental resistance against any way of "user poll". If someone has an well founded conclusive concept we can discuss the question again and if feedback is positive we will find an infrastructure for the process.

Статистика Bugzilla

Смотри QA/Bugzilla/Statistics.