Материал из Mandriva Russian Community Wiki

Описание

Ошибка — это случай, при наступлении которого компонент дистрибутива Mandriva Linux (или другой продукт, поддерживаемый Bugzilla, например, веб-сайт Mandriva) не может выполнить своих функций.

Процесс

Об ошибках могут сообщать любые пользователи дистрибутива Mandriva Linux. Мы стараемся рассмотреть все отчёты об ошибках, но это не означает, что все ошибки будут решены именно в том порядке, который кажется составителю отчёта наилучшим. Мы стараемся везде, где это только возможно, корректно обработать неправильно адресованные или некорректные сообщения об ошибках.

Это означает, что проблемы, которые имеют место в поддерживаемых пакетах, должны быть решены везде, где это возможно. Если проблема не может быть решена, требуется полное разъяснение обстоятельств. Оба этих случая (решение ошибки или объяснение невозможности решения) интерпретируются как решение ошибки. Если ошибка является дубликатом уже известной ошибки, отчёт об ошибке не является корректным, ошибка выходит за рамки системы устранения ошибок или ошибку невозможно воспроизвести, такая ошибка должна помечаться как RESOLVED с соответствующим статусом и полным объяснением, составленным либо сопровождающим пакета либо членом команды Bug (Bug Squad). Эти случаи также интерпретируются как решение ошибки. Никакие другие результаты не могут считаться решением ошибки.

Отчёт

Об ошибках нужно сообщать в Bugzilla. При этом надо выбрать соответствующую версию дистрибутива и продукт. Отчёт об ошибке должен содержать полное описание проблемы и, если возможно, пошаговую инструкцию по воспроизведению ошибки. Любая существенная информация о среде, необходимая для воспроизведения ошибки: особое оборудование, особые пакеты, особые параметры настроек — должна включаться в отчёт. Предложенные исправления, включая патчи, приветствуются, но не являются обязательными.

Голосование

Всякий, кто имеет учётную запись в Bugzilla, может голосовать за ошибки. Голосование — это способ, с помощью которого можно заметить заинтересованность пользователей в исправлении ошибки. Голоса рассматриваются сопровождающими как один из факторов, влияющих на приоритет решения ошибки, и как инструмент наблюдения.

Наиболее раздражающие (по результатам голосов) ошибки

Наиболее востребованные (по результатам голосов) возможности

Сортировка

Все ошибки вначале попадают к команде сортировки (triage team). Прежде всего, команды сортировки должна решить, требует ли проблема вмешательства со стороны сопровождающего пакета.

Проблема не требует вмешательства сопровождающего

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

• отчёт об ошибке является дубликатом уже существующего отчёта. Это означает, что о такой ошибке в том же самом продукте и в том же самом релизе уже сообщалось. Отчёты об ошибках об одной и той же проблеме в разных релизах НЕ являются дублирующими. Члены команды сортировки должны присвоить дублируемым ошибкам статус RESOLVED DUPLICATE;

• проблема не подпадает под определение ошибки. Это может возникать в том случае, когда, например, отчёт об ошибке содержит просьбу или пожелание о создании дополнительной(ых) возможности(ей) в программном обеспечении, не поддерживаемом командой разработчиков Mandriva, или когда ошибка, о которой сообщил пользователь, является результатом некорректных действий самого пользователя. Члены команды сортировки ошибок, не подпадающих под определение «ошибка», должны установить статус RESOLVED INVALID или RESOLVED WONTFIX, за исключением того случая, когда запросы на улучшение являются допустимыми, этот случай рассматривается в следующем пункте;

• о проблеме не сообщалось ранее (т. е. она не является дубликатом) и она подпадает под определение ошибки, но было бы лучше, если бы она была решена на следующем этапе разработки. Некоторые проблемы не могут быть решены на уровне создания пакетов дистрибутива. Такие проблемы включают в себя, например, фундаментальные ошибки в коде приложений. В этом случае члены команды сортировки будут просить, чтобы пользователь сообщил об ошибке на соответствующий уровень разработки, используя наиболее очевидный метод сообщения об ошибках для этого проекта (например, если ошибка должна быть решена командой разработки GNOME, то сообщение об ошибке должно попасть в Bugzilla проекта GNOME). После этого, члены команды сортировки должны присвоить ошибке статус RESOLVED REPORTEDUPSTREAM, предоставив ссылку на отчёт об ошибке в апстриме соответствующего проекта. Если такая ошибка была найдена в Cooker, то как только она будет решена в апстриме, обновлённая версия будет включена в Mandriva Linux в разумно короткие сроки. Если такая ошибка была найдена в стабильном релизе, то это является лишь временным решением проблемы, т. к. новые версии не включаются в стабильные релизы по понятным причинам. Как только проблема будет решена в апстриме, команда сортировки или человек, сообщивший об ошибке, могут повторно открыть (re-open) ошибку, и она будет пересмотрена с позиции, является ли практичным включить апстрим-фикс в обновление для Mandriva Linux.

Проблема требует вмешательства сопровождающего

Проблемы, не подпадающие под описанные выше категории (проблема удовлетворяет определению «ошибка», о проблеме не сообщалось ранее, проблема может быть воспроизведена, проблема может быть решена на уровне создания пакетов), требуют действий со стороны сопровождающего. В этом случае член команды сортировки обязан убедиться, что от человека, сообщившего об ошибке, получена вся необходимая информация, которая позволила бы выставить ошибке соответствующий приоритет (priority) и важность (severity). Члены команды сортировки ни в коем случае не должны назначать ошибки сопровождающим, не убедившись предварительно, что вся необходимая информация была получена.

Если вся необходимая информация уже содержится в отчёте, ошибке просто присваивается статус ASSIGNED, и она назначается соответствующему сопровождающему. С этого момента времени ошибка попадает в зону ответственности сопровождающего.

Если информация по ошибке не полная, члены команды сортировки должны добавить ключевое слово NEEDINFO и прикрепить комментарий, извещающий человека, сообщившего об ошибке, о том, какой именно информации не хватает, а также, возможно, о том, как получить эту информацию. До тех пор, пока команде сортировки не будет представлена дополнительная информация, ошибка будет находиться в зоне ответственности человека, сообщившего об ошибке. Если такая информация не будет получена в течение разумного периода времени, или репортёр утверждает, что такую информацию предоставить невозможно, проблема не требует вмешательства сопровождающего и должна быть соответствующим образом обработана командой сортировки.

Команда сортировки также должна устанавливать приоритет и важность каждой ошибки. Сопровождающие используют эту информацию, планируя приоритетные задачи, поэтому к вопросу выбора приоритета ошибки и её важности нужно подходить ответственно. Приоритет отражает то, насколько срочно нужно исправить ошибку. Это зависит от того, насколько важна данная ошибка в контексте дистрибутива в целом. Важность ошибки показывает, насколько серьёзной является ошибка в контексте пакета. Таким образом, критическая ошибка в редко используемом пакете может иметь важность уровня «critical»(критическая), но приоритет уровня «low» (низкий), а небольшая ошибка в широко используемом пакете может иметь важность уровня «minor» (незначительный), но приоритет уровня «release_critical» (критичный для релиза).

Приоритет «release_critical» относится только к ошибкам Cooker и бэта-релизам и должен использоваться только для проблем, которые являются достаточно важными, т. е. это такие ошибки, которые снизили бы общее качество релиза, если бы их не исправили к моменту выхода релиза. Приоритет «high» (высокий) должен использоваться для проблем, которые достаточно важны, чтобы их приоритет возобладал над приоритетом решения других ошибок. Приоритет «low» должен использоваться для ошибок, которые достаточно тривиальны и/или приоритет которых ниже приоритета других ошибок. Во всех других случаях следует использовать приоритет «normal» (нормальный).

Важность уровня «critical» должна использоваться для ошибок, которые делают пакет чрезвычайно трудным в использовании (например, аварийное завершение программы, которое затрагивает большую часть использования программы или невозможность установки или запуска пакета). Важность уровня «major» должна использоваться для серьёзных проблем, которые затрагивают большую часть пакета, или в том случае, если пакет чрезвычайно не стабилен. Важность уровня «minor» должна использоваться для проблем, которые незначительно влияют на использование пакета, или в том случае, если такие проблемы затрагивают лишь небольшую часть пользователей и/или проявляются лишь в сравнительно небольшом количестве случаев. Важность уровня «trivial» должна использоваться для проблем, которые практически не оказывают никакого воздействия на использование пакета. Во всех остальных случаях следует использовать важность уровня «normal».

Как только команда сортировки закончила разбор ошибки, команда должна добавить к ошибке ключевое слово «Triaged».

Решение сопровождающего

Когда проблема требует действий со стороны сопровождающего пакета, и вся соответствующая информация была предоставлена репортёром, проблема попадает в зону ответственности сопровождающего. Сопровождающий может пометить ошибку как RESOLVED FIXED, как только исправление (fix) попадёт в репозиторий svn, но в случае стабильного релиза их ответственность на этом не заканчивается. Для поддерживаемых пакетов сопровождающий должен убедиться в официальном выпуске обновления, согласно политике пост-релизной поддержки. It is desirable that a link be posted in the original bug report to the update request bug report (where the two are different), to enable users to follow the status of the update. Для не поддерживаемых пакетов желательно, чтобы сопровождающий выпускал обновлённый пакет непосредственно в соответствующем репозитории.

Конечно, спектр всех возможных действий, необходимых для исправления ошибок, находится за пределами компетенции данной статьи. Как только исправленный пакет становится доступным в соответствующем репозитории, сопровождающий должен установить ошибке статус RESOLVED FIXED.

Сопровождающий имеет право ускорить процесс сортировки

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

«VERIFIED» и «CLOSED»

Статусы «VERIFIED» и «CLOSED» бесполезны в нашем процессе обработки ошибок, поэтому нет никакой надобности использовать их в Mandriva Bugzilla. Когда сопровождающий исправляет ошибку, она должна быть помечена как «RESOLVED» «FIXED». Если репортёр или команда bug (bug squad) хочет проверить закрытие ошибки, они могут это сделать следующим образом: если они подтверждают, что ошибка исправлена, то они просто оставляют «RESOLVED» «FIXED»; если они считают, что ошибка не исправлена, они могут повторно открыть ошибку.

Запросы на улучшение

Запросы на улучшение являются особым случаем в процессе слежения за ошибками в Mandriva. Допустимые запросы на улучшение содержат запросы дополнительных возможностей в таких пакетах программ, которые поддерживаются разработчиками Mandriva или являются их разработкой. Предложения к улучшению пакетов и программ, которые не были написаны сотрудниками Mandriva или которые не поддерживаются разработчиками Mandriva. Запросы на улучшение программ, которые не являются разработкой Mandriva и не поддерживаются её разработчиками, не считаются допустимыми запросами и подпадают под случай «проблема не требует вмешательства сопровождающего».

Команда сортировки, обрабатывая запросы на улучшения, должна удостовериться, что от репортёра было получено понятное объяснение новой возможности, и что поле «severity» (важность) установлено в значение «enhancement» (улучшение). После этого, команда сортировки должна присвоить ошибке статус «ASSIGNED» и назначить её соответствующему сопровождающему.

Сопровождающий не обязан принимать улучшение. Запрос на улучшение — это не ошибка, а это значит, что запросы не обязательно должны удовлетворяться. Сопровождающий сам принимает решение, что делать с запросом. Если запрос принят, то в отчёт должен быть добавлен комментарий, подтверждающий факт принятия. Как только запрошенное улучшение выполнено, и новый пакет, включающий это улучшение, становится доступным в соответствующем репозитории, сопровождающий должен присвоить статусу ошибки значение «RESOLVED» «FIXED». Если сопровождающий решил не принимать запрос, он должен добавить комментарий, поясняющий данное решение, и присвоить статусу значение «RESOLVED» «WONTFIX». Любой выбор сопровождающего является решением проблемы.