openSUSE:FAQ dos relatórios de bugs
Índice
- 1 Que tipo de feedback você se quer?
- 2 Manuseio geral do bug
- 2.1 Quais campos devem ser preenchidos inicialmente? Quais devo mudar ou não?
- 2.2 Obterei algum retorno depois de relatar um bug?
- 2.3 Quais campos devo mudar e quais não devo?
- 2.4 O quê devo fazer se a versão atual do openSUSE contiver o mesmo bug (ou parecido) que já foi relatado para uma versão anterior?
- 2.5 Pessoas se irritaram porque informei "Install openSUSE x.y-Beta-z" no campo "how to reproduce". Por quê?
- 2.6 As pessoas estavam muito infelizes, porque só escrevi "ver assunto" no campo descrição - mas o meu assunto realmente explica tudo! Não é pura picuinhas insistir para que os relatores de bug repitam o que está o campo de descrição?
- 3 Bug em estado NEEDINFO
- 3.1 O quê significa bug em estado NEEDINFO e como isso deve ser tratado?
- 3.2 Não me tornarei proprietário do bug quando alterar o status do bug de NEEDINFO para ASSIGNED (com Aceitar bug (altere estado para ASSIGNED) na página de detalhes de bug no Bugzilla)?
- 3.3 Por que é importante que eu altere o estado de um bug de NEEDINFO para ASSIGNED? Isto não é responsavilidade do proprietário do bug?
- 3.4 O quê acontecerá se as informações necessárias não forem acrescentadas aos meu bugs em estado NEEDINFO?
- 4 Bug em estado VERIFIED/CLOSED
- 5 Bug em estado WONTFIX
- 6 Como relatar um bug diante ...
- 7 openSUSE Documentation
Que tipo de feedback você se quer?
Gostamos de ambas, tanto das positivas quanto das negativas, importa sim que nos seja informada a sua impressão sobre o trabalho realizado, e serão melhores ainda se vierem acompanhadas de sugestões para melhorias.
- Por feedback positivo, entendemos aquilo que é bom ouvir: que um sistema foi instalado com sucesso e funciona, que determinadas áreas foram testados e que satisfazem o seu propósito. Por favor, informe isso na opensuse@opensuse.org. Os comentários positivos são registrados em nosso testdb.
- Para o feedback negativo, que significa todos os problemas que forem encontrados, deve-se usar o Bugzilla. Por favor, relate um bug separado para cada problema que você encontrar. Há outras áreas neste FAQ que explicam detalhadamente como identificar e relatar um bug.
- Além disso, esperamos pelas suas ideias para melhorias, comumente chamadas de pedidos de recurso. Coletamos estas no openFATE, o nosso banco de dados de recurso.
Manuseio geral do bug
Quais campos devem ser preenchidos inicialmente? Quais devo mudar ou não?
- Componente
Nota: nem todos os defeitos durante a instalação são por culpa do Yast; podem ser, por exemplo, defeitos do kernel. - Plataforma
Escolha "todos" se acha que não depende da plataforma; senão, escolha a sua plataforma. - Sumário
As pessoas olhando para o sumário entenderão do que se trata. - Descrição do defeito
Adicione todos os detalhes sobre o defeito. Note que não deve dizer "Ver sumário", pois o sumário pode mudar. - Como Reproduzi-lo?
Isto é tão importante que merece uma explicação extra em Q: 2.5 - Gravidade
Escolha a gravidade certa. Marque-o apenas como "blocker" se ele bloqueia o seu trabalho com o produto. O sinalizador SHIP_STOPPER está disponível, se você acha que não devemos embarcar com este bug não corrigido no produto. - O resto
Não é necessário preencher quaisquer dos outros campos, os valores predefinidos são suficientes.
Obterei algum retorno depois de relatar um bug?
Sim, caso suas "prefs" não sejam alteradas, será informado via e-mail sobre quaisquer alterações.
Se está com dúvidas ou apenas acha que precisa comentar qualquer resposta; por favor, não envie nada para o endereço de comentador que é gerado automaticamente no correio do Bugzilla. Utilize a interface Web do Bugzilla para se comunicar, pois é a única maneira da informação relevante ser acessível a todos os interessados.
Quais campos devo mudar e quais não devo?
Como não desenvolvedor, deves, em geral, apenas adicionar comentários adicionais, ou adicionar-se ao CC. Se o defeito está especificado como "NEEDINFO", lembre-se de especificá-lo como "ASSIGNED" depois de dar toda a informação.
Há uma caixa de verificação, abaixo do comentário, que diz algo como "This comment provides the needed info" (Este comentário contém a informação necessária). Este campo não deveria ser usado preferencialmente?
O quê devo fazer se a versão atual do openSUSE contiver o mesmo bug (ou parecido) que já foi relatado para uma versão anterior?
Sugerimos que mova a versão do pacote e escreva no comentário algo como "Este defeito foi reportado para o openSUSE x.y e continua a existir para o openSUSE u.v. Estou ajustando a versão". Se o defeito já foi fechado anteriormente, deves reabri-lo.
Pessoas se irritaram porque informei "Install openSUSE x.y-Beta-z" no campo "how to reproduce". Por quê?
Porque esta informação é completamente inútil, além de redundante e não ajudar em nada a reproduzir um bug. Podemos dizer que um erro é sobre a instalação porque você selecionou "Installation", na lista de componentes do Bugzilla, e podemos dizer, ainda, qual a versão você instalou da lista de versões ao lado.
Aquilo que realmente necessitamos saber é o quê estavas fazendo e como estavas fazendo - Tal como, "inicializei do CD1, selecionei "Instalação", selecionei o idioma "Klingon", mantive como estavam as "configurações de instalação", confirmei a "instalação" quando solicitado, observei então como o meu disco rígido explodiu em meio a chamas.
E não, isso realmente não é picuinhas - temos tantos modos e caminhos de instalação que demora muito tempo para descobrir tudo o que sai a partir dos arquivos de log. Você tem essa informação imediatamente disponível, por isso, introduza-a naquele campo.
Claro, não necessitamos deste nível de detalhes quando se trata de um relato de bug sobre um texto de ajuda num diálogo final de configuração de hardware (como instalação de impressora, placa de TV, etc...) - mas os passos para obter o lugar onde o problema aconteceu, nós realmente necessitamos. Temos tantos diálogos que não é fácil descobrir a qual deles você se refere e qual o caminho que foi trilhado até esbarrar com o problema.
As pessoas estavam muito infelizes, porque só escrevi "ver assunto" no campo descrição - mas o meu assunto realmente explica tudo! Não é pura picuinhas insistir para que os relatores de bug repitam o que está o campo de descrição?
Não, não é suficiente.
Os assuntos são alterados o tempo todo. O problema que você relatou pode ser apenas a ponta de um iceberg - o problema real pode estar em um lugar completamente diferente, e assim aqueles que sabem qual o lugar, claro, mudará o assunto em conformidade. Isto, por sua vez, significa que o seu assunto original será perdido.
Por isso, deve ser bastante óbvio que o assunto não é lugar para armazenar as informações pertinentes, e que o problema que está sendo relatado, certamente é a informação mais importante em um relatório de bug.
É também mal estilo simplesmente despejar todo tipo de informação no assunto e, em seguida, apenas fazer referência ao assunto. Isto é pura preguiça apenas. Custa-lhe tempo uma vez fazê-lo corretamente, mas todo aquele que trabalhar com esse bug terá que pesquisar em todos os lugares pelas informações relevantes outra vez.
Além disso, um assunto deve ser conciso - mas uma descrição de erro deve ser explicativa. Os dois requisitos são contraditórios.
Bug em estado NEEDINFO
O quê significa bug em estado NEEDINFO e como isso deve ser tratado?
NEEDINFO significa que o proprietário do bug (aquele que está atualmente trabalhando com este bug) necessita de mais inormação a respeito deste bug - normalmente deverão ser fornecidas pelo relator do bug.
Se você encontrar um bug que você relatou que está definido como NEEDINFO, procure uma pergunta ou uma solicitação para fornecer mais informações (tais como logs, etc) em um dos últimos comentários.
Se este for o caso, por favor responda a essa pergunta ou forneça essa informação, respectivamente, e defina o estado do bug para ASSIGNED - clique em Aceitar bug (altere o para ASSIGNED) na página de detalhes de bug no Bugzilla.
Por favor, prefira a interface Web do Bugzilla para responder perguntas e anexar os logs. Não envie essa informação por e-mail, a menos que tenha motivos sérios para esse fim. Normalmente existem mais pessoas trabalhando em um bug e essa informação deve estar acessível a todos eles para garantir uma rápida correção.
Não me tornarei proprietário do bug quando alterar o status do bug de NEEDINFO para ASSIGNED (com Aceitar bug (altere estado para ASSIGNED) na página de detalhes de bug no Bugzilla)?
Não, o proprietário do bug permanece o mesmo, apenas o estado se altera. Você pode fazer isso com segurança, sem medo de que esse bug passe a ser de sua responsabilidade por isso.
Por que é importante que eu altere o estado de um bug de NEEDINFO para ASSIGNED? Isto não é responsavilidade do proprietário do bug?
Não, isso é da responsabilidade de quem responde a pergunta feita ou fornece as informações que foram solicitadas.
Os proprietários do Bug usam NEEDINFO para que possam ver mais facilmente sobre quais bugs eles podem atualmente trabalhar (aqueles definidos como ASSIGNED, NEW ou REOPENED) e os que estão presos, pois a informação importante está faltando - bugs em NEEDINFO não aparecem mais em sua lista de afazeres de bugs em aberto.
Esta é a importância de se alterar o estado do bug de NEEDINFO para outro - o proprietário do bug pode desconsiderar o e-mail que o Bugzilla envia automaticamente diante de comentários adicionados a um bug, fazendo com que este bug possa permanecer em NEEDINFO por um período de tempo indefinido.
Nossos mantenedores recebem tantos e-mails gerados em momentos de pico (como durante a fase Beta), que os impedem de razoavelmente reagir a cada um individualmente, de modo que em um certo ponto eles têm de recorrer às listas de status de erro - e então as chances são de que ele se lembre que algumas informações solicitadas já estão disponíveis e o trabalho sobre um bug pode recomeçar.
Por isso, é interesse próprio de cada repórter de bug mudar o status do bug de NEEDINFO após as perguntas serem respondidas.
Claro que, às vezes você pode ter sorte e o proprietário do bug perceber que as informações solicitadas já estão disponíveis e definir o status de erro para ASSIGNED ele próprio, mas confiar na sorte não é geralmente uma boa tática.
Por favor, note que os erros que são atribuídos ao BNC-Screening-Team (problemas relacionados principalmente ao YaST e ao X11) inicialmente ou durante o processo não devem ser definidos de NEEDINFO para ASSIGNED pelo relator do bug ou pessoa a quem a informação foi solicitada. Isso ocorre porque uma alteração deste estado quase sempre envolve uma mudança que é feita por esta equipe. Mudar esta situação pode causar o erro específico para aparecer no anúncio errado e, portanto, não poder ser manipulado (transferido) de forma eficiente. Obrigado por ter isso em conta.
O quê acontecerá se as informações necessárias não forem acrescentadas aos meu bugs em estado NEEDINFO?
Um bug que esteja a mais de um mês no estado NEEDINFO pode ser fechado como "Resolvido: SEMRESPOSTA" com uma mensagem amigável como "As informações solicitadas não foram fornecidas por a mais de quatro semanas, fechado como SEMRESPOSTA, reabra o erro uma vez que a informação seja fornecida. "..
Como parte da triagem de bugs, outros desenvolvedores também podem fazer isso por bugs.
Bug em estado VERIFIED/CLOSED
Devo marcar um bug como VERIFICADO ou FECHADO quando percebo que o problema foi resolvido numa nova versão ou com as atualizações?
[TBD]
Bug em estado WONTFIX
Esta seção foi movida para
Como relatar um bug diante ...
Para mais informações sobre como relatar erros para diferentes componentes, como e.g. o Kernel, KDE ou Yast, vá para openSUSE:Submeter relatórios de bugs.
openSUSE Documentation
Relatar defeitos na documentação do openSUSE no Bugzilla (componente: "Documentação").