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

From Free Pascal wiki
Jump to navigationJump to search
Line 20: Line 20:
 
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]].  
 
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.
+
* próximo lançamento: regressões (isto é: as coisas que estão trabalhando bem na versão atual mas não estão pegando na versão svn) e quebras que podem causar perda de dados.
* 1.0: Lazarus 1.0 will contain stable support for win32 and gtk1 interface.
+
* 1.0: Lazarus 1.0 conterá um suporte estável para interface win32 e gtk1.
* post 1.0: other widget sets and new features.
+
* post 1.0: outros widget sets e novos recursos.
  
 
==== Removendo entradas duplicadas ====
 
==== Removendo entradas duplicadas ====
Line 33: Line 33:
 
O bug tracker suporta configuração de relação entre relatos.
 
O bug tracker suporta configuração de relação entre relatos.
  
A relação weakest é '''Relatado'''. Isto dá exatamente um link entre os relatos. Isto pode ser muito útil, se você arrumar um relato, ele pode corrigir o relato que foi relatado também...
+
A relação mais fraca é '''Relatado'''. Isto dá exatamente um link entre os relatos. Isto pode ser muito útil, se você arrumar um relato, ele pode corrigir o relato que foi relatado também...
  
 
Se dois relatores descrevem o mesmo relato, então você pode ajudar '''Duplicado do''' para o relato mais novo. O outro relator receberá um link para esse relato com '''Tem duplicado'''.
 
Se dois relatores descrevem o mesmo relato, então você pode ajudar '''Duplicado do''' para o relato mais novo. O outro relator receberá um link para esse relato com '''Tem duplicado'''.

Revision as of 16:59, 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.

  • próximo lançamento: regressões (isto é: as coisas que estão trabalhando bem na versão atual mas não estão pegando na versão svn) e quebras que podem causar perda de dados.
  • 1.0: Lazarus 1.0 conterá um suporte estável para interface win32 e gtk1.
  • post 1.0: outros widget sets e novos recursos.

Removendo entradas duplicadas

Quando um novo relato é visto, você pode também remover cópias que são causadas, porque pessoas enviam algum relato mais de uma vez. Às vezes o bugracker leva um longo tempo para processar um novo relato e o relato recebe impacientes clique em enviar novamente. Esses relatos podem ser deletados.

Mencionando questões na lista de e-mail e fóruns

Se um relato não descreve um bug, mas ele é somente uma questão ou um relator não sabe como usar certo recurso, você pode mencionar a ele a lista de e-mail e/ou os fóruns para perguntar sobre essa questão. Então você pode resolver o relato com resolução "não é um relato". Se você desejar você pode fornecer uma rápida resposta à questão, mas o bug tracker é para colocar bugs e pedidos de recursos, não para fornecer suporte.

Adicionando relações com outros relatos

O bug tracker suporta configuração de relação entre relatos.

A relação mais fraca é Relatado. Isto dá exatamente um link entre os relatos. Isto pode ser muito útil, se você arrumar um relato, ele pode corrigir o relato que foi relatado também...

Se dois relatores descrevem o mesmo relato, então você pode ajudar Duplicado do para o relato mais novo. O outro relator receberá um link para esse relato com Tem duplicado.

Você pode usar a relação Pai - Filho entre dois relatos para descrever dependências. A fim de arrumar o relato Pai, primeiro o relato Filho deve ser arrumado. Às vezes isso é muito útil para clonar um relato (grande) e descrever parte desses em separados relatos Filhos.

Mencionando o bug tracker do fpc

Se um bug não é da IDE ou da LCL, mas é da RTL, FCL ou do compilador, você pode resolver o relato com resolução "não é um relato" e mencionar ao relator o bug tracker do FPC.

Confirmando relatos

Mais uma vez, a primeira estapa para arrumar um relato, é criando um pequeno programa de exemplo que mostra o relato. Como dificular esse depende da vontade do relator, quando enviou o relato. Algumas pessoas testam programas para seus relatos (muito bom), algumas pessoas somente colocam um fragmento de código (melhor que nada) e alguma pessoas não colocam nada. Nem todos os relatos tem etapas adequadas para serem reproduzidos.

Se você Se o relato não estiver obstruído, você pode pedir para o relator dar as etapas para reproduzir esse relato e/ou um programa teste.

Se você administrou a reprodução desse relato, então você pode ajustar o relato como Confirmado.