Nota: O documento original é mais novo que esta tradução.

Informações sobre o sistema de processamento de bugs para mantenedores de pacotes e classificadores de bugs

Inicialmente, um relatório de bug é enviado por um usuário como uma mensagem de e-mail comum para submit@bugs.debian.org o qual deve incluir uma linha Package (para mais informações veja Instruções para relatar bug). Um número é então atribuído ao relatório, informado ao usuário, e encaminhado para debian-bugs-dist. Se a linha Package contiver um pacote que tenha um mantenedor conhecido, o mantenedor também receberá uma cópia.

A linha Subject (Assunto) terá Bug#nnn: adicionado, e o Reply-To (Responder para) será ajustado para incluir o usuário que enviou o relatório e também nnn@bugs.debian.org.

Fechando relatórios de bugs

Relatórios de bugs Debian devem ser fechados quando o problema é corrigido. Problemas em pacotes só podem ser considerados corrigidos apenas quando um pacote que inclui a correção para o bug entra no repositório Debian.

Normalmente, as únicas pessoas que deveriam fechar um relatório de bug são o usuário que relatou o bug e o(s) mantenedor(es) do pacote para o qual o bug foi enviado. Existem exceções para esta regra, por exemplo, os bugs relatados para pacotes desconhecidos ou para certos pseudo-pacotes genéricos. Em caso de dúvida, não feche o bug, peça primeiro por ajuda na lista de discussão debian-devel.

Relatórios de bugs devem ser fechados através do envio de uma mensagem para nnn-done@bugs.debian.org. O corpo da mensagem precisa conter uma explicação de como o bug foi corrigido.

Com as mensagens recebidas do sistema de acompanhamento de bugs, tudo o que você precisa fazer para fechar o bug é enviar uma resposta através de seu programa de leitura de mensagens e editar o campo To (Destinatário, Para) para nnn-done@bugs.debian.org ao invés de nnn@bugs.debian.org (nnn-close é fornecido como um apelido para nnn-done).

Onde aplicável, por favor forneça uma linha Version no pseudo-cabeçalho de sua mensagem quando fechar um bug, de forma que o sistema de acompanhamento de bugs saiba quais versões do pacote contêm a correção.

A pessoa que está fechando o bug, a pessoa que o relatou e a lista de discussão debian-bugs-closed irão todos receber uma notificação sobre a mudança do status do relatório. A pessoa que enviou o relatório e a lista de discussão também receberão o conteúdo da mensagem enviada para nnn-done.

Mensagens de acompanhamento

O sistema de acompanhamento de bugs incluirá o endereço da pessoa que relatou o bug e o endereço do bug (nnn@bugs.debian.org) no cabeçalho Reply-To (Responder para) depois de encaminhar o relatório do bug. Por favor, note que estes são dois endereços distintos.

Qualquer desenvolvedor que deseje responder a um relatório de bugs deve simplesmente responder à mensagem, respeitando o cabeçalho Reply-To (Responder para). Isto não fechará o bug.

Não use as funcionalidades responder para todos ou encaminhar do seu leitor de e-mail a não ser que você deseje editar os destinatários consideravelmente. Em particular, veja que você não envia mensagens encaminhadas para submit@bugs.debian.org.

As mensagens podem ser enviadas para os seguintes endereços a fim de serem arquivadas no sistema de rastreamento de bugs:

Para mais informações sobre cabeçalhos para suprimir mensagens de confirmação e como enviar com cópias usando o sistema de acompanhamento de bugs, veja as instruções para relatar bugs.

Níveis de Severidade

O sistema de acompanhamento de bugs grava um nível de severidade com cada relatório de bug. Este é definido como normal por padrão, mas pode ser sobrescrito incluindo uma linha Severity no pseudo-cabeçalho quando o bug é enviado (consulte as instruções para reportar bugs), ou usando o comando severity com o servidor de requisição de controle.

Os níveis de severidade são:

critical
faz com que o software não relacionado ao sistema (ou o sistema todo) pare, ou causa sérias perdas de dados, ou introduz uma falha de segurança nos sistemas onde você instala o pacote.
grave
torna o pacote em questão inutilizável ou quase inutilizável, ou causa perda de dados, ou introduz uma falha de segurança, permitindo acesso às contas dos usuários que utilizam o pacote.
serious
é uma violação severa da política Debian (praticamente, viola uma diretiva must (obrigatória) ou required (requerida), ou, na opinião do mantenedor do pacote ou do gerente de lançamento, torna o pacote impróprio para o lançamento.
important
um bug que tem um efeito maior na utilização de um pacote, sem torná-lo completamente inutilizável para todos.
normal
o valor padrão, aplicável à maioria dos bugs.
minor
um problema que não afeta a utilidade do pacote, e de correção presumivelmente trivial.
wishlist
para requisição de qualquer melhoria e também para quaisquer bugs que sejam muito difíceis de corrigir devido a sérias considerações de projeto.

Certas severidades são consideradas release-critical, significando que o bug terá um impacto na liberação do pacote na versão estável do Debian. Atualmente, as severidades nesta categoria são critical, grave e serious. Para regras completas e canônicas sobre quais problemas merecem tais severidades, veja a lista dos problemas release-critical para o próximo lançamento

Tags para relatórios de bugs

Cada bug pode ter zero ou mais de um conjunto de tags. Estas tags são exibidas na lista de bugs quando você consulta a página do pacote e quando você consulta o registro completo do bug.

Tags podem ser definidas incluindo uma linha Tags no pseudo-cabeçalho quando o bug é reportado (consulte as instruções para reportar bugs) ou usando o comando tags com o servidor de requisição de controle. Separe tags múltiplas com vírgulas, espaços ou ambos.

As tags de bugs atuais são: patch, wontfix, moreinfo, unreproducible, help, newcomer, pending, security, upstream, confirmed, fixed, fixed-upstream, fixed-in-experimental, d-i, ipv6, lfs, l10n, a11y, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore . Aqui estão algumas informações detalhadas sobre as tags:

patch
Um patch ou outro procedimento fácil para corrigir o bug é incluído nos registros do bug. Caso exista um patch, mas o mesmo não corrija o bug adequadamente ou cause outros problemas, esta tag não deve ser usada.
wontfix
Este bug não será corrigido. Possivelmente porque esta é uma escolha entre duas maneiras arbitrárias de fazer as coisas, e o mantenedor e a pessoa que relatou o bug preferem maneiras diferentes de fazer as coisas, possivelmente porque a mudança de comportamento causará outros, piores, problemas para os outros, ou possivemente por outras razões.
moreinfo
Este bug não pode ser direcionado até que mais informações sejam fornecidas pela pessoa que relatou o mesmo. O bug será fechado caso a pessoa que o relatou não forneça maiores informações em um período de tempo razoável (alguns meses). Esta é para bugs do tipo Não funciona. O que não funciona?
unreproducible
Este bug não pode ser reproduzido no sistema do mantenedor. A assistência de terceiros é necessária para diagnosticar a causa do problema.
help
O mantenedor está requisitando ajuda para lidar com este bug. Ou o mantenedor não tem as habilidades necessárias para corrigir esse bug e necessita de colaboração, ou está sobrecarregado e quer delegar essa tarefa. Este bug pode não ser adequado para novos colaboradores a menos que também esteja marcado com a tag newcomer.
newcomer
Este bug tem uma solução conhecida mas o mantenedor solicita que outra pessoa o implemente. Esta é uma tarefa ideal para novos contribuidores que desejam se envolver com o Debian, ou que desejam melhorar suas habilidades.
pending
Uma solução para este bug foi encontrada e um envio será feito em breve.
fixed
Este bug está corrigido ou contornado (pelo envio de um não mantenedor, por exemplo), mas ainda existe um problema que precisa ser resolvido. Esta tag substitui a antiga severidade fixed.
security
Este bug descreve um problema de segurança em um pacote (por exemplo, permissões erradas permitindo o acesso a dados que não deveriam estar acessíveis; buffer overruns permitindo que pessoas controlem um sistema de uma maneira que não deveriam ser capazes de fazer; ataques de negação de serviço que precisam ser corrigidos, etc). A maioria dos bugs de segurança devem também ser definidos para uma severidade crítica ou grave.
upstream
Este bug aplica-se à parte do pacote sob responsabilidade do desenvolvedor original.
confirmed
O mantenedor do pacote verificou, entendeu e basicamente concorda com o bug, mas ainda tem que consertá-lo. (O uso dessa tag é opcional; ela é usada para aqueles mantenedores que precisam gerenciar uma grande quantidade de bugs em aberto.)
fixed-upstream
O bug foi corrigido pelo desenvolvedor original, mas não no pacote ainda (por uma razão qualquer: talvez seja muito complicado fazer a migração da mudança ou é uma mudança muito pequena, que não vale a pena).
fixed-in-experimental
O bug foi corrigido no pacote da distribuição experimental, mas ainda não foi corrigido na distribuição instável.
d-i
Esse bug é importante para o desenvolvimento do debian-installer. É esperado que essa tag seja usada quando o bug afetar o desenvolvimento do instalador, mas não está associado a um pacote que faz parte do próprio instalador.
ipv6
Esse bug afeta o suporte à versão 6 do Protocolo de Internet (IP).
lfs
Esse bug afeta o suporte a arquivos grandes (maiores que 2 gigabytes)
l10n
Este bug é relevante para a localização do pacote.
a11y
Este bug é relevante para a acessibilidade do pacote.
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, sid, experimental
Estas são tags de versão, que possuem dois efeitos. Quando colocada em um bug, o bug pode afetar apenas aquela versão em particular (embora ele também possa afetar outras versões se outras tags de versões foram colocadas), caso contrário são aplicadas regras normais de bugado/corrigido/inexistente. O bug tambem não deve ser arquivado até que seja corrigido na versão.
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore
Este bug crítico de lançamento é para ser ignorado permitindo, assim, o lançamento dessa versão em particular. Estas tags devem ser usadas somente pelo(s) gerente(s) de lançamento; não defina isso sozinho sem a autorização explícita dele(s).

Algumas informações sobre tags específidas de distribuição: As tags -ignore ignoraram o bug para permitir a propagação da teste (testing). As tags de versões indicam que o bug em questão não deve ser arquivado antes de ser corrigido no conjunto das versões marcadas. As tags de versões também indicam que um bug somente pode ser considerado bugado em um conjunto de versões específicas. [Em outras palavras, se qualquer das tags de versões estão inseridas, o bug é inexistente em qualquer versão cuja tag daquela versão correspondente não está inserida. Caso contrário, as regras normais de encontrado/corrigido se aplicam.]

Tags de versões não devem ser usadas se o versionamento adequado do bug conseguirá o efeito desejado, uma vez que exigem a adição e a remoção manual. Se você não tem certeza se uma tag de versão é necessária, entre em contato com o Debian BTS Administrators (owner@bugs.debian.org) ou o time de versão para esclarecimentos.

Registrando que você encaminhou um relatório de bug

Quando um desenvolvedor encaminha um relatório de bugs para o desenvolvedor original do pacote fonte do qual o pacote Debian é derivado, o mesmo deve anotar isso no sistema de acompanhamento de bugs como abaixo:

Certifique-se de que o campo To (Destinatário, Para) de sua mensagem para o autor possua apenas o(s) endereço(s) do(s) autor(es); coloque a pessoa que reportou o bug, nnn-forwarded@bugs.debian.org e nnn@bugs.debian.org no campo CC (Com Cópia).

Peça ao autor para preservar o CC (Com Cópia) para nnn-forwarded@bugs.debian.org quando responder, assim o sistema de acompanhamento de bugs irá arquivar a resposta com o relatório original. Estas mensagens são apenas arquivadas e não enviadas; para enviar uma mensagem da forma normal, envie-a para nnn@bugs.debian.org.

Quando o sistema de acompanhamento de bugs recebe uma mensagem em nnn-forwarded, o mesmo marca o bug relevante como tendo sido encaminhado para o(s) endereço(s) no campo To (Destinatário, Para) da mensagem que ele recebe, caso o bug já não esteja marcado como encaminhado.

Você pode também manipular a informação encaminhado para enviando mensagens para control@bugs.debian.org.

Alterando o responsável pelo bug

Nos casos onde a pessoa responsável por consertar o bug não é o mantenedor do pacote (por exemplo, quando o pacote é mantido por uma equipe de desenvolvedores), pode ser útil registrar esse fato no sistema de processamento de bugs. Para facilitar, cada bug pode opcionalmente ter um dono.

O dono pode ser configurado adicionando a linha Owner no pseudo-cabeçalho quando o bug é enviado (veja as instruções para relatar bugs), ou usando os comandos owner e noowner no servidor de requisição de controle.

Mantenedores de pacotes listados incorretamente

Caso o mantenedor de um pacote esteja listado incorretamente, isto acontece geralmente devido ao mantenedor ter mudado recentemente e o novo mantenedor não ter ainda feito o envio de uma nova versão do pacote com um campo Maintainer do arquivo de controle modificado. Isto será corrigido quando o pacote for enviado; alternativamente, os mantenedores do repositório podem sobrescrever o registro do mantenedor de um pacote manualmente, por exemplo, se uma recompilação e um reenvio do pacote não são esperados tão cedo. Entre em contato com override-change@debian.org para mudanças no arquivo de sobrescrita (override file).

Reabrindo, reatribuindo e manipulando bugs

É possível reatribuir relatórios de bugs para outros pacotes, reabrir bugs fechados erroneamente, modificar a informação dizendo para onde, caso exista, um relatório de bug foi encaminhado, mudar as severidades e títulos de relatórios, configurar o responsável pelos bugs, juntar e separar relatórios de bugs e registrar as versões dos pacotes nos quais os bugs foram encontrados e em quais delas os bugs foram corrigidos. Isto é feito enviando mensagens para control@bugs.debian.org.

O formato destas mensagens é descrito em outro documento disponível na World Wide Web ou no arquivo bug-maint-mailcontrol.txt. Uma versão em texto puro pode também ser obtida enviando uma mensagem com a palavra help para o servidor no endereço acima.

Inscrevendo-se em bugs

O sistema de acompanhamento de bugs também permite que a pessoa que relatou o bug, os desenvolvedores, e qualquer outra parte interessada, inscrevam-se em um bug específico. Esse recurso pode ser usado por aqueles que desejam monitorar um bug, sem que seja necessário inscrever-se em um pacote através do PTS. Todas as mensagens recebidas em nnn@bugs.debian.org, são enviadas aos inscritos.

A inscrição em bugs pode ser feita através do envio de um e-mail para nnn-subscribe@bugs.debian.org. O assunto e o conteúdo do e-mail são ignorados pelo BTS. Uma vez que a mensagem seja processada, os usuários receberão um e-mail de confirmação que deve ser respondido para que eles comecem a receber as mensagens relacionadas ao bug.

Também é possível cancelar a inscrição de um bug. O cancelamento da inscrição pode ser feita através do envio de um e-mail para nnn-unsubscribe@bugs.debian.org. O assunto e o conteúdo do e-mail são novamente ignorados pelo BTS. Os usuários receberão uma mensagem de confirmação que deve ser respondida para que eles tenham as inscrições do bug canceladas.

Por padrão, o endereço inscrito é aquele encontrado no campo From (De) do cabeçalho da mensagem. Se você deseja inscrever um outro endereço em um bug, você terá que codificar o endereço a ser inscrito dentro da mensagem de inscrição. Eis o formato utilizado para isso: nnn-subscribe-localpart=example.com@bugs.debian.org. Esse exemplo, enviaria à localpart@example.com uma mensagem de inscrição no bug nnn. O símbolo @ deve ser codificado mudando para o símbolo =. Similarmente, um cancelamento de inscrição utilizaria o seguinte formato: nnn-unsubscribe-localpart=example.com@bugs.debian.org. Em ambos os casos, o assunto e o corpo do e-mail serão encaminhados ao endereço contido na requisição de confirmação.

Recurso mais ou menos obsoleto de procura por Assunto

Mensagens que chegam em submit ou bugs cujo Assunto inicie com Bug#nnn serão tratadas como tendo sido enviadas para nnn@bugs.debian.org. Isto é para compatibilidade regressiva com mensagens encaminhadas a partir do endereço antigo e para pegar mensagens enviadas para submit por engano (por exemplo, usando "responder para todos os destinatários").

Um esquema similar opera para maintonly, done, quiet e forwarded, os quais tratam mensagens que chegam com uma tag Assunto como tendo sido enviadas para o endereço nnn-qualquercoisa@bugs.debian.org correspondente.

Mensagens que chegam com forwarded puro e done — isto é, sem número do relatório de bugs no endereço — e sem um número de bug no Assunto serão arquivadas como junk (lixo) e mantidas por algumas semanas, mas por outro lado serão ignoradas.

Recurso obsoleto X-Debian-PR: quiet

É usado para ser possível prevenir que o sistema de acompanhamento de bugs encaminhe para qualquer lugar mensagens que o mesmo recebeu em debian-bugs, colocando uma linha X-Debian-PR: quiet no cabeçalho da mensagem atual.

Esta linha de cabeçalho é agora ignorada. Ao invés disso, envie sua mensagem para quiet ou nnn-quiet (ou maintonly ou nnn-maintonly).


Other BTS pages:


Debian BTS administrators <owner@bugs.debian.org>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.