BugTracking/BugzillaMiniHowto

ALT Linux Bugzilla mini-HOWTO

Как театр начинает с вешалки, так и багзилла начинается с регистрации. Конечно же, всегда есть возможность зайти в театр, поглазеть на афиши идущих в этом сезоне спектаклей (поиск существующих багов в багзиле), но тогда пропадает самое главное достоинство — интерактивность происходящего. Напомню, что речь идет о театре, находящемся по адресу bugzilla.altlinux.org Внешний вид театра классический. Конечно, это не греческий амфитеатр, но в то же время сделан по образу и подобию многих таких же построек.

Скажу сразу, что вдаваться в подробности устройства театра «Глюкозавр» (c) pilot@ я не собираюсь, и рассказывать, что происходит за сценой — у меня цели тоже нет. Моя задача провести вас в зал — дать, так сказать, контрамарку $)

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

Регистрация

Для тех, кто уже имеет постоянный именной абонемент, этот абзац скорее всего будет неинтересен, и я предлагаю пропустить его, дабы не тратить драгоценное время. Остальным же сообщаю, что для регистрации в Bugzilla на главной странице присутствует линк с гордым именем Регистрация/New Account (самая нижняя строка, вторая справа ссылка слева от Вход в систему/Login). Все, что нужно указать на появившейся странице по ссылке — это только реальный email (первое поле). Ну а дальше система вышлет на зарегистрированный электронный адрес письмо для подтверждения регистрации, при переходе по ссылки в котором можно будет установить пароль. Пароль в дальнейшем можно будет поменять при входе в систему (Команды: Параметры/Actions: Preferences).

• 

  Запрос на регистрацию

• 

  Регистрация

• 

  Смена пароля

Получив доступ в систему, можем смело действовать.

Поиск существующих ошибок

Итак, поищем описание проблемы среди имеющихся (регистрации не требует):

• кликаем по ссылке Поиск/Search внизу страницы;
• переходим во вкладку "Простой поиск"
• в появившейся форме выбираем продукт, например Sisyphus;
• в поле Компонент/Component вводим название пакета, для которого ищем проблему (здесь тоже действует автодополнение);
• в принципе на этом можно остановиться и нажать кнопку Поиск/Search. В этом случае мы получим полный список известных проблем для заданного пакета (компонента). Можно сузить список найденных проблем, задав определённый статус:
  • UNCONFIRMED — неподтвержденный,
  • NEW — новый,
  • RESOLVED — (раз)решённый,
  • CLOSED — закрытый,
  • REOPENED — открытый повторно,

и т. д. Это, несомненно, сократит количество найденных багов.

• каждая страничка багрепорта похожа по своей структуре на плоский тред форума. То есть внутри может быть беседа одного, двух или более лиц по существу поставленной проблемы. Также там могут находится патчи и возможные (временные) исправления проблемы или предложения разработчику (имеются в виду не поздравления с днем рождения или другими праздниками, и не предложения утопиться в ближайшем пруду, а желание реализовать ту или иную недостающую функциональность).
• если при попытке открыть багрепорт получаем Access Denied. You are not authorized to access bug #nnnn. — скорее всего, проблема или имеет отношение к безопасности и до сих пор не публична, или помечена как таковая по ошибке.

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

• 

  Кликаем по ссылке "Поиск"

• 

  переходим во вкладку "Простой поиск"

• 

  Выбираем продукт

• 

  Вводим название пакета

• 

  При необходимости ставим статус

• 

  Найденные пакеты

Поиск ошибки по номеру

Еще одна разновидность поиска — по номеру ошибки. Допустим, вам пришло уведомление от глюкоробота или же где-то на просторах интернета вы встретили упомнинание вида «#6629» со смысловым смещением (указанием) в сторону багзилы. В этом случае достаточно ввести «магические цифры» (номер ошибки, 6629 в нашем примере) в поле в шапке или подвале страницы поле рядом с кнопкой Поиск/Search и нажать оную. Система сразу же переместит вас на страницу с описанием ошибки (если такая зарегистрирована).

Как вариант, можно вбить руками адрес bugzilla.altlinux.org/nnnn.

• 

  Переход на страницу ошибки по адресу

Поиск с помощью packages.altlinux.org

На сайте packages.altlinux.org находите пакет, на который вы хотите повесить отчёт об ошибке, например, kde5-krusader -- и щёлкаете по заголовку Ошибки; в результате попадаете на страницу, где отмечены все ошибки (баги) и пожелания, "повешенные" на данный пакет.

• 

  Список ошибок на packages.altlinux.org

Заведение нового бага

Обратите внимание: на каждую отдельную ошибку стоит создавать отдельное сообщение.

Если есть несколько перекликающихся, но по существу разных ошибок в различных компонентах или даже в одном -- стоит их развесить отдельно ради точности и понятности (иначе проблемы "растекаются" и теряют состояние как таковое), затем можно добавить метабаг, который зависит от каждой из них, содержит ключевое слово METABUG в поле Ключевые слова/Keywords и [META] в описании, но в подробном описании лишь обобщает причину/цель данной группы сообщений об ошибках.

Вести обсуждение самих ошибок в метабаге не следует (для этого есть отдельные сообщения).

• Жмём кнопку Зарегистрировать ошибку/New bug
• Если логин (email)/пароль введены ещё не были, система спросит их и предложит выбрать раздел — вешаем ли мы баг на дистрибутивы, в нестабильную ветку или на неправильно работающий web-сайт ALT Linux. После этого выберем «продукт», на который вешаем баг. Под продуктом подразумеваются конкретная часть системы, как-то дистрибутив, Sisyphus, документация, переводы. Определившись, на что именно вешаем багу — выбираем нужный продукт. В некоторых разделах этот шаг отсутствует.
• Дальше заполняем поле Компонент/Component (пакет, на который мы вешаем багу, или конкретный web-сайт). Если компонентов в данном продукте мало — там будет выпадающий список, если много — поле ввода с автодополнением.
• Следующее поле (Платформа/Platform) можно оставить без изменений, если только ваша ошибка не проявляется исключительно на 64-битной системе или на системе с процессорами ARM или PowerPC.
• А вот поле Severity имеет глубинный смысл, ведь это сурьёзность заводимого сообщения об ошибке. Если сомневаетесь — оставьте Normal.
  • blocker — наиболее чреватые проблемами ошибки, включая серьёзные проблемы безопасности или функциональности;
  • critical — критичные для функционирования пакета;
  • major — выдающиеся относительно обычных;
  • normal — «обычные» (умолчание);
  • minor — незначительные, но тем не менее;
  • trivial — тривиальные в исправлении (например, опечатки в описании пакета или меню);
  • enhancement — не сообщение об ошибке, а предложение по улучшению.
• Если ошибка касается безопасности и предоставляемая информация имеет чувствительный характер — есть отдельная галочка Security group (злоупотреблять не стоит — баг можно направить в эту группу только при его открытии, а снять пометку могут только члены этой группы; баги с пометками видят только члены сразу всех групп, на которые проставлены пометки).
• Заполняем поле Суть/Summary. В этом поле можно в двух-трех-десяти словах (одним предложением) описать суть проблемы, чтобы легче было искать и ориентироваться другим пользователям глюкозавра. Принцип «краткость — сестра таланта» здесь действует как никогда.
• Поле Подробное описание/Description подразумевает полное (детальное) описание проблемы, в котором нужно указать версию и название установленного дистрибутива, даты последних обновлений. Если есть понимание - версию пробного пакета. Приложить логи (в случае ошибки с ядром - dmesg), для ошибок, связанных с оборудованием - список оборудования (выводы команд lspci -nn и lsusb -v). Если надо - скриншоты ошибки.
• Если все поля заполнены верно, то жмём кнопку Сохранить/Commit.

Скорее всего, ошибка будет добавлена в базу и майнтейнер пакета будет уведомлен по электронной почте о неисправности в его пакете.

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

Информация о дальнейшей активности в рамках описанной или подписанной (полем Исполнитель/Assign to можно переложить ответственность на другого разработчика; для дополнения списка уведомляемых есть Подписка/Cc:) ошибки будет сваливаться на указанный при регистрации электронный адрес. Под активностью подразумевается изменение статуса ошибки, комментарии других пользователей, добавление патчей или текстовых файлов и т. д. (к слову, все это вы можете настроить по своему вкусу). Кого добавлять в список Сс: — можно узнать, например, из Changelog пакета (например, если маинтейнером пакета является некая packaging team, то стоит добавить в Сс: несколько человек из неё); автоматически добавляются указанные в ACL пакета. При этом указывать в поле Сс: следует в формате <login@altlinux.org>.

Закрытие бага

Майнтейнер пакета может исправить (или не исправить) ошибку и изменить её статус на RESOLVED (исправлена), при этом указывается способ исправления (resolution) ошибки:

• FIXED — ошибка исправлена, как правило, исправлением исходных кодов или spec-файла.
• NOTABUG — майнтейнер считает, что сообщение об ошибке некорректно (например, если это не баг, а фича).
• WONTFIX — майнтейнер признал наличие ошибки, но по каким-то причинам не может или не собирается ее исправлять. Также применяется для случаев, когда действительная ошибка осталась на пакете, который более не поддерживается в Sisyphus и по факту отсутствует в репозитории.
• DUPLICATE — сообщение об ошибке дублирует другую ранее внесенную в базу кляузу, майнтейнер должен указать ее номер.
• WORKSFORME — майнтейнер не может воспроизвести ошибку и просит у пользователя дополнительную информацию.

Если исправление ошибки удовлетворило пользователя (например, он скачал обновлённую версию пакета и убедился в исправлении), пользователь должен изменить статус ошибки на CLOSED (закрыта). Если исправление не удовлетворило пользователя, он может переоткрыть ошибку, изменив статус на REOPEN (см. тж. чуть ниже).

К сожалению, пользователю трудно обнаруживать исправленные (FIXED), но не закрытые (CLOSED) ошибки, поскольку такие ошибки не обнаруживаются стандартным поиском «My bugs». Для обнаружения таких ошибок рекомендуется воспользоваться поиском по ошибкам, имеющим статус FIXED, или использовать гиперссылку в письме, которую вы получите после изменения майнтейнером статуса ошибки на FIXED.

Не вполне, но местами всё же применимый CV баги.

И напоследок, старайтесь пользоваться театром, не причиняя вреда и неудобства другим зрителям или актёрам. Актёр должен чувствовать себя комфортно на сцене, а зритель — в зале. Чем больше полезной информации донесёт зритель до актёра, тем больше вероятности, что актёр осчастливит зрителя свой блестящей игрой $)

В частности, если у вас проблема с каким-то пакетом, а не «вообще» — указывайте его версию.

И ещё — не вешайте баги «отсутствует перевод» или «ошибка в переводе», особенно если заметно что проблема в консерватории (ну то есть в дирекции театра :)). В этом случае лучше сделать или поправить перевод и прислать его разработчикам программы. Мантейнерам хватает забот, и не все они переводчики.

Переоткрыть или повесить новый?

> Переоткрою. Чуть-чуть бы доделать.

Не надо так делать — у каждой хорошей баги должны быть чёткие начало, формулировка и конец. Когда начинаются бесконечные самоуточняющиеся портянки, незаметно растёт наклад времени на их разбор и «diff» для выяснения, что ж там ещё; теряют точность ссылки на багу в %changelog (или же приходится сопоставлять и время); многих подобное подвигает в сторону «забить».

Проверено на случае, где «портянки» дошли до клинических и в итоге пришлось писать внутренний регламент.

Есть отдельная проблема — есть отдельная бага.

Полезности

Firefox/Mozilla bookmarklet

Закладка на панели, по клику на которую спрашивается номер бага для открытия.

Добавьте в букмарки (в папку «toolbar») такую ссылку (в одну строчку):

javascript:q = "" + (window.getSelection ? window.getSelection() : 
document.getSelection ? document.getSelection() : 
document.selection.createRange().text); 
if (!q) q = prompt("You didn't select any text.  Enter altbug id:", ""); 
if (q!=null) location=("https://bugzilla.altlinux.org/"+q); void 0

Firefox/Mozilla Internet Keyword

Переход к багу с номером NNN при вбивании в строку адреса altbug NNN либо всем багам пакета ABC по altbug ABC

Добавьте закладку со следующими параметрами:

• Имя (Name): ALT Linux Bugzilla
• Адрес (Location): https://bugzilla.altlinux.org/%s
• Краткое имя (Keyword): altbug

Может также пригодиться расширение URL Alias, рекомендуемое legion@.

Opera Search Engine

Переход к багу с номером NNN при вбивании в строку адреса altbug NNN

Добавьте Search Engine Tools ▷ Preferences ▷ Search ▷ Add со следующими параметрами:

• Имя (Name): ALT Linux Bugzilla
• Краткое имя (Keyword): altbug
• Адрес (Address): https://bugzilla.altlinux.org/%s

Opera Search Field

Поле ввода типа «google search» для перехода к багу по номеру

Добавьте Search Engine, созданный на предыдущем шаге, на любую панель инструментов: (Right Click) ▷ Customize ▷ Buttons ▷ Search. Перетащите «ALT Linux Bugzilla» в нужное вам место на панели инструментов.

Ссылки

• Руководство по эксплуатации Bugzilla (en)
• О Bugzilla по-русски
• Эффективные баг-репорты
• Как эффективно сообщать об ошибках (How to Report Bugs Effectively)
• How to Write a Useful Bug Report
• Bug Writing Guidelines
• Видеоролик "Создание запроса на улучшение пакета"