Difference between revisions of "Moderating the bug tracker/pt"
Line 1: | Line 1: | ||
{{Moderating the bug tracker}} | {{Moderating the bug tracker}} | ||
− | + | Este documento contém algumas linhas guias para usar o Lazarus [http://www.lazarus.freepascal.org/mantis/ bug tracker]. Este documento é escrito para dois grupos: | |
− | * lazarus | + | * desenvolvedores lazarus, quem arrumará os bugs |
− | * | + | * moderadores, quem dará suporte ao controle dos relatos priorizando-os e verificando assim como eles são reproduzidos. |
− | + | Nós usaremos o termo '''Lazarus team''' para ambos os grupos. | |
− | == | + | == Ciclo de vida de um relato == |
− | + | Um relato pode ter os seguintes estados: | |
− | * new: | + | * new/novo: ele foi colocado no bug tracker |
− | * acknowledged: | + | * acknowledged/admitido: o Lazarus Team viu o relato e ajustou seu alvo |
− | * assigned: | + | * assigned/atribuído: o relato foi atribuído para um desenvolvedor lazarus, quem tentará corrigi-lo |
− | * confirmed: | + | * confirmed/confirmado: um membro do Lazarus team tem o bug duplicado ou aceitou que a característica deve ser implementada |
− | * resolved: | + | * resolved/resolvido: a pessoa a qual o relato foi atribuído achou que o relato pode ser fechado. Então ele também ajustou a resolução, por exemplo '''fixed/arrumado''' ou '''not as issue/não é um relato''' |
− | == | + | == Como os moderadores podem dar suporte ao desenvolvedores Lazarus == |
− | === | + | === Admitindo relatos === |
− | ==== | + | ==== Ajustando o alvo ==== |
− | + | A etapa mais importante quando você admite um relato, é aquela em que você ajusta o campo de alvo. O campo de alvo ajuda os desenvolvedores lazarus a se empenhar a corrigir aquele bug. Geralmente há três opções: '''próximo lançamento''', '''1.0''' ou '''post1.0'''. Para explicação dessas opções, veja o [[Road To 1.0#1.0 or after 1.0]]. | |
* next release: 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 release: regressions (i.e. things that work in the current release, but got broken in the svn version) and crashes that can cause data loss. |
Revision as of 16:32, 26 March 2006
│
Deutsch (de) │
English (en) │
français (fr) │
português (pt) │
русский (ru) │
Este documento contém algumas linhas guias para usar o Lazarus bug tracker. Este documento é escrito para dois grupos:
- desenvolvedores lazarus, quem arrumará os bugs
- moderadores, quem dará suporte ao controle dos relatos priorizando-os e verificando assim como eles são reproduzidos.
Nós usaremos o termo Lazarus team para ambos os grupos.
Ciclo de vida de um relato
Um relato pode ter os seguintes estados:
- new/novo: ele foi colocado no bug tracker
- acknowledged/admitido: o Lazarus Team viu o relato e ajustou seu alvo
- assigned/atribuído: o relato foi atribuído para um desenvolvedor lazarus, quem tentará corrigi-lo
- confirmed/confirmado: um membro do Lazarus team tem o bug duplicado ou aceitou que a característica deve ser implementada
- resolved/resolvido: a pessoa a qual o relato foi atribuído achou que o relato pode ser fechado. Então ele também ajustou a resolução, por exemplo fixed/arrumado ou not as issue/não é um relato
Como os moderadores podem dar suporte ao desenvolvedores Lazarus
Admitindo relatos
Ajustando o alvo
A etapa mais importante quando você admite um relato, é aquela em que você ajusta o campo de alvo. O campo de alvo ajuda os desenvolvedores lazarus a se empenhar a corrigir aquele bug. Geralmente há três opções: próximo lançamento, 1.0 ou post1.0. Para explicação dessas opções, veja o Road To 1.0#1.0 or after 1.0.
- next release: regressions (i.e. things that work in the current release, but got broken in the svn version) and crashes that can cause data loss.
- 1.0: Lazarus 1.0 will contain stable support for win32 and gtk1 interface.
- post 1.0: other widget sets and new features.
Removing duplicate entries
When looking at new issue, you can also remove duplicated that are caused, 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 impatients and clicks on submit again. Those issues can be deleted.
Refering 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 "not an issue". If you wish you can provide a short answer to the question, but the bug tracker is to enter bugs and feature request, not to provide support.
Adding relations with other issues
The bug tracker supports setting relations between issues.
The weakest relation is Related. This gives just a link between the issues. This can be useful, if you fixed one issue, it may fix the related issues too.
If two reports decribe the same issues, then you can set Duplicate of to the newest report. The other report gets 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, first the Child issue must be fixed. Sometimes it is usefull to clone a (big) issue and describe part of it in a seperate Child issue.
Refering 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 resolving the issue with resolution "not an issue" and refer the reporter to the FPC bug tracker.
Confirming issues
Most of the time, the first step in fixing an issue, is creating a small example program that shows the issue. How difficult this is depends on the effort the reporter has made, when he submitted the report. Some people test programs to their report (very nice), some people only a code snippet (better than nothing) and some people nothing at all. Not all reports have adequate steps to reproduce.
If it is not clear from the report, you can ask the reporter the 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.