Difference between revisions of "Moderating the bug tracker/ru"

From Free Pascal wiki
Jump to navigationJump to search
 
(7 intermediate revisions by the same user not shown)
Line 48: Line 48:
 
Патчи могут быть перемещены в подпроект патчей. Патчи там более заметны и могут управляться отдельно от других проблем.
 
Патчи могут быть перемещены в подпроект патчей. Патчи там более заметны и могут управляться отдельно от других проблем.
  
==== Referring to the fpc bug tracker ====
+
==== Ссылка на трекер ошибок fpc ====
If a bug is not in the IDE or the LCL, but in the RTL, FCL or the compiler, you can move the issue to the FPC project in the bug tracker.
+
Если ошибка не в IDE или LCL, а в RTL, FCL или компиляторе, вы можете в багтрекере переместить проблему в проект FPC.
  
==== Referring to the Lazarus-CCR bug tracker ====
+
==== Ссылка на багтрекер Lazarus-CCR ====
Some projects or components hosted on Lazarus-CCR use the Lazarus bug tracker for tracking issues. Those issues should not reside in the Lazarus project: you should move them to the Lazarus CCR bug tracker.
+
Некоторые проекты или компоненты, размещенные на Lazarus-CCR, используют багтрекер Lazarus для отслеживания проблем. Эти проблемы не должны находиться в проекте Lazarus: вы должны переместить их в багтрекер Lazarus CCR.
  
=== Confirming issues ===
+
=== Подтверждение проблем ===
Most of the time, the first step in fixing an issue is creating a small example program that demonstrates the issue. Reporters vary in the effort they make when submitting their initial report. Some people add test programs to their report (very nice), some people only add a code snippet (better than nothing) and some people add nothing at all. Not all reports provide adequate steps for others to reproduce the supposed issue. Going to the length of adding a small, compilable example program speeds identification and resolution of the issue you have identified.
+
В большинстве случаев первым шагом в решении проблемы является создание небольшой программы-примера, которая демонстрирует проблему. Репортеры различаются по усилиям, которые они прилагают при представлении своего первоначального отчета. Некоторые люди добавляют тестовые программы в свой отчет (очень приятно), некоторые добавляют только фрагмент кода (лучше, чем ничего), а некоторые вообще ничего не добавляют. Не все отчеты предоставляют адекватные шаги для воспроизведения предполагаемой проблемы другими. Добавление небольшого компилируемого примера программы ускоряет идентификацию и устранение выявленной вами проблемы.
  
If it is not clear from the Mantis bug report, you can ask the reporter to give steps to reproduce this issue and/or a test project.
+
Если это не ясно из сообщения об ошибке Mantis, вы можете попросить репортера описать подробнее шаги для воспроизведения этой проблемы и/или тестового проекта.
  
If you manage to reproduce the issue, then you can set the issue to '''Confirmed'''.
+
Если вам удалось воспроизвести проблему, вы можете установить ее статус на '''Confirmed''' (Подтверждено).
  
=== Assigning issues to yourself ===
+
=== Назначение проблемы себе ===
If you think you can fix a reported issue, you can assign the issue to yourself.<br>
+
Если вы считаете, что можете исправить сообщенную проблему, вы можете назначить ее себе. <br>
Other users, including the original reporter will then know the issue is under someones attention.<br>
+
Другие пользователи, включая первоначального репортера, уведомляются, что проблема находится под чьим-то вниманием. <br>
Once you have provided a patch [http://wiki.lazarus.freepascal.org/Creating_A_Patch] you then set the target to the next stable release and unassign the issue (assign to nobody). This will signal to the maintainers that a patch is being offered for review.<br>
+
После того, как вы предоставили [http://wiki.lazarus.freepascal.org/Creating_A_Patch патч], вы устанавливаете цель на следующий стабильный выпуск и отменяете проблему (никому не назначаете). Это сообщит майнтейнерам о том, что исправление предлагается для ознакомления. <br>
If it turns out that you are unable to fix the issue you have assigned to yourself, simply unassign it.
+
Если окажется, что вы не можете исправить проблему, которую вы назначили себе, просто отмените ее.
  
 +
=== Проблемы GTK 1 ===
 +
Набор виджетов gtk (он же gtk1) больше не поддерживается командой Lazarus, см. [http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/047069.html объявление]. Если взамен используется набор виджетов gtk2 и проблем не возникает, проблема может быть считаться решенной и ей будет присвоено приостановленное состояние.
  
=== GTK 1 issues ===
+
==Тэги==
The gtk (i.e. the gtk version 1) widget set is not actively supported anymore by the Lazarus team, see [http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/047069.html announcement]. If there is no problem when the gtk2 widget set is used instead, then the issue can be resolved with state suspended.
 
  
==Tags==
+
Ниже приведена таблица с тегами, используемыми для маркировки групп отчетов об ошибках, которые нелегко определить с помощью других параметров и их описания.
 
 
Below is a table with the tags utilized to mark groups of bug reports which aren't easily defined by the other options and their description.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
! Tag !! Description
+
! Тэг !! Описание
 
|-
 
|-
|gtk2||Represents all gtk2 specific bugs and is used to track what needs to be fixed before gtk2 becomes the default Linux widgetset.
+
|gtk2||Представляет все специфичные для gtk2 ошибки и используется для отслеживания того, что необходимо исправить, прежде чем gtk2 станет набором виджетов Linux по умолчанию.
 
|}
 
|}
  
==See also==
+
==См.также==
* [[How do I create a bug report]] general information on submitting bugs, what should be covered in a bug report, and using the bug tracker.
+
* [[How do I create a bug report/ru|Как мне создать отчет об ошибке]] - общая информация о том, как отправлять сообщения об ошибках, что следует освещать в отчете об ошибках и как использовать систему отслеживания ошибок..

Latest revision as of 08:07, 8 August 2019

Deutsch (de) English (en) français (fr) português (pt) русский (ru)

Этот документ содержит некоторые рекомендации по использованию багтрекера 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 по умолчанию.

См.также

  • Как мне создать отчет об ошибке - общая информация о том, как отправлять сообщения об ошибках, что следует освещать в отчете об ошибках и как использовать систему отслеживания ошибок..