|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Участник:Nadezhdazharinova/Песочница2Материал из CustisWiki Логотип Bugzilla Bugzilla — система отслеживания ошибок, разрабатываемая Mozilla Foundation.
СодержаниеВведениеКлючевым понятием системы является Bug (баг) — некоторое задание, запрос, рекламация по поводу ошибки в системе или просто сообщение, требующее обратной связи. Баги регистрируют и предоставляют заинтересованным лицам целостную информации о состоянии этого issue, включая интерфейсы редактирования, запроса и поиска, механизмы почтового и RSS-оповещений. Bugzilla используют многие компании и организации по всему миру. Из наиболее известных: NASA, IBM, Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office. Анатомия багаСущность Bug имеет набор атрибутов, работа с которыми — редактирование и запросы — является основными сценариями использования Bugzilla. Рассмотрим эти атрибуты. .jpg)
Структурные атрибуты1. Product (Продукт) - основной атрибут, задающий структуру. Каждый Product состоит из набора Компонентов. Можно включить классификацию продуктов — дополнительное подразделение продуктов на группы (исключительно двухуровневое), что отразится на интерфейсе заведения новых багов и на интерфейсе запросов. 2. Component (Компонент) - дополнительная структурная классификация. В зависимости от выбранного компонента баг может иметь разный набор компонентов. Атрибуты жизненного цикла1. Status (Статус) - основной атрибут, определяющий текущее состояние бага. Отражает меру активности бага от начального состояния, когда он еще не подтвержден как баг, до завершения, когда баг исправлен/решен, что подтверждено Службой Качества. Набор состояний зависит от конкретной инсталляции и настроек Bugzilla. Стандартный набор:
Также можно использовать:
3. Диаграмма Жизненный цикл бага (он же граф переходов состояний, workflow) жестко задан в коде и представлен ниже, на графе.
Связанные пользователи
Описание бага1. Summary - аннотация задачи/проблемы одним предложением. По правилам хорошего тона при регистрации нового бага следует дублировать (не обязательно дословно) содержимое Summary в первом комментарии. Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага. Конечно, доступна история изменений, но лучше зафиксировать историю в комментариях, которые отображаются всегда. 2. Version - номер версии продукта (компонента продукта), в которых наблюдается описанная проблема. 3. Priority - приоритет бага, указывается Assigned To пользователем на основе собственной оценки. Менять приоритет у чужих багов неправильно. Стандартный набор значений — от P1 (наивысший приоритет) до P5 (наименьший). 4. Severity - критичность возникшей проблемы. Список допустимых значений настраивается, стандартный набор:
5. Target (Target Milestone, Веха) - здесь указывается веха (версия, стадия) проекта, к которой баг должен быть решен. Не путать с Version. Например, баг может описывать ошибку, возникшую в версии 1.17, которую было решено исправить к версии 1_21. Веха не обязательно привязана к версии продукта, она может быть привязана к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут Milestone URL, содержащий ссылку на документ с именованными и описанными вехами, то есть где будет приведен некоторый Roadmap проекта. 6. Comments - комментарии к багу. Первый — это Description, остальные в форме редактирования бага именуются Additional Comments. Bugzilla рассылает всем связанным с багом пользователям комментарии по почте. В нашей инсталляции Bugzilla есть возможность «Silent» комментариев (checkbox Silent), уведомления о которых не рассылаются по почте. Использовать Silent следует только в том случае, когда информация в комментарии действительно мало интересна — например, worklog-запись о выполненной промежуточной (не решающей баг) работе, или если основная ценность записи - регистрация личных трудозатрат (см. Учет времени (Time tracking)). Не стоит злоупотреблять комментариями, превращая баг в форум. Для обсуждения постановки задачи, продуктивней завести ассоциированную с багом статью в Wiki-системе, и обсуждать там (см. Интеграция с Wiki). Зависимости между багамиВ Bugzilla регистрируется только один единственный вид зависимостей: «баг X зависит от решения бага Y». Нет разделения структурных зависимостей вида «проблема X подразделяется на проблемы X1,X2,X3» и сетевых зависимостей общего вида, но в целом ничто не мешает представлять структурные зависимости в общем виде («баг X зависит от решения багов X1,X2,X3»). Зарегистрированные зависимости видны и при просмотре атрибутов отдельно выбранных багов, и могут быть просмотрены в виде ориентированного графа вида:
В нашей инсталляции Bugzilla 3 графы зависимостей имеют две дополнительные особенности:
В нашей инсталляции Bugzilla показывается также активность по блокирующим багам, а именно:
Blockers completed ~16%,
last changed 2009-02-12 12:57:45
Прочее
В нашей инсталляции Bugzilla можно пользоваться автоматической связью между багом и ассоциированной с каждым Component'ом Wiki-системой, в которой можно делать пристойно отформатированную постановку задачи и даже вести ее обсуждение (См. Интеграция с Wiki).
Набор ключевых слов «глобальный», общий для всех продуктов внутри инсталляции Bugzilla, поэтому рекомендуется ответственно относиться к заведению каждого нового ключевого слова, чтобы не замусоривать общее пространство.
Атрибуты, не используемые в нашей инсталляции Bugzilla:
Поиск баговОсновные атрибутыНа странице Bugzilla Search представлен интерфейс для поиска любых зарегистрированных багов, комментариев и патчей. Интерфейс позволяет задать поисковые значения для всех перечисленных полей бага, причем для некоторых полей может быть задано несколько значений из домена (с помощью списков со множественным выбором). Если значение не выбрано — атрибут бага может принимать любое значение. Хранение запросовЛюбой выполненный запрос можно сохранить под выбранным именем (Remember Search As). Ссылка на сохраненный поиск отобразится в линейке Saved Searches, результат запроса можно будет получить за один клик, перейдя по ссылке. Временные условияМожно накладывать временные условия на изменение бага, запрашивая только баги, по которым было какое-либо движение (изменение атрибутов, комментарии) в определенном интервале времени — см. группу полей Bug Changes. Интервал времени можно задавать как в абсолютной форме (дата в формате YYYY-MM-DD), так и в форме, относительной текущей дате. Можно сделать хранимый запрос, показывающий только баги, измененные в течение предшествующих 24 часов (или недели, месяца). Можно использовать слова:
Можно добавить перед относительными датами знак +, это будет означать, что относительная дата не вычитается из Now, а прибавляется (в будущее). Полнотекстовый поискНачиная с версии 3.0 Bugzilla поддерживает честный полнотекстовый поиск по MySQL FULLTEXT-индексам, а с нашими доработками — и русскоязычную морфологию через стеммер Портера Lingua::Stem::Ru (порт из snowball). То есть по слову «завтрака» ищется и «завтрак», и «завтраков» и пр. Искать по словам можно из двух мест: со страницы поиска и из поля Quicksearch в шапке и подвале страниц Bugzilla. По умолчанию ищутся баги, содержащие в описании и/или комментариях все введённые слова с учётом морфологии. Однако, также действует специальный синтаксис, на самом деле совпадающий с синтаксисом MySQL Fulltext Boolean Search. При встрече во введённом запросе любого элемента этого синтаксиса запрос автоматически переключается в режим поиска любого из введённых слов, если не указано обратное. Описание синтаксиса:
Слова короче 3 символов в поиске не учитываются. 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» «флаг_утвердить+» (аналогично с ?,-) В Bugzilla 3.0 появилась возможность, ранее имевшаяся только в нашей версии — подзапросы по сохранённым запросам поиска в лице операций matched by saved search (присутствует в списке, возвращаемом запросом таким-то), и not matched by saved search (отсутствует в списке, возвращаемом запросом таким-то). Например, вы можете сформулировать условие «Блокируется багом из списка, возвращаемого сохранённым запросом поиска My Bugs» — для этого нужно выбрать поле Depends On, операцию matched by saved search и значение My Bugs. Чуть менее тривиально: можно задавать и запросы вида «найти все мои баги в открытом состоянии, для которых все блокирующие выполнены». Для этого просто нужно создать сохранённый запрос, находящий все выполненные баги, и подменить в запросе из предыдущего абзаца My Bugs этим запросом. Желательно, чтобы вспомогательные запросы возвращали небольшое число багов, иначе это сильно влияет на скорость ответа. Также весьма желательно при использовании этих условий задавать дополнительные, «простые» условия фильтрации. Заметим, запросы типа «баги, у которых нет блокирующих или «баги, у которых нет зависимых» можно реализовать стандартными условиями типа: NOT(Depends On "contains regexp" "[0-9]+" ) NOT(Blocks "contains regexp" "[0-9]+" ) Списки баговПосле выполнения запроса система возвращает выборку — список удовлетворяющих запросу багов. Формат этого списка настраиваемый, по ссылке Change Columns можно настроить набор показываемых в списке атрибутов. Также можно включить настройку Stagger headers — разнесение заголовка таблицы списка на два уровня. После выбора списка его можно отсортировать щелчками по заголовкам колонок (что приводить к сортировке списка в порядке возрастания выбранного атрибута-колонки). Другие полезные возможности вызываются ссылками, расположенными внизу списка:
Также есть 3 кнопки:
В нашей инсталляции Bugzilla также есть пункты:
Создание баговСоздание багов вручнуюПроцедура следующая:
Для быстрого заведения багов по образцу уже созданных — например, если происходит декомпозиция крупной проблемы на мелкие — можно применять клонирование бага. Создание бага клонированием другого багаИмпорт из Excel-файлаBugzilla 3.0 поддерживает массовый импорт багов из Excel-файлов — как бинарных Система подразумевает, что первая строка Excel-файла содержит заголовки колонок, а последующие — описания багов. Обязательными полями бага являются Product, Component и Summary. Процедура импорта багов из Excel-файла следующая. Сначала вы выбираете Excel-файл и устанавливаете начальные параметры импорта. Далее система разбирает загруженный файл и отображает его на веб-странице для проверки и изменения каких-либо полей или сопоставления полей колонкам таблицы. После проверки и нажатия Import selected bugs отображается страница с результатами импорта:
Для запуска Excel-импорта:
После нажатия кнопки Parse File будет показана страница с таблицей так, как её видит система. Если колонки в Excel-файле имели названия, совпадающие с названиями полей в Bugzilla, они автоматически сопоставятся нужным полям бага. Если автоматического сопоставления не произошло, кликом на название колонки можно выбрать нужное поле из выпадающего списка. Значения полей (то есть значения ячеек) должны соответствовать значениям полей в Bugzilla. Все поля отображаются редактируемыми, вы можете исправить любые значения, если увидите несоответствия. По результатам автоматической проверки существующих импортированных багов из списка будут установлены флажки слева каждой строки. По нажатию кнопки Import selected bugs будет предпринята попытка импорта только помеченных флажками багов. После успешно выполненного импорта вы увидите ссылку Import another Excel file — you can bookmark this link as a template. В этой ссылке сохранена информация о сопоставлении полей и значениях полей для всех багов по умолчанию. Поэтому, переходя по ней, вы сможете импортировать другой файл того же формата без лишних усилий. Также вы можете сохранить ссылку в закладки браузера для использования в будущем. Редактирование баговРедактирование багов необходимо для поддержания (и распространения по заинтересованным лицам) актуальной информации по обозначенной в описании бага проблеме или задаче. Редактирование бага включает изменение значений атрибутов бага (ведется история их изменения и написания комментариев). Основной принцип трекинга — регистрация и хранение истории всех изменений. Поэтому комментарии не удаляются после их добавления. Кроме текстовых комментариев, можно также добавлять различные вложения (attachments) — логи ошибок, скриншоты, примеры патчей (patches) и др. В основном редактированием основных атрибутов бага занимаются связанные с багом пользователи, указанные в атрибутах Reporter, Assigned To и QA Contact. Регламент работы с багом жестко не определен, любой пользователь, обладающий соответствующими правами, может изменять состояние и атрибуты бага. Впрочем, обычно:
Если в инсталляции Bugzilla включены функции регистрации времени (например, параметр timetrackinggroup), то можно регистрировать предварительную оценку сложности задачи и с каждым комментарием свои трудозатраты, корректировать оценку оставшийся работы (См. Учет времени (Time tracking)). В окне редактирования бага можно выяснить различные аспекты решаемой проблемы, зарегистрированные в Bugzilla:
КомментарииЗаметим, что комментарии к багу нельзя редактировать задним числом (это принципиальная позиция), разве что член специальной группы insidergroup может сделать их private — невидимыми для обычных пользователей. В нашей инсталляции Bugzilla можно воспользоваться ссылкой Preview (например, проверить, правильно ли гиперлинкуются ссылки, см. Автоматические ссылки), и убедившись, что все хорошо, вернуться кнопкой браузера Назад и выполнить Commit. В стандартной инсталляции для этого можно использовать страничку c адресом вида http://bugs.office.custis.ru/bugs/page.cgi?id=linkify.html Клонирование багаДля быстрого заведения новых багов (схожих с имеющимися) — например, если необходимо выделить подзадачу из крупной задачи, можно применять клонирование бага:
Клонирование бага приводит к созданию бага, унаследовавшего все атрибуты и являющегося блокирующим для исходного (родительского) бага. Впрочем, при клонировании можно редактировать родительские атрибуты и отказаться от блокирования родительского бага. В нашей инсталляции Bugzilla также можно клонировать в баг любой комментарий исходного бага ссылкой clone to other/same/int product на комментарии. Полезности BugzillaАвтоматические ссылкиКомментарии в Bugzilla разрешены только plain текстом, то есть печатая<U>вы получите не подчеркнутый текст, а <U>. Также нет списков и иных структурных элементов. Тем не менее, Bugzilla делает гиперссылки для определенного рода комментариев, например распознаются и гиперлинкуются основные типы URL:
Дополнительно гиперлинкуются ссылки на внутрибагзильные элементы (баги, комменты, вложения):
Интеграция с системами контроля версийОчень важно описать связь между багами (заданиями или сообщениями об ошибках) и производимым (исправляемым) разработчиком артефактом — программным кодом (включая документацию). В нашей Компании весь код (то есть практически все производимое разработчиком) находится в репозиториях принятых в Компании систем управления версиями CVS и Subversion и Git. Наша инсталляция Bugzilla интегрирована с системой ViewVC, в которую оперативно загружается информация о всех правках в CVS- и Subversion-репозиториях Компании. Поэтому, если при работе над багом XXX ведутся правки файлов, находящихся под CVS или Subversion, при фиксации (выполнении commit) не нужно писать длинных комментариев, описывающих суть изменений, а достаточно указать номер бага. Например, выполнить cvs commit -m "Bug 1234" Комментарий можно вводить и через опции командной строки, и через редактор, см. ссылки на документацию в CVS, Subversion. При соблюдении этого правила для каждого бага можно найти все commit'ы, в комментариях к которым указан номер этого бага, с помощью ссылки Look for Bug in CVS, SVN, Git на странице бага. Ранее похожую функцию выполнял Bonsai, однако был сделан переход на ViewVC по причине поддержки не только системы контроля версий CVS, но также и Subversion последним. Посему ссылки Look for Bug in CVS, SVN, Git теперь ведут именно в ViewVC. Интеграция с WikiBugzilla не является инструментом, подходящим для совместной работы над любым документом, поэтому при возникновении спорной или дискуссионной ситуации, когда нужно выработать постановку задачи, нужно использовать подходящий для этого инструмент - Wiki-систему. В нашей инсталляции Bugzilla дополнительно к возможностям автоматических ссылок можно делать читаемые гипертекстовые ссылки на статьи (разделы статей) в CustisWiki, например: wiki:Bugzilla#Автоматические_ссылки wiki:[[Bugzilla#Автоматические ссылки]] будет ссылаться на Bugzilla#Автоматические_ссылки. Если при работе над багом требуется сделать документ-постановку задачи и/или провести его обсуждение, можно воспользоваться ссылкой Look for Bug in Wiki на странице бага и перейти к одноименной с багом статье Bug XXX для чтения/редактирования/обсуждения. Рекомендуется после заведения статьи выполнить ее переименование (закладка move/переименовать) в более понятное название, например «Ошибка ORA-YYY при загрузке каталога (Bug XXX)», copy-paste атрибута Summary. Таким образом, будет создана статья с смысловым заголовком и статья-перенаправление «Bug XXX». Однако, стоит помнить, что в CustisWiki не стоит помещать конфиденциальную информацию, так как тут уже не действует система прав Bugzilla. Учет времени (Time tracking)Пользователи, входящим в группу timetrackinggroup, могут вести учет трудоемкости каждого бага. Ведется учет следующих полей:
Единица измерения — часы. Можно вводить дробные значения 1.5 = полтора часа. Time SummaryОтчет Time Summary для выбранного списка багов показывает зарегистрированные трудозатраты за заданный период с группировкой по месяцам, с разбивкой по сотрудниками или багам. Советы по использованию BugzillaВ процессе использования Bugzilla было сделано много доработок. О них можно очень кратко прочитать здесь Bugzilla: Список доработок#Доработки 3.x
Сделана специальная доработка (Bug:15001 и Bug:53638, которая позволяет присоединить текстовое вложение к багу через буфер обмена, без создания файла, с одновременным добавлением комментария, фиксацией времени и изменением некоторых атрибутов бага. Таким образом, если Вы получили текстовое сообщение об ошибке с большим стеком, то надо не писать комментарий, а добавить вложение, где вставить это сообщение в текстовое окно вложения (переключив radio button на Enter text), а ниже написать комментарий с краткой формулировкой ошибки.
Не вкладывайте простые тестовые примеры (например 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 List». Но если доброжелатель добавляя себя, добавит комментарий «Я, типа, себя добавил», это будет уже добавление комментария и обойдет вышеуказанный фильтр. Не используйте подписей в комментариях, особенно модные многострочные подписи с ASCII-картинками.
Если вы считаете, что отправленный вами баг некорректно помечен как DUPLICATE of another, задавайте вопросы-комментарии в вашем баге, а не в том, который считается багом-оригиналом. Смело добавляйте в CC List бага человека, который принял такое решение, если его нет. ФлагиФлаг — это некий атрибут, разновидность статуса, который может быть установлен на баг или вложение, чтобы указать, что этот баг/вложение находятся в некотором состоянии. Каждая инсталляция Bugzilla может определить свой собственных набор флагов, которых можно устанавливать на баг или вложение. Флаги в отличие от ключевых слов, имеющих «глобальную область» видимости для всех продуктов и компонентов, можно делать локальными, устанавливая набор продуктов и компонентов, в которых может быть установлен этот флаг. Вы можете установить или сбросить флаг, также разрешена функция запроса флагов - вы можете запрашивать другого пользователя установить флаг. Чтобы установить флаг, выберите +, или - из выпадающего списка Flags. Значение этих символов зависит от флага? в качестве примера, установление флага review в + может означать, что баг или вложение одобрены, а в - — отклонены. Чтобы сбросить флаг, выберите в выпадающем списке пустое значение. Чтобы сделать запрошенный флаг, установите флаг в ? и введите имя пользователя, у которого запрашиваете установку флага. В нашей инсталляции Bugzilla есть доработка, позволяющая не вводить пользователей для запрашиваемых флагов вручную, а выбирать из списка связанных с багом пользователей (Reporter, Assignee, QA Contact, CC List). Установленный флаг показывается на странице бага и странице edit attachment рядом с аббревиатурой установившего флаг пользователя. Например: Иван: review [ + ]. Аналогично показывается запрошенный флаг, только в скобках показывается имя пользователя, у которого запрошена установка флага, например Иван: review [ ? ] (Бибичев). Отчеты и графикиВ дополнение к стандартному списку багов Bugzilla имеет некоторые аналитические возможности — просмотр количества зарегистрированных багов в виде таблиц и графиков с возможностью задания среза (перспективы) агрегации, а также графики, показывающие динамическое изменение состояния багов по времени. ОтчетыОтчет представляет собой некий информационный срез о текущем состоянии базы зарегистрированных багов. Можно сделать отчет как обычным, 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 доступен, если вы определили только одну горизонтальную ось). Остальные интерфейсные элементы интуитивно понятны — можно изменять размер картинки, если текст наползает графику или слишком узкие столбцы гистограмм. В нашей инсталляции Bugzilla кроме числа багов можно просматривать агрегированные временные параметры бага:
В примере выше разработчик может оценивать свою загрузку во временных единицах, сколько часов требуется на баги различной серьезности, что поможет ответить на вопрос — можно ли будет позволить себе отпуск в ближайший месяц: 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 по ссылке Preferences. Настройки расположены на пяти вкладках: General preferences, Email preferences, Saved searches, Name and password, Permissoins. Рассмотрим подробнее каждую из них. General preferencesВкладка содержит простые настройки общеинтерфейсного плана. В нашей инсталляции Bugzilla дополнительно включены настройки:
Email preferencesЭти настройки определяют когда и сколько писем будет вам прислать Bugzilla. Если вы хотите получать все письма — нажмите кнопку Enable All Mail, если не хотите получать письма от Bugzilla вообще — нажмите Disable All Mail. Администратор Bugzilla может заблокировать получение почты пользователем через добавление имени пользователя в файл data/nomail. Такие меры применяются в исключительных случаях — например, для аккаунтов уволившихся сотрудников. Раздел Global options содержит (пока?) только настройки извещений по флагам):
Раздел Field/recipient specific options содержит настройки для определения случаев, когда вы хотите получать письма от Bugzilla, и в каких отношениях с багом вы должны при этом находиться. Поставьте/уберите галочки в соответствующих клетках. Каждая запись в таблице соответствует событию бага (новый комментарий, изменение приоритета и др.). Колонки в таблице соответствуют вашей связи с багом:
Почту также можно фильтровать по различным заголовкам X-Bugzilla-Что-Нибудь, присутствующих во всех письмах от Bugzilla (см. [[#Дополнительные email-заголовки|Дополнительные email-заголовки). По умолчанию Bugzilla рассылает почту вне зависимости от того, кто был автором изменения бага, и вы будете получать почту, даже если будете единственным лицом, связанным с багом. Если вы не хотите получать письма после своих изменений, поставьте галочки в строке but not when (overrides above): The change was made by me.
Раздел User Watching содержит пользователей, следящих за вашим потоком извещений от Bugzilla. Если вы введете список (разделенный запятыми) пользовательских аккаунтов (обычно совпадающих с email-адресами) в Users to watch, то будете получать копию всех писем, рассылаемых пользователю Bugzillой (с учетом настроек безопасности). В нашей инсталляции Bugzilla можно подписываться на почту других пользователей и подписывать (а также отписывать) других пользователей на себя.
Saved searches... добавить инфу ... Name and passwordНа этой вкладке вы можете изменить основную информацию вашей личной записи — изменить пароль, настоящее имя. По соображениям безопасности при изменении любых параметров на этой странице вы должны подтвердить изменение вводом своего пароля. PermissoinsЧисто информационная вкладка, описывающая все права пользователя в текущей инсталляции Bugzilla — какие группы продуктов доступны, может ли пользователь редактировать баги и осуществлять административные функции. Фильтрация писем от BugzillaBugzilla добавляет некоторые заголовки во все письма. В большинстве почтовых клиентов эти заголовки также можно использовать для фильтрации почты. Заголовки — это не subject, а внутренние заголовки письма, увидеть которые можно в свойствах письма или выбрав в почтовой программе пункт View Message Headers или подобный. Список заголовков:
Также есть набор заголовков, имеющих значением значение соответствующего атрибута бага:
Примеры: Задача 1: Фильтровать почту по багам, содержащую только изменения связанных багов. Решение: Заголовок X-Bugzilla-Added-Comments равен 0 и заголовок X-Bugzilla-Changed-Fields пуст. Задача 2: Перемещать в специальную папку письма по багам, назначенным на меня, созданным мной или содержащим вопрос ко мне. Решение: В Outlook создать правило, которое будет перемещать письма, содержащие в заголовке "X-Bugzilla-Reason: Assigned-To" или "X-Bugzilla-Reason: CC Assigned-To" или "X-Bugzilla-Type: request" или "X-Bugzilla-Reason: Reporter", в нужную папку. Просмотр ПатчейВажно: под патчем или исправлением здесь имеется в виду именно патч, то есть файл в специальном стандартном текстовом формате (patch), представляющий собой инструкции для программы-патчера по проносу изменений. А не какие-либо тексты программ или инструкции для человека. Просмотр и ревизия исправлений в Bugzilla часто затруднена из-за недостатка контекста, несоответствующих форматов и других сложностей. Patch Viewer это дополнение Bugzilla, предназначенное для улучшения контекста, интеграции с Bonsai, LXR, CVS. Patch Viewer позволяет:
В нашей инсталляции Bugzilla мы не используем PatchViewer, так как есть гораздо более удобная система просмотра версионных репозиториев ViewVC (см. Интеграция с системами контроля версий). СсылкиBugzilla в России; Bugzilla в Википедии; Bug Tracking системы (бесплатные). Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации. Статья реплицируется в Wiki4IntraNet. Внимание! Данная статья выбрана для репликации в SMWiki. |
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
Может также упоминаться (и с некоторыми оговорками использоваться) как:
Не злоупотребляйте этой возможностью!