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

From Free Pascal wiki
Jump to navigationJump to search
Line 16: Line 16:
 
* closed(закрыта): репортер проверил исправление и согласен с исправлением. Периодически решаемые проблемы, которые не были закрыты репортером, будут закрыты администратором системы отслеживания ошибок
 
* 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 ====
 
==== Removing duplicate entries ====

Revision as of 19:49, 6 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(дорожной картой).

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.

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.

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.

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.

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

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.

Referring to the Lazarus-CCR bug tracker

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.

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.

If you manage to reproduce the issue, then you can set the issue to Confirmed.

Assigning issues to yourself

If you think you can fix a reported issue, you can assign the issue to yourself.
Other users, including the original reporter will then know the issue is under someones attention.
Once you have provided a patch [1] 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.
If it turns out that you are unable to fix the issue you have assigned to yourself, simply unassign it.


GTK 1 issues

The gtk (i.e. the gtk version 1) widget set is not actively supported anymore by the Lazarus team, see 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.

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.

See also