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

From Free Pascal wiki
Jump to navigationJump to search
 
(One intermediate revision by the same user not shown)
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'''.
Line 46: Line 46:
 
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.
 
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 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'''.
 
Se você administrou a reprodução desse relato, então você pode ajustar o relato como '''Confirmado'''.

Latest revision as of 17:00, 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 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.