BugTracking/BugzillaMiniHowto

{{MovedFromFreesourceInfo|AltLinux/BugTracking/BugzillaMiniHowto}}

== ALT Linux Bugzilla mini-HOWTO ==

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

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

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

=== Регистрация ===

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

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

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

Итак, поищем описание проблемы среди имеющихся (регистрации не требует):
* кликаем по ссылке <tt>Поиск</tt>/<tt>Search</tt> внизу страницы;
* в появившейся форме выбираем продукт, например <tt>Sisyphus</tt>;
* в поле <tt>Компонент</tt>/<tt>Component</tt> вводим название пакета, для которого ищем проблему (здесь тоже действует автодополнение);
* в принципе на этом можно остановиться и нажать кнопку <tt>Поиск</tt>/<tt>Search</tt>. В этом случае мы получим полный список известных проблем для заданного пакета (компонента). Можно сузить список найденных проблем, задав определённый статус:
** <tt>UNCONFIRMED</tt> — неподтвержденный,
** <tt>NEW</tt> — новый,
** <tt>RESOLVED</tt> — (раз)решённый,
** <tt>CLOSED</tt> — закрытый,
** <tt>REOPENED</tt> — открытый повторно,
и т. д. Это, несомненно, сократит количество найденных багов.
* каждая страничка багрепорта похожа по своей структуре на плоский тред форума. То есть внутри может быть беседа одного, двух или более лиц по существу поставленной проблемы. Также там могут находится патчи и возможные (временные) исправления проблемы или предложения разработчику (имеются в виду не поздравления с днем рождения или другими праздниками, и не предложения утопиться в ближайшем пруду, а желание реализовать ту или иную недостающую функциональность).
* если при попытке открыть багрепорт получаем <tt>Access Denied. You are not authorized to access bug #nnnn.</tt> — скорее всего, проблема или имеет отношение к безопасности и до сих пор не публична, или помечена как таковая по ошибке.

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

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

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

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

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

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

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

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

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

Майнтейнер пакета может исправить (или не исправить) ошибку и изменить её статус на <tt>RESOLVED</tt> (исправлена), при этом указывается способ исправления (resolution) ошибки:
* <tt>FIXED</tt> — ошибка исправлена, как правило, исправлением исходных кодов или spec-файла.
* <tt>NOTABUG</tt> — майнтейнер считает, что сообщение об ошибке некорректно (например, если это не баг, а фича).
* <tt>WONTFIX</tt> — майнтейнер признал наличие ошибки, но по каким-то причинам не собирается ее исправлять.
* <tt>DUPLICATE</tt> — сообщение об ошибке является копией другой ранее внесенной в базу ошибки, майнтейнер должен указать ее номер.
* <tt>WORKSFORME</tt> — майнтейнер не может воспроизвести ошибку и просит у пользователя дополнительную информацию.
Если исправление ошибки удовлетворило пользователя (например, он скачал обновлённую версию пакета и убедился в исправлении), пользователь должен изменить статус ошибки на <tt>CLOSED</tt> (закрыта). Если исправление не удовлетворило пользователя, он может переоткрыть ошибку, изменив статус на <tt>REOPEN</tt>.

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

Не вполне, но местами всё же применимый [https://bugzilla.redhat.com/bugzilla/page.cgi?id=bug_status.html CV баги].

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

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

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

=== Полезности ===

==== Firefox/Mozilla bookmarklet ====

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

Добавьте в букмарки (в папку «toolbar») такую ссылку:
<pre>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</pre>

==== Firefox/Mozilla Internet Keyword ====

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

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

Имя (Name): любое
Адрес (Location): http://bugzilla.altlinux.org/%s
Краткое имя (Keyword): altbug

==== Opera Search Engine ====

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

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

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

==== Opera Search Field ====

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

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

=== Ссылки ===
* [https://bugzilla.altlinux.org/docs/html/using.html Руководство по эксплуатации Bugzilla (en)]
* [http://lib.custis.ru/index.php/Bugzilla О Bugzilla по-русски]
* [http://www.developers.org.ua/archives/egorfine/2008/04/03/effective-bug-reports/ Эффективные баг-репорты]
* [http://www.linux.com/article.pl?sid=07/03/07/2012225 A dozen tips for testing free software]
* [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively]
* [https://bugs.eclipse.org/bugs/bugwritinghelp.html How to Write a Useful Bug Report]
* [http://developer.mozilla.org/en/docs/Bug_writing_guidelines Bug Writing Guidelines]