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

From Free Pascal wiki
Jump to navigationJump to search
(Created page with "{{Moderating the bug tracker}} Этот документ содержит некоторые рекомендации по использованию [http://bugs.freepascal....")
 
 
(13 intermediate revisions by the same user not shown)
Line 7: Line 7:
  
  
−
== Life cycle of an issue ==
+
== Жизненный цикл проблемы ==
−
An issue can have the following states:
+
Проблема может иметь следующие состояния:
−
* new: it has entered in the bug tracker
+
* new(новая): она вошла в трекер ошибок
−
* acknowledged: the Lazarus team has seen the issue and has set its target
+
* acknowledged(признана): команда Lazarus увидела проблему и поставила перед собой цель
−
* confirmed: a member of the Lazarus team has duplicated the bug or agrees that the feature should be implemented
+
* confirmed(подтверждена): член команды Lazarus продублировал ошибку или согласен с тем, что функция должна быть реализована
−
* assigned: the issue has been assigned to a Lazarus developer, who will try to fix it
+
* assigned(назначена): проблема была назначена разработчику Lazarus, который попытается ее исправить
−
* resolved: the person to whom the issue was assigned thinks the issue can be closed. Then he also sets the resolution, for example '''fixed''' or '''not an issue'''.
+
* resolved(решена): лицо, которому была назначена проблема, считает, что проблема может быть закрыта. Затем он также устанавливает разрешение, например, '''фиксированный''' или '''не проблема'''
−
* closed: the reporter tested the fix and agrees with the fix. Periodically resolved issues that have not been closed by the reporter, will be a closed by the bug tracker administrator.
+
* closed(закрыта): репортер проверил исправление и согласен с исправлением. Периодически решаемые проблемы, которые не были закрыты репортером, будут закрыты администратором системы отслеживания ошибок
  
−
== How can moderators support the Lazarus developers? ==
+
== Как модераторы могут поддерживать разработчиков Lazarus? ==
  
−
=== Acknowledging issues ===
+
=== Признание проблем ===
−
==== Setting the target ====
+
==== Установка цели ====
−
The most important step when you acknowledge an issue, is that you set the target field. The target field helps the Lazarus developers to prioritize their bug fixing effort. Generally there are three options: '''next minor release''' (e.g. 1.6.2), '''post next major release''' (e.g. 1.8) or '''post next major release''' (e.g. post 1.8). For an explanation of these options, see [[Road To 1.0#1.0 or after 1.0]].
+
Самый важный шаг при подтверждении проблемы заключается в том, что вы устанавливаете целевое поле. Поле назначения помогает разработчикам 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: patches, regressions (i.e. things that work in the current release, but got broken in the svn version) and crashes that can cause data loss.
+
* '''next minor release''': патчи, регрессии (то есть то, что работает в текущем выпуске, но не работает в версии SVN) и сбои, которые могут привести к потере данных.
−
* next major release: improvements, major design changes, new features.
+
* '''next major release''': улучшения, серьезные изменения дизайна, новые функции.
−
* post next major release: things that are not likely to be fixed or incuded in the next major release (e.g. new widgetset).
+
* '''post next major release''': вещи, которые вряд ли будут исправлены или включены в следующий основной выпуск (например, новый набор виджетов).
  
−
There are two fields for the target:  
+
Для цели есть два поля:
−
* LazTarget, which can be used to select issues for several (sub-)projects at once, for example Lazarus, Lazarus/packages and Lazarus/patches.  
+
* LazTarget, который можно использовать для выбора проблем сразу для нескольких (под-)проектов, например, Lazarus, Lazarus/packages и Lazarus/patches.  
−
* Target version, which is used by the [http://bugs.freepascal.org/roadmap_page.php road map].
+
* Target version (целевая версия), которая используется [http://bugs.freepascal.org/roadmap_page.php road map](дорожной картой).
  
−
==== Removing duplicate entries ====
+
==== Удаление повторяющихся записей ====
−
When looking at a 'new' issue, you may need to remove duplicates that have arisen because people submitted the same issue more than once. Sometimes the bugtracker takes a long time to process the new report and the reporter gets impatient and clicks on submit again. Such 'issues' can be deleted.
+
При рассмотрении «новой» проблемы вам может потребоваться удалить дубликаты, возникшие из-за того, что люди представили одну и ту же проблему более одного раза. Иногда обработчику ошибок требуется много времени для обработки нового отчета, и репортер теряет терпение и снова нажимает на кнопку «Отправить». Такие «проблемы» могут быть удалены.
  
−
==== Referring questions to the mailing list and forums ====
+
==== Направление вопросов в список рассылки и форумы ====
−
If an issue doesn't describe a bug, but is only question (or the reporter doesn't know how to use certain feature) you can refer him to the mailing list and/or the forums to ask his question. Then you can resolve the issue with resolution "'''no change required'''". If you wish, you can provide a short answer to his question, but the bug tracker is for entering bugs and feature requests, not for providing support.
+
Если проблема не описывает ошибку, а является лишь вопросом (или репортер не знает, как использовать определенную функцию), вы можете направить его в список рассылки и/или на форумы, чтобы задать его вопрос. Затем вы можете решить проблему с заключением "'''no change required'''"(никаких изменений не требуется). При желании вы можете дать краткий ответ на его вопрос, но средство отслеживания ошибок предназначено для ввода ошибок и запросов функций, а не для предоставления поддержки.
  
−
==== Adding relations to other issues ====
+
==== Добавление взаимосвязей с другими вопросами ====
−
The bug tracker supports setting relations between issues.  
+
Отслеживание ошибок поддерживает настройку взаимосвязей между проблемами.
  
−
The weakest relation is '''Related'''. This merely links the two issues. This can be useful since if you fixed one issue, it may fix the related issue(s) too.
+
Самое слабое отношение - '''Related''' (Связанный). Оно просто связывает две проблемы. Это может быть полезно поскольку, если вы исправили одну проблему, это может исправить и связанные проблемы.
  
−
If two reports decribe the same issue, then you can set '''Duplicate of''' to the newest report. The other report then receives a link to that issue with '''Has duplicate'''.
+
Если два отчета описывают одну и ту же проблему, вы можете установить пометку '''Duplicate of''' (Дубликат чего-то...) для самого нового отчета. Другой отчет затем получает ссылку на эту проблему с пометкой '''Has duplicate''' (Имеется дубликат).
  
−
You can use the '''Parent - Child''' relation between two issues to describe dependency. In order to fix the '''Parent''' issue, the '''Child''' issue must be fixed first. Sometimes it is usefull to ''clone'' a (big) issue and describe part of it in a separate '''Child''' issue.
+
Вы можете использовать отношение '''Parent - Child''' (Родитель - Потомок) между двумя вопросами для описания зависимости. Чтобы исправить проблему '''Parent''' (Родитель), сначала нужно решить проблему '''Child''' (Потомок). Иногда полезно ''клонировать'' (бОльшую) проблему и описать ее часть в отдельной '''Child''' (у потомка) проблеме.
  
−
==== Moving to the patches subproject ====
+
==== Переход к подпроекту патчей ====
−
Patches can be moved to the patches subproject. Patches are more visible there and can be managed separately from other issues.
+
Патчи могут быть перемещены в подпроект патчей. Патчи там более заметны и могут управляться отдельно от других проблем.
  
−
==== 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 09: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 по умолчанию.

См.также

  • Как мне создать отчет об ошибке - общая информация о том, как отправлять сообщения об ошибках, что следует освещать в отчете об ошибках и как использовать систему отслеживания ошибок..
Retrieved from "http://wiki.freepascal.org/index.php?title=Moderating_the_bug_tracker/ru&oldid=126304"