Moderating the bug tracker/ru
Deutsch · English · Français · Português · Русский
Этот документ содержит некоторые рекомендации по использованию багтрекера Lazarus'а. Этот документ написан для двух групп:
- разработчиков Lazarus, которые попытаются исправить ошибки
- модераторов, которые поддержат решение проблемы, расставив приоритеты и убедившись, что они воспроизводимы.
Мы будем использовать термин команда Lazarus для обеих групп.
Жизненный цикл проблемы
Проблема может иметь следующие состояния:
- new(новая): она вошла в трекер ошибок
- acknowledged(признана): команда Lazarus увидела проблему и поставила перед собой цель
- confirmed(подтверждена): член команды Lazarus продублировал ошибку или согласен с тем, что функция должна быть реализована
- assigned(назначена): проблема была назначена разработчику Lazarus, который попытается ее исправить
- resolved(решена): лицо, которому была назначена проблема, считает, что проблема может быть закрыта. Затем он также устанавливает разрешение, например, фиксированный или не проблема
- closed(закрыта): репортер проверил исправление и согласен с исправлением. Периодически решаемые проблемы, которые не были закрыты репортером, будут закрыты администратором системы отслеживания ошибок
Как модераторы могут поддерживать разработчиков Lazarus?
Признание проблем
Установка цели
Самый важный шаг при подтверждении проблемы заключается в том, что вы устанавливаете целевое поле. Поле назначения помогает разработчикам Lazarus расставить приоритеты в своих усилиях по исправлению ошибок. Как правило, есть три варианта: next minor release(следующий минорный релиз) (например, 1.6.2), next major release(следующий основной релиз) (например, 1.8) или post next major release(опубликовать следующий основной релиз) (например, post 1.8). Объяснение этих параметров см. Road To 1.0#1.0 or after 1.0.
- next minor release: патчи, регрессии (то есть то, что работает в текущем выпуске, но не работает в версии SVN) и сбои, которые могут привести к потере данных.
- next major release: улучшения, серьезные изменения дизайна, новые функции.
- post next major release: вещи, которые вряд ли будут исправлены или включены в следующий основной выпуск (например, новый набор виджетов).
Для цели есть два поля:
- LazTarget, который можно использовать для выбора проблем сразу для нескольких (под-)проектов, например, Lazarus, Lazarus/packages и Lazarus/patches.
- Target version (целевая версия), которая используется road map(дорожной картой).
Удаление повторяющихся записей
При рассмотрении «новой» проблемы вам может потребоваться удалить дубликаты, возникшие из-за того, что люди представили одну и ту же проблему более одного раза. Иногда обработчику ошибок требуется много времени для обработки нового отчета, и репортер теряет терпение и снова нажимает на кнопку «Отправить». Такие «проблемы» могут быть удалены.
Направление вопросов в список рассылки и форумы
Если проблема не описывает ошибку, а является лишь вопросом (или репортер не знает, как использовать определенную функцию), вы можете направить его в список рассылки и/или на форумы, чтобы задать его вопрос. Затем вы можете решить проблему с заключением "no change required"(никаких изменений не требуется). При желании вы можете дать краткий ответ на его вопрос, но средство отслеживания ошибок предназначено для ввода ошибок и запросов функций, а не для предоставления поддержки.
Добавление взаимосвязей с другими вопросами
Отслеживание ошибок поддерживает настройку взаимосвязей между проблемами.
Самое слабое отношение - Related (Связанный). Оно просто связывает две проблемы. Это может быть полезно поскольку, если вы исправили одну проблему, это может исправить и связанные проблемы.
Если два отчета описывают одну и ту же проблему, вы можете установить пометку Duplicate of (Дубликат чего-то...) для самого нового отчета. Другой отчет затем получает ссылку на эту проблему с пометкой Has duplicate (Имеется дубликат).
Вы можете использовать отношение Parent - Child (Родитель - Потомок) между двумя вопросами для описания зависимости. Чтобы исправить проблему Parent (Родитель), сначала нужно решить проблему Child (Потомок). Иногда полезно клонировать (бОльшую) проблему и описать ее часть в отдельной Child (у потомка) проблеме.
Переход к подпроекту патчей
Патчи могут быть перемещены в подпроект патчей. Патчи там более заметны и могут управляться отдельно от других проблем.
Ссылка на трекер ошибок fpc
Если ошибка не в IDE или LCL, а в RTL, FCL или компиляторе, вы можете в багтрекере переместить проблему в проект FPC.
Ссылка на багтрекер Lazarus-CCR
Некоторые проекты или компоненты, размещенные на Lazarus-CCR, используют багтрекер Lazarus для отслеживания проблем. Эти проблемы не должны находиться в проекте Lazarus: вы должны переместить их в багтрекер Lazarus CCR.
Подтверждение проблем
В большинстве случаев первым шагом в решении проблемы является создание небольшой программы-примера, которая демонстрирует проблему. Репортеры различаются по усилиям, которые они прилагают при представлении своего первоначального отчета. Некоторые люди добавляют тестовые программы в свой отчет (очень приятно), некоторые добавляют только фрагмент кода (лучше, чем ничего), а некоторые вообще ничего не добавляют. Не все отчеты предоставляют адекватные шаги для воспроизведения предполагаемой проблемы другими. Добавление небольшого компилируемого примера программы ускоряет идентификацию и устранение выявленной вами проблемы.
Если это не ясно из сообщения об ошибке Mantis, вы можете попросить репортера описать подробнее шаги для воспроизведения этой проблемы и/или тестового проекта.
Если вам удалось воспроизвести проблему, вы можете установить ее статус на Confirmed (Подтверждено).
Назначение проблемы себе
Если вы считаете, что можете исправить сообщенную проблему, вы можете назначить ее себе.
Другие пользователи, включая первоначального репортера, уведомляются, что проблема находится под чьим-то вниманием.
После того, как вы предоставили патч, вы устанавливаете цель на следующий стабильный выпуск и отменяете проблему (никому не назначаете). Это сообщит майнтейнерам о том, что исправление предлагается для ознакомления.
Если окажется, что вы не можете исправить проблему, которую вы назначили себе, просто отмените ее.
Проблемы GTK 1
Набор виджетов gtk (он же gtk1) больше не поддерживается командой Lazarus, см. объявление. Если взамен используется набор виджетов gtk2 и проблем не возникает, проблема может быть считаться решенной и ей будет присвоено приостановленное состояние.
Тэги
Ниже приведена таблица с тегами, используемыми для маркировки групп отчетов об ошибках, которые нелегко определить с помощью других параметров и их описания.
| Тэг | Описание |
|---|---|
| gtk2 | Представляет все специфичные для gtk2 ошибки и используется для отслеживания того, что необходимо исправить, прежде чем gtk2 станет набором виджетов Linux по умолчанию. |
См.также
- Как мне создать отчет об ошибке - общая информация о том, как отправлять сообщения об ошибках, что следует освещать в отчете об ошибках и как использовать систему отслеживания ошибок..
From the Free Pascal wiki, page "Moderating the bug tracker/ru", as it stood on 2019-08-08 after a change by Zoltanleo, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's Licensing page. If you have concerns about this material, message the admin.