Ключевым понятием системы является баг («Bug») — суть «issue» — некоторое задание, запрос, рекламация по поводу ошибки в системе, или просто сообщение, требующее обратной связи, и назначение системы — регистрация и предоставление заинтересованным лицам целостной информации об состоянии этого «issue»,
включая интерфейсы редактирования, запроса и поиска, механизмы почтового и RSS-оповещений.
Сейчас Bugzilla используют более пятиста компаний и организаций по всему миру. Из наиболее известных имен компаний и проектов: NASA, IBM, Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office.
Анатомия бага
Сущность Bug имеет набор атрибутов, работа с которыми — редактирование и запросы — является основными сценариями использования Bugzilla.
Опишем эти атрибуты.
Структурные
Product
«Продукт». Основной атрибут, задающий структуру. Каждый «Product» состоит из набора компонентов. Можно включить классификацию продуктов — дополнительное подразделение продуктов на группы (исключительно двухуровневое), что отразиться на интерфейсе заведения новых багов и на интерфейсе запросов.
Component
«Компонент». Дополнительная структурная классификация. В зависимости от выбранного компонента, баг может иметь разный набор флагов.
Атрибуты жизненного цикла
Status
«Статус». Основной атрибут, определяющий текущее состояние бага, т. е. меру его активности — от самого «начального» состояния, когда он даже не подтвержден, как баг, до благополучного завершения, когда баг исправлен/решен, что подтверждено Службой Качества.
Набор состояний зависит от конкретной инсталляции и настройки Bugzilla, однако, стандартный набор:
UNCONFIRMED
«Не подтвержден». Наличие этого состояния зависит от настройки конкретного продукта. Например, если считается, что баг-отчеты в продукт могут составлять неконтролируемое множество пользователей (например, интернет-аудитория), то в этом состоянии имеется смысл. Тогда, для перехода в следующее состояние («NEW»), необходимо решение пользователя системы с правами «canconfirm». Если же новые баги ставят только обученные сотрудники, то в это состояние, скорее всего не нужно.
NEW
«Новый». Только что зарегистрирован или проверен (если был зарегистрирован в состоянии «UNCONFIRMED»).
ASSIGNED
«Акцептован». Пользователь, указанный в «Assigned-to», подтвердил свою ответственность за этот баг. Баг может быть «перенаправленным» другому лицу, и снова стать «NEW».
REOPENED
Баг уже был однажды решен, однако, решение было либо неправильными, либо неокончательным.
Resolution
«Резолюция», «Решение» — этот атрибут имеет смысл только для багов в состояниях «RESOLVED», «VERIFIED», «CLOSED». Также, набор «резолюций» можно настраивать, но стандартный набор следующий:
FIXED
«Решено» — наиболее стандартная резолюция — означает, что задание выполнено или баг исправлен.
INVALID
«Некорректно» — неправильная или некорректная постановка, не имеющая смысла.
WONTFIX
«Проблема есть, но решать ее не будем». Например, такое может быть в отношении «request for enhancement», которые хоть и имеют смысл, но являются слишком трудновыполнимы и не являются обязательными.
DUPLICATE
«Дубль» — описанная проблема уже регистрировалась в определенном баге.
WORKSFORME
«А у меня работает…» — не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода.
MOVED
Проблема перенесена в иную систему-"tracker".
Диаграмма
Жизненный цикл бага, он же граф переходов состояний, он же work flow, жестко задан в коде, и представлен ниже, на графе.
Связанные пользователи
Assigned_To
Лицо (сотрудник, пользователь), ответственное за решение (исправление) бага. Подтверждение ответственности происходит при переводе бага из состояний «NEW» или «REOPENED» в состояние «ASSIGNED».
Reporter
Пользователь, собственно составивший (заполнивший информацию) о баге.
QA
Пользователь, ответственный за проверку решения бага.
CC
«СС list»: Список людей, извещаемых при изменениях бага.
Описание бага
Summary
Аннотация задачи/проблемы одним предложением. В правилах «хорошего тона» обязательно дублировать (не обязательно дословно) при регистрации нового бага, содержимое «Summary» в первом комментарии, ибо атрибут «Summary» может быть несколько раз отредактирован, будет утерян смысл бага. Конечно, можно посмотреть историю изменений, но лучше, чтобы эта история была зафиксирована в комментариях, которые показываются всегда.
Version
Обычно используется для указания конкретных версий продукта (вернее компонента продукта), в которых наблюдается описанная проблема.
Priority
Ответственный указывает приоритет (именно свою оценку приоритета) описанной проблемы или задания. Поэтому менять приоритет у чужих багов-заданий считается неправильным.
Стандартный набор значений — от «P1» (наивысший приоритет) до «P5» (наименьший).
Severity
Указывает на критичность возникшей проблемы. Домен значений можно настраивать, стандартный набор следующий:
Blocker
Разработка или использования продукта невозможна. Нужно немедленное исправление проблемы.
Critical
Серьезные проблемы — не работает критический блок функционала, наблюдаются серьезные ошибки, связанные с потерей данных и т. п.
Major
Проблема связана с важным функционалом продукта.
Minor
Проблема связана с второстепенным функционалом продукта, или есть легкий обходной путь для этой проблемы.
Trivial
Проблема косметического уровня — например, «недоработанный» интерфейс (опечатки, не выровненные поля, разнобой с цветами и т. п.)
Enhancement
«Request for enhancement».
Target
«Target Milestone», «Веха».
Указание вехи, (версии, стадии) проекта, к которой баг должен быть решен.
Не путать с версией. Например, баг может описывать ошибку, возникшую в версии «1.17», но которую было решено исправить к вехе «1_21», в которой будет выпущена версия продукта «1.21». Веха не обязательно должна быть привязана к версии продукта — она может быть привязана и к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут «Milestone URL», содержащий ссылку на документ, где вехи продукта должны быть поименованы и описаны, т. е. где будет приведен некоторый «Roadmap» проекта.
Comments
Комментарии. Первый комментарий по багу — это «Description», остальные в форме редактирования бага именуются «Additional Comments». Используется всеми связанными с багом пользователями для централизованных комментариев, которых Bugzilla рассылает всем (#Reporter,#CC,#QA,#CC) по почте.
В нашей инсталляции, есть возможность «Silent»-комментариев (checkbox «Silent»), информация о которых не рассылается по почте. Использовать только в том случае, когда информация в комментарии действительно малоинтересна — например, просто worklog-запись о выполненной промежуточной (не «решающей» баг) работе, например, если основная ценность записи — с регистрация личных трудозатрат (см. #Учет времени (Timetracking)).
Также, не стоит злоупотреблять комментарии, и превращать их в форум. Для обсуждения постановки задачи, продуктивней завести ассоциированную с багом статью в WikiWiki-системе, и обсуждать там (см. #Интеграция с Wiki).
Зависимости между багами
В Bugzilla регистрируется только один единственный вид зависимостей:
«баг X зависит от решения бага Y». Т.е. нет разделения структурных зависимостей вида «проблема X подразделяется на проблемы X1,X2,X3» и сетевых зависимостей общего вида, но в целом, ничто не мешает представлять структурные зависимости в общем виде («баг X зависит от решения багов X1,X2,X3».
Зарегистрированные зависимости видны и при просмотре атрибутов отдельно выбранных багов, и могут быть просмотрены в виде ориентированного графа вида:
(Баг «11407» зависит от решенного «11406» и нерешенного «11405»).
Depends on
Указывает, от решения каких багов зависит данный баг.
Blocks
Указывает, решение каких багов зависит от данного бага.
Misc
URL
Ассоциированный с багом URL, указывающий на документ с описанием/постановкой проблемы, если таковой имеется.
В нашей инсталляции Bugzilla, можно также пользоваться автоматической связью между багом и ассоциированной с каждым компонентомWikiWiki-системой, в которой можно делать пристойно отформатированную постановку задачи и даже вести ее обсуждение (См. #Интеграция с Wiki).
Whiteboard
Текстовая зона свободной формы для задания кратких заметок или тегов к багу.
Keywords
Ключевые слова, используемые для пометки и даже для классификации багов.
Набор ключевых слов «глобальный», общий для всех продуктов внутри инсталляции Bugzilla, поэтому, рекомендуется ответственно относиться к заведению каждого нового ключевого слов, чтобы не «замусоривать» общее пространство.
Platform
Вычислительная платформа (железо), на которой наблюдается проблема.
В нашей инсталляции Bugzilla этот атрибут не используется.
OS
Операционная система, на которой наблюдается проблема.
В нашей инсталляции Bugzilla этот атрибут не используется.
Attachments
К багам можно прикреплять файлы (например сценарии тестирования, патчи)
Votes
Собрал ли баг сколько либо голосов (в нашей инсталляции отсутствует). Используется, в основном, для автоматического перевода бага из состояния «UNCONFIRMED» в состояние «NEW».
Поиск багов
Основные атрибуты
На странице «Bugzilla Search» представлен интерфейс к поиску любых зарегистрированных багов, комментариев и патчей. Интерфейс позволяет задать поисковые значения для всех перечисленных полей бага, причем для некоторых полей может быть задано несколько значений из домена (с помощью списков с множественным выбором). Если значение не выбрано — атрибут бага может принимать любое значение.
Хранение запросов
Любой выполненный запрос можно сохранить под неким выбранным именем («Remember Search As»), тогда результат этого запроса можно будет всегда получить за один «клик», активировав одноименную с запросом ссылку, которая будет показываться внизу страницы, в линейке «Saved Searches».
Временные условия
Можно накладывать временные условия на изменение бага, запрашивая только баги, по которым было какое нибудь движение (изменение атрибутов, комментарии) в определенном интервале времени — см. группу полей «Bug Changes». Интервал времени можно задавать как в абсолютной форме (дата в ISO-формате yyyy-mm-dd), так и в форме, относительной текущей даты, таким образом можно сделать хранимый запрос, показывающий только баги измененные в течении предшествующих 24 часов (или недели, или месяца).
Конкретно, можно использовать слова:
Now — «сейчас», разумно использовать для задания верхней границы интервала.
1d — день назад (2d — два дня назад …). 0d — последняя полночь, до текущего момента.
1w — то же самое в неделях. 0w — начало недели.
1m — то же в месяцах. 0m — начало месяца.
1y — то же в годах. 0y — начало года.
Можно добавить перед относительными датами знак «+», это будет означать, что относительная дата не вычитается из «Now», а прибавляется (в будущее).
Boolean Charts
Можно также задавать «продвинутые» запросы используя «Boolean Charts».
Хотя использование «Boolean Charts» несколько менее «интуитивно» и возможно требует большего времени, чем задание атрибутов в основной форме, с их помощью можно построить запрос, практически произвольной сложности, вида
[ NOT ]
( (Атрибут11 Операция11 Значение11) OR (Атрибут12 Операция12 Значение12) OR ....)
[ AND (Атрибут21 Операция21 Значение21) OR (Атрибут22 Операция22 Значение22) OR ....) ]
[ AND ... ]
...
)
В частности, там можно накладывать условия по флагам, например,
Только баги, содержащие флаги установленные пользователем «user@company.com»
«Flag Setter» «is equal to» «user@company.com»
Только баги, в которых флаг «флаг_утвердить» установлен в «+»
«Flag» «is equal to» «флаг_утвердить+»
Только баги, в которых флаг «флаг_утвердить» установлен в «?»
«Flag» «is equal to» «флаг_утвердить?» (аналогично с «-»).
В нашей инсталляции Bugzilla мы также можем формулировать условия на «связанные» баги, т. е. задавать запросы вида «найти все мои баги, в открытом состоянии, для которых все блокирующие выполнены».
Для задания таких запросов, в Boolean Charts, при выборе атрибутов
«BugsThisDependsOn» и «OtherBugsDependingOnThis»
и операций «equals»/ «not equals», в поле значение, можно вставлять подзапрос, например:
query:SomeBugs
Тогда ограничение типа
BugsThisDependsOn equals SomeBugs
будет вводить ограничение «и баги, зависящие от багов, возвращаемых запросом SomeBugs»
BugsThisDependsOn not equals SomeBugs
будет вводить ограничение «и баги, не зависящие от багов, возвращаемых запросом SomeBugs»
OtherBugsDependingOnThis equals SomeBugs
будет вводить ограничение «и баги, блокирующие баги, возвращаемые запросом SomeBugs»
OtherBugsDependingOnThis not equals SomeBugs
будет вводить ограничение «и баги, не блокирующие баги, возвращаемые запросом SomeBugs»
Желательно, чтобы вспомогательные запросы возвращали небольшое число багов, иначе это сильно влияет на скорость ответа. Также, весьма желательно, при использовании этих условий, задавать дополнительные, «простые» условия фильтрации.
Заметим, запросы типа «баги, у которых нет блокирующих» или «баги, у которых нет зависимых»
можно реализовать стандартными условиями типа:
После выполнения запроса система возвращает выборку — список удовлетворяющих запросу багов. Формат этого списка настраиваемый, по ссылке «Change Columns» можно настроить набор показываемых в списке атрибутов.
Рекомендуется также включить настройку «Stagger headers» (разнесение заголовка таблицы списка на два уровня).
После выбора списка, его можно отсортировать щелчками по заголовкам колонок (что приводить к сортировке списка в порядке возрастания выбранного атрибута-колонки).
Другие полезные возможности вызываются ссылками, расположенными внизу списка:
CSV
выдает список в CSV формате (разделенным запятыми), например, для импорта в программу электронных таблиц.
RSS
выдает список в RSS формате, для чтения через RSS-агрегатор. Список отсортирован по убыванию времени открытия бага, набор полей тоже задан жестко. Может быть полезным для отслеживания «поступления» новых багов. Для пользователей Mozilla Firefox рекомендуется установить Sage, чтобы использовать Bugzilla-авторизацию, полученную браузером после логина;
Change Columns
изменить список атрибутов, показываемых в списке (см. выше) .
Change several bugs at once
Если у вас достаточно привилегий, то вы можете делать некоторые изменения одновременно над всеми багами в списке — например, сменить ответственного («owner»), «закрыть» группу багов, перенести их в другой продукт или компонент.
Send mail to bug owners
Послать письмо всем ответственным по всем багам в списке.
Edit Search
Можно вернуться на страницу запроса для дополнительного уточнения запроса.
Remember Search As
Можно присвоить этому запросу имя и сохранить его, ссылка на сохраненный запрос будет показываться внизу вашей страницы.
Просмотр выбранного списка багов в виде ориентированного графа.
Summary Report
Просмотр табличной агрегации (См. #Отчеты) выбранного списка багов по выбранному срезу (набору атрибутов). Каждая ячейка табличного отчета будет содержать число багов, обладающих соответствующими атрибутами и ссылка на список этих багов. Таким образом, можно легко делать настоящий «OLAP drill-down», т. е. формулировать «широкий запрос», переходя от списка к табличному отчету «раскладывать» по выбранным измерениям (от одного до трех), и далее, получать списки багов по отдельным ячейкам «среза», возможно повторяя процедуру раскладки по другим измерениям.
Заведение багов
Процедура заведения бага следующая:
Кликните на ссылке «NEW» в нижней линейке «Actions».
Выберите продукт и компонент.
Заполните поля. Уделите особое внимание атрибутам идентифицирующим проблему или задание (что, где, насколько срочно) — Product, Version, Severity; Старайтесь сделать так, что все, что вы написано в summary также было записано (не обязательно дословно) в первом комментарии (поле Description). Дело в том, что «summary» бага часто меняют, и нужно, чтобы первоначальная информация не пропала.
Нажмите «Commit» — это зафиксирует и отправит ваш «bug report».
Для быстрого заведения багов по образцу некоторых имеющихся (например, если происходит декомпозиция крупной проблемы на мелкие) можно применять клонирование багов.
Редактирование багов
Редактирование багов необходимо, для поддержания (и распространения по заинтересованным лицам) актуальной информации по обозначенной в описании бага проблеме или задаче.
Редактирование бага включает изменение значений атрибутов бага (причем ведется полная история их изменения, и написания комментариев (по сути рабочих журналов по решению проблемы).
Т.е. основной принцип «трекинга» — регистрация и хранение истории всех изменений. Поэтому, комментарии не удаляются и не редактируются, после того, как произошло их добавление в журнал комментариев к багу.
Кроме текстовых комментариев, можно также («аддитивно») регистрировать различные вложения («attachments») — логи ошибок, скриншоты, примеры патчей («patches»), и т. п.
В основном, редактированием основных атрибутов бага занимаются наиболее тесно связанные с багом
участники, указанные в атрибутах Reporter, Assigned_To и QA, но конкретный регламент использования жестко не определен, и в принципе, любой пользователь (даже никак не связанный с багом), обладающий соотв. правами, может менять состояние бага и другие атрибуты.
«Assignee» определяет Priority, Status, переводя баг по состояниям «NEW»-> «ASSIGNED»-> «RESOLVED».
«QA» определяет Status, переводя баг из состояния «RESOLVED» в состояния «VERIFIED» или «REOPENED».
Если в инсталляции включены функции регистрации времени (см., например, параметр «timetrackinggroup»), то можно, регистрировать предварительную оценку сложности задачи,
и с каждым комментарием также регистрировать свои трудозатраты и корректировать оценку оставшийся работы (См. #Учет времени (Timetracking)).
В окне редактирования бага можно выяснить различные аспекты решаемой проблемы, зарегистрированные как в Bugzilla:
Лента комментариев к багу, отсортированная по времени;
Ссылка «View Bug Activity» ведет на историю изменения всех атрибутов бага;
так и в других системах (есть в нашей инсталляции):
Look for Bug in CVS
Выполняет поиск в CVS-репозитарии ревизий файлов, в комментарии к которым указан номер этого бага и предоставляет Bonsai-интерфейс для просмотра совершенных изменений. См. #Интеграция с CVS.
Look for Bug in Wiki
Перенаправляет на ассоциированную с багом статью. См. #Интеграция с Wiki.
Комментарии
Заметим, что комментарии к багу нельзя редактировать задним числом (это принципиальная позиция),
разве что член специальной группы «insidergroup» может сделать их «private» — невидимыми для обычных пользователей.
В нашей инсталляции можно воспользоваться ссылкой «Preview» (например, проверить, правильно ли «прогиперлинкуются» различные ссылки, см. #Автоматические ссылки), и убедившись, что все хорошо, вернуться кнопкой «Back» броузера и выполнить «Commit».
В стандартной инсталляции для этого можно использовать страничку c адресом вида:
Для быстрого заведения новых багов (схожих с имеющимися) — например, если необходимо провести декомпозицию, т. е. выделить некоторую подзадачу из крупной задачи, можно применять «клонирование», вызываемое ссылкой «Clone This Bug to other/same product».
Клонирование бага приводит к заведению бага унаследовавшего все атрибуты (заполнять которых с нуля может быть очень муторно и долго) от исходного бага + являющегося блокирующим для родительского бага (впрочем, при клонировании можно и подредактировать родительские атрибуты и отказаться от блокирования родительского бага). «Клонирование в тот же продукт» выделено отдельной ссылкой, т. к. это ускоряет наиболее распространенный сценарий клонирования, исключая одну или две страницы выбора продукта.
В нашей инсталляции также можно клонировать в баг любой комментарий исходного бага — через ссылку «clone as bug» над комментарием.
Полезности
Автоматические ссылки
Комментарии в Bugzilla разрешены только plain текстом, т. е. печатая
<U>
даст не подчеркнутый текст, а
<U>
. Также нет списков и иных структурных элементов. Тем не менее, Bugzilla делает гиперссылки для определенного рода комментариев, например распознаются и «гиперлинкуются» основные типы URL, типа:
«http://»,
«ftp://»,
«mailto:»,
почтовые адреса «someone@somewhere.org».
Дополнительно гиперлинкуются ссылки на внутрибагзильные элементы (баги, комменты, вложения):
bug 12345
comment 7
bug 23456, comment 53
attachment 4321
Интеграция с CVS
Очень важно, описать связь между багами (заданиями или сообщениями об ошибках) и производимым (или исправляемым) Разработчиком артефактом — программным кодом (включая документацию). В нашей Компании, весь код (т. е. практически все производимое Разработчиком) находится под CVS — принятой в Компании системой контроля версий.
Наша инсталляция Bugzilla интегрирована с системой Bonsai, в которую оперативно грузится информация о всех правках в CVS-репозитарии Компании. Поэтому, если при работе над багом XXX, ведутся правки файлов, находящихся под CVS, то при фиксации, (т. е. при выполнении «commit») не нужно писать длинных комментариев, описывающих суть изменений, а достаточно указать идентификатор заявки/задания (номер бага), например, выполнить
cvs commit -m "Bug 1234"
Комментарий можно вводить и через опции командной строки и через редактор, см. ссылки на документацию в CVS.
При соблюдении этого правила, для каждой заявки можно найти все CVS-ревизии, в комментариях к которым указан номер этой заявки, с помощью ссылки «Look for Bug in CVS» на странице редактирования бага.
Интеграция с Wiki
Bugzilla не является инструментом, подходящим для совместной работы над любым документом (пусть даже одностраничным), поэтому, при возникновении спорной или дискуссионной ситуации, когда нужно выработать постановку задачи (пусть даже и локальной), нужно использовать подходящий для этого инструмент: WikiWiki-систему.
В нашей инсталляции Bugzilla, дополнительно к возможностям #Автоматические ссылки,
можно делать читаемые гипертекстовые ссылки на статьи (и разделы статей) в
CustisWiki, например
Если при работе над багом (заданием или запросом), требуется сделать документ-постановку задачи и/или провести его обсуждение, то можно воспользоваться ссылкой «Look for Bug in Wiki» на странице редактирования бага, и мгновенно перейти к одноименной с багом статье «Bug XXX», для чтения/редактирования/обсуждения. Рекомендуется после заведения статьи выполнить ее переименование (закладка «move») в более дескриптивное название, например «Bug XXX — ошибка ORA-YYY при загрузке каталога» (что можно сделать в два клика используя только copy-paste атрибута «Summary» бага и мышь). Таким образом, будет создана статья с смысловым заголовком, и статья-перенаправление «Bug XXX».
Однако, стоит помнить, что в CustisWiki не стоит помещать конфиденциальную информацию, т. к. тут уже не действует система прав Bugzilla.
Учет времени (Timetracking)
Пользователи, входящие в группу, указанную в настройках как «timetrackinggroup», могут вести учет трудоемкости каждого бага.
Для каждого бага ведется учет следующих полей
«Orig. Est.»
Начальная оценка трудоемкости бага. Разумно использовать как априорную оценку трудоемкости. Хотя ее можно менять, лучше это делать реже — т. е. чтобы сохранился смысл априорной оценки, данной разработчиком или руководителем проекта.
Число затраченных часов времени. Может только увеличиваться с каждым редактированием.
«Hours Left»
Осталось затратить времени. Изначально выставляется, как «Current Est.»- «Hours Worked», но будучи отредактированным, влияет на «Current Est.». Т.е. например, если считалось, что на баг надо затратить 5 часов, а после некоторой работы выяснилось, что затрачено 3 часа, а осталось еще 7, то текущая оценка меняется на 10 часов.
Выигрыш. Вычислимое поле — разность «Orig. Est.» — «Current Est.».
Советы
Поддерживайте целостность
Старайтесь сделать так, что все, что вы написано в «summary» также было записано в первом комментарии. Дело в том, что «summary» бага часто меняют, и нужно, чтобы первоначальная информация не пропала.
Старайтесь указывать корректные значения в полях или не указывать никаких. Например, не пишите строки «any», «нет» и подобный мусор в поле «URL», если нет никакого конкретного URL, который связан с данным багом.
Вложения
Используйте вложения, а не комментарии, для больших блоков текстовых данных, таких как отладочная информация, логи и т. п. Из-за этого комментарии к багу станет невозможно читать, да и люди получать бессмысленные жирные письма.
Обрезайте и сжимайте скриншоты. Нет необходимости показывать весь экран, если вы хотите указать на проблему в одном окне.
Не вкладывайте простые тестовые примеры (например HTML файл, ссылающийся на CSS и картинку) как архив. Вместо этого загрузите перечисленные файлы в обратном порядке, и отредактируйте вкладываемый HTML-файл, чтобы он ссылался непосредственно на загруженные вложения.
Bugzilla хранит и использует «Content-Type» для каждого вложения (например «text/html»). Чтобы выгружать вложение с другим «Content-Type» (например «application/xhtml+xml»), надо добавить CGI-параметр «content-type» в URL, т. е. &content-type=text/plain.
Комментирование
Если вы изменяете баг, добавляйте комментарий только если вам действительно есть что сказать по делу, или если этого требует Bugzilla (для некоторых типов переходов). В противном случае, вы можете без нужды «заспамить» невинных людей. Например, люди могут настроить свой аккаунт (См. #«Field/recipient specific options») чтобы не получать извещений при событиях вида «изменился CC». Но если доброжелатель добавляя себя, добавит еще комментарий «Я, типа, себя добавил», то это будет уже добавление комментария и это обойдет вышеуказанный фильтр.
Не используйте подписей в комментариях, особенно, модные многострочные подписи с ASCII-картинками.
Конфликты
Если вы считаете, что отправленный вами баг некорректно помечен как «DUPLICATE of another», пожалуйста, задавайте вопросы-комментарии в вашем баге, а не в том, который считается багом-оригиналом. Смело добавляйте в «CC» бага человека, который принял такое решение, если его в «CC» нет.
Флаги
Флаг это некий атрибут, разновидность статуса, который может быть установлен на баг или вложение, чтобы указать, что этот баг/вложение находятся в некотором состоянии. Каждая инсталляция может определить свой собственных набор флагов, которых можно устанавливать на баг или вложение. Более того, флаги, в отличие от ключевых слов, имеющих «глобальную область» видимости для всех продуктов и компонентов, можно делать локальными, устанавливая набор продуктов и компонентов, в которых может быть установлен этот флаг.
Если некий флаг определен в вашей конфигурации багзилла, то вы можете установить или сбросить этот флаг, и если разрешена функция запроса флагов (разрешается администратором системы), вы можете запрашивать другого пользователя установить флаг.
Чтобы установить флаг, выберите «+», или «-» из выпадающего списка за списком «Flags». Значение этих символов зависит от флага и в этой документации описано быть не может, но в качестве примера, установление флага «review» в «+» может означать что баг или вложение одобрены, а «-» — отклонены. Чтобы сбросить флаг, выберите в выпадающем списке пустое значение.
Если разрешено администратором, можно также делать «запрошенный флаг», устанавливая флаг в «?» и вводя рядом имя пользователя, от которого желается установка флага.
Установленный флаг показывается на странице бага и странице «edit attachment», рядом с аббревиатурой установившего флаг пользователя. Например: Иван: review [ + ].
Аналогично показывается запрошенный флаг, только в скобках показывается имя пользователя, у которого запрошена установка флага, например Иван: review [ ? ] (Бибичев).
Отчеты и графики
В дополнение к стандартному списку багов, багзилла имеет некоторые аналитические возможности — просмотр количества зарегистрированных багов в виде таблиц и графиков, с возможностью задания среза (перспективы) агрегации, + графики показывающие динамическое изменение состояния багов по времени.
Отчеты
Отчет представляет собой некий информационный срез о текущем состоянии базы зарегистрированных багов. Можно сделать отчет как обычным, HTML-табличным, так и графическим, с различными видами графиков: линейными, круговыми, гистограммы (line/pie/bar), и переключаться между этими режимами просмотра онлайн.
Очень удобно, что эти отчеты задаются с помощью стандартного интерфейса запросов и компактного интерфейса, определяющего выбор и расположение одного до трех измерений, по которым будет идти агрегация («трехмерная агрегация» — это когда на выходе будет соответственно набор двухмерных таблиц или графиков).
Например, можно выбрать в поисковой форме «все баги в продукте XXX» и затем отрисовать их серьезность относительно каждого компонента продукта, чтобы увидеть, какой компонент имеет наибольшее число серьезных проблем.
Или разработчик может выбрать все «свои» баги, распределив их по «критичности» и своей оценке приоритета, получив следующую таблицу, где каждая ячейка (например, «(major,P2)=> 2») является гиперссылкой на выборку соответствующих багов (т. е., в данном случае, двух багов, у которых, в дополнению к условиям общего запроса «Severity=major», а «Priority=P2»):
Priority
Severity P2 P3 P4 P5 Total
major 2 . 1 . 3
normal 8 1 1 . 10
minor . . 2 2 4
trivial . 1 . . 1
enhancement . . 1 1 2
Total 10 2 5 3 20
От выборки багов можно снова перейти к таблице и продолжить детализацию далее
(см. описание «Summary report» в #Списки багов).
После того как вы заполнили параметры выборки и вызвали «Generate Report», вы можете переключаться между форматами «HTML», «CSV», «Bar», «Line», «Pie» (Формат «Pie» доступен если вы определили только одну горизонтальную ось). Остальные интерфейсные элементы интуитивно понятны — можно изменять размер картинки, если текст наползает графику или слишком узкие столбцы гистограмм.
В нашей инсталляции, кроме числа багов, можно просматривать агрегированные временные параметры бага:
Remaining time;
Estimated time.
Т.е. в вышеприведенном примере, разработчик может оценивать свою загрузку в временных единицах, сколько часов требуется от него на баги различной серьезности (и поможет например, ответить на вопрос — можно ли будет позволить себе отпуск в ближайший месяц или нет):
Priority
Severity P2 P3 P4 P5 Total
major 32 . . . 32
normal 47.5 184 . . 231.5
minor . . . 192 192
trivial . 5 . . 5
enhancement . . 30 3 33
Total 79.5 189 30 195 493.5
Динамические графики (Charts)
Динамические график, чарт (chart) — это просмотр эволюции состояния базы багов по времени.
В данный момент в Bugzilla есть две системы построения таких графиков — «Old Charts» и «New Charts». «Old Charts» — это старая, давно используемая система, она отображает только изменения статусов и решений багов для каждого продукта. Она более не поддерживается и не развивается и будет вскоре исключена из системы. Развиваться будет система «New Charts», которая позволяет отрисовывать все, что можно задать поисковым запросом.
Оба системы требуют, чтобы администратор настроил скрипт собирающий данные.
Каждая отдельная линия в чарте представляется датасетом «data set», которые упорядочены в категории и подкатегории. Автоматически опеределяются категории/подкатегории на основе отношений Продукт/Компонент (для всех продуктов и компонентов), но также можно определять и любые другие категории.
Датасеты могут быть публичными, которых могут видеть все, или приватными, доступными только создателю. Причем сделать датасет публичным могут только администраторы.
Датасеты, даже приватные не должны пересекаться по набору (Категория, Подкатегория, Имя). Поэтому личные датасеты лучше заводить под Категорией со своим именем.
Создание Динамических Графиков
Для создания чарта, надо для каждого нужного датасета, выбрать его в списке и нажать «Add To List». В списке «List Of Data Sets To Plot» вы можете задать название-заголовок для каждого отображаемого датасета, также можно заказать суммирование подмножества выбранных датасетов (т. е. можно просуммировать датасеты представляющие баги в состоянии RESOLVED, VERIFIED и CLOSED для выбранного продукта, тем самым получив полное число исправленных багов). Ошибочно добавленный датасет можно исключить с помощью чекбокса и «Remove». Если вы добавили больше чем один датасет, то в списке автоматически появится линия «Grand Total». Если она не нужна, то ее можно также удалить, как и любую другую линию.
Также можно выбрать отрисовку только в определенном диапазоне дат, и аккумулирование результатов, т. е. режим, когда каждая линия представляет собой сумму своего датасета и нижележащей линии, и верхняя линия представляет собой сумму всех датасетов. Лучше попробуйте, это проще, чем пытаться обьяснить.
Для всех выбранных в список датасетов, если вы являетесь его владельцем или администратором можно редактировать его параметры — название, частоту и т. п.
По окончании настроек нажмите «Chart This List» для получения чарта.
Создание новых датасетов
Для создания нового датасета следуйте ссылке «create a new data set» на странице «Create Chart». Там вы, используя стандартный интерфейс выбора определите нужную выборку, а внизу страницы, определите категорию, подкатегорию и имя для нового датасета.
Если вы обладаете достаточными полномочиями, вы можете сделать датасет общедоступным, и сделать частоту сбора данных меньшей, чем неделя (значение по умолчанию).
Настройки пользователя
После того, как вы войдете в систему, вы можете поменять личные настройки Bugzilla, по ссылке «Edit prefs» внизу страницы.
Настройки разбиты на три группы-закладки:
Account Settings
На этой закладке, вы можете менять основную информацию вашей личной записи — пароль, e-mail, настоящее имя. По соображениям безопасности, при изменении любых параметров на этой странице, вы должны подтвердить изменение вводом своего пароля. Если вы меняете своей email, то по обоим (старому и новому) адресам будет выслано письмо со ссылкой на подтверждение изменения.
Email Settings
Эти настройки определяют когда и сколько писем будет вам слать Bugzilla.
Если вы хотите получать максимальное объем писем — нажмите на кнопку «Enable All Mail». Если не хотите получать почту от Bugzilla вообще — нажмите «Disable All Mail».
Администратор Bugzillы может также заблокировать получение почты пользователем через добавление имени пользователя в файл data/nomail. Но такие крутые меры применяются в исключительных случаях — например, для аккаунтов уволившихся сотрудников.
Более детальную настройка описана ниже.
«Global options»
Раздел «Global options» содержит (пока?) только настройки извещений по флагам (см. #Флаги):
«Email me when someone asks me to set a flag»
известить, если кто-то адресовал к вам «запрошенный флаг».
«Email me when someone sets a flag I asked for»
известить, если кто-то ответил на (установил в «+» или «-») запрошенный вами флаг.
«Field/recipient specific options»
Если вы хотите получать почту, но не во всех случаях, то используйте таблицу «Field/recipient specific options». Каждая запись в таблице соответствует событию бага (новый комментарий, изменение приоритета и т. п.). Колонки в таблице соответствуют вашей связи с багом:
Reporter
Вы являетесь инициатором бага, т. е. вы указаны в поле бага «Reporter».
Assignee
Вы являетесь ответственным за баг, т. е. вы указаны в поле бага «Assigned To».
QA Contact
Вы являетесь контроллером бага, т. е. вы указаны в поле бага «QA Contact».
CC
Вы в указаны списке «CC» бага.
Voter
Вы голосовали за баг. Ваш аккаунт будет показан по ссылке «Show votes for this bug» из окна бага.
Некоторые из описанных колонок могут отсутствовать, это определяется конфигурацией конкретной инсталляции.
Определите, в каких случаях вы хотите получать письма от Bugzilla, и в каких отношениях с багом должны вы при этом находиться и поставьте/оставьте галочки только в соответствующих клетках.
Bugzilla добавляет заголовок (не subject, а внутренний заголовок письма) «X-Bugzilla-Reason» всем рассылаемым письмам, описывая отношение получателя к упомянутому багу (AssignedTo, Reporter, QAContact, CC, Voter). Этот заголовок может быть использован для фильтрации почты.
По умолчанию, Bugzilla рассылает почту вне зависимости от того, кто был автором измения бага, и вы будете получать почту, даже если вы будете единственным лицом, связанным с багом. Если вы не хотите получать письма после своих собственных изменений, поставьте галочки в строке [ «but not when» ] «The change was made by me».
«User Watching»
Если вы введете список (разделенный запятыми) пользовательских аккаунтов (обычно совпадающих с email-адресами) в «Users to watch», то вы будете получать копию всех писем рассылаемых пользователю Bugzillой (с учетом настроек безопасности). Если вы не видите это поле в настройках — значит была Bugzilla установлена без этой возможности, и для ее активации нужно обратиться к системному администратору. В этом же разделе, в информационном поле «Users watching you» перечислены пользователи «следящие» за вашим потоком извещений от Bugzilla.
Permissions
Это чисто информационная страница-закладка, описывающая все права пользователя в текущей инсталляции — какие группы продуктов доступны, может ли пользователь редактировать баги и осуществлять административные функции.
Advanced
Просмотр Патчей
Важно: под патчем или исправлением, здесь имеется в виду именно патч, т. е. файл в специальном стандартном текстовом формате (patch) представляющий собой инструкции для специальной программы-патчера по проносу изменений. А не какие-то тексты программ или инструкции для человека.
Просмотр и ревизия исправлений в Bugzilla часто затруднена из-за недостатка контекста, несоответствующих форматов и других сложностей. «Patch Viewer» это дополнение Bugzilla, предназначенное для улучшения контекста, интеграции с Bonsai, LXR, CVS.
«Patch Viewer» позволяет:
Просмотр исправлений с раскраской, в режиме «side-by-side», а не интерпретация сырого содержимого исправления;
Просмотр разницы между двумя исправлениями;
Получение контекстной информации об исправлении;
Удобный просмотр исправления, с возможностью скрывать/раскрывать разделы;
Ссылки на разделы исправления для обсуждения или ревизии;
Ссылки на Bonsai или LXR для определения ответственности;
Создает исправления в унифицированном «diff»-формате.
В нашей инсталляции, мы не используем PatchViewer, т.к. есть гораздо более удобная интеграция с системой контроля версий (см. #Интеграция с CVS).
Просмотр в Patch Viewer
Самый удобный способ для просмотра патчей вызывается по ссылке «Diff» в списке «Attachments»,
либо ссылкой «View Attachment As Diff» на странице «Edit Attachment».
Изучение разницы между двумя исправлениями
Для просмотра разницы между двумя патчами, надо сначала в Patch Viewer войти в просмотр нового патча, затем выбрать в выпадающем списке нужный старый патч, и нажать на кнопку «Diff».
Получение большего контекста
Если патч был получен с помощью «cvs diff», то можно при просмотре больший контекст (больше строк кода окружающих изменение или добавление). Для этого можно ввести нужное число контекстных строк в текстовое поле над Patch Viewer («Patch / File / [textbox]») и нажать «Enter».
Дополнительно по ссылке «File» будут показаны изменения в контексте всего файла.
Схлопывание и раскрытие разделов Исправления
Можно просматривать исправления в разбивке по секциям-файлам — интерфейс понятен, нужно нажимать на ссылки «(+)» и «(-)» в каждом разделе или «Collapse All», «Expand All» (сверху страницы).
Ссылки на разделы Исправления
Ссылки на Bonsai
Чтобы перейти для детального изучения кода в Bonsai, надо проследовать по ссылке «Lines XX-YY» в заголовке раздела. Это будет работать даже если патч был к старой версии файла, т. к. Bonsai хранит все версии файлов.
Создание стандартного Diff
Патч может быть преобразован в «unified diff format» путем вызова ссылки «Raw Unified».
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
