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

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

Inicialmente, um relatório de bug é enviado por um(a) usuário(a) como uma mensagem de e-mail comum para [email protected], 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(a) e encaminhado para debian-bugs-dist. Se a linha Package contiver um pacote que tenha um(a) ou mais mantenedores(as) conhecidos(a), eles(as) também receberão uma cópia.

Na campo Assunto será adicionado Bug#nnn: e o campo Responder para incluirá o(a) usuário(a) que enviou o relatório e também nnn@bugs.debian.org.

Fechando relatórios de bugs

Os 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 devem fechar um relatório de bug são: o(a) usuário(a) que relatou o bug e os(as) mantenedores(as) 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 pseudopacotes genéricos. Um bug também pode ser fechado por qualquer contribuidor(a) se o bug for de um pacote órfão, ou se o(a) mantenedor(a) do pacote esqueceu de fechá-lo. É muito importante mencionar a versão do pacote para a qual o bug foi corrigido. 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 um e-mail para nnn[email protected]. 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 e-mail e editar o campo Para inserindo nnn[email protected] em vez 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 pseudocabeç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 Responder para depois de encaminhar o relatório do bug. Por favor, observe que estes são dois endereços distintos.

Qualquer desenvolvedor(a) que deseje responder a um relatório de bugs deve simplesmente responder à mensagem, respeitando o cabeçalho 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, não envie mensagens encaminhadas para [email protected].

As mensagens podem ser enviadas para os seguintes endereços a fim de serem arquivadas no sistema de acompanhamento 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 para cada relatório de bug. Este é definido como normal por padrão, mas pode ser sobrescrito incluindo uma linha Severity no pseudocabeç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(as) usuários(as) que utilizam o pacote.
serious
é uma violação severa da política Debian (praticamente, viola uma diretiva must ou required, ou, na opinião do(a) mantenedor(a) do pacote ou do(a) 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(as).
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 grandes considerações de design.

Certas severidades são consideradas release-critical, significando que o bug terá um impacto na liberação do pacote na versão estável (stable) 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 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.

As tags podem ser definidas incluindo uma linha Tags no pseudocabeç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 atuais dos bugs são: patch, wontfix, moreinfo, unreproducible, help, security, upstream, pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs, fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore . Aqui estão algumas informações detalhadas sobre as tags:

patch
Um patch (correção) 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(a) mantenedor(a) e a pessoa que relatou o bug preferem maneiras diferentes de fazer as coisas, possivelmente porque a mudança de comportamento causará outros problemas piores para os outros, ou possivelmente 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(a) mantenedor(a). A assistência de terceiros é necessária para diagnosticar a causa do problema.
help
O(A) mantenedor(a) está requisitando ajuda para lidar com este bug. Ou o(a) mantenedor(a) não tem as habilidades necessárias para corrigir esse bug e necessita de colaboração, ou está sobrecarregado(a) e quer delegar essa tarefa. Este bug pode não ser adequado para novos(as) colaboradores(as) a menos que também esteja marcado com a tag newcomer.
newcomer
Este bug tem uma solução conhecida mas o(a) mantenedor(a) solicita que outra pessoa o implemente. Esta é uma tarefa ideal para novos(as) contribuidores(as) 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 foi corrigido ou contornado (por exemplo foi enviado por um(a) não mantenedor(a)), 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 liberando 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 também devem ser definidos para uma severidade critical ou grave.
upstream
Este bug aplica-se à parte do pacote sob responsabilidade do(a) desenvolvedor(a) original.
confirmed
O(A) mantenedor(a) 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(as) mantenedores(as) que precisam gerenciar uma grande quantidade de bugs em aberto.
fixed-upstream
O bug foi corrigido pelo(a) desenvolvedor(a) original, mas ainda não foi corrigido no pacote (por uma razão qualquer: talvez seja muito complicado fazer a migração da mudança ou é uma mudança tão pequena que não vale a pena).
fixed-in-experimental
O bug foi corrigido no pacote da versão experimental, mas ainda não foi corrigido na versão instável (unstable).
d-i
Esse bug é importante para o desenvolvimento do instalador do Debian. É 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 afeta a acessibilidade para usuários(as) com deficiências. Ele afeta particularmente a usabilidade por pessoas que dependem de tecnologia assistiva (ou outra adaptativa) para usar o sistema/pacote.
ftbfs
O pacote falha ao ser construído a partir do código-fonte. Se o bug foi atribuído para um pacote-fonte, aquele pacote falha na construção. Se o bug foi atribuído para um pacote binário, os pacotes-fonte afetados falham na construção. A tag é aplicável para ambientes de construção não padrões (por exemplo, usando Build-Depends da experimental), mas a severidade deve ser abaixo de serious (release critical) nesses casos.
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, 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ão foram colocadas), caso contrário são aplicadas regras normais de problemático/corrigido/inexistente. O bug também 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, bookworm-ignore, trixie-ignore forky-ignore
Este bug release-critical é para ser ignorado, permitindo, assim, o lançamento dessa versão em particular. Estas tags devem ser usadas somente pelo(s)/pela(s) gerente(s) de lançamento; não defina isso sozinho sem a autorização explícita dele(s)/dela(s).

Algumas informações sobre tags específicas de versão: As tags -ignore ignoram o bug para permitir a propagação para a 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ão também indicam que um bug somente pode ser considerado problemático em um conjunto de versões específicas. [Em outras palavras, se qualquer das tags de versão 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 os(as) administradores(as) do Debian BTS ([email protected]) ou o time de versão para esclarecimentos.

Registrando que você encaminhou um relatório de bug

Quando um(a) desenvolvedor(a) encaminha um relatório de bugs para o(a) desenvolvedor(a) original do código fonte do qual o pacote Debian é derivado, deve-se anotar no sistema de acompanhamento de bugs como abaixo:

Certifique-se de que o campo Para da sua mensagem para o(a) autor(a) possua apenas o endereço de e-email dele(a) (ou os endeços de e-mail no caso de ser mais de um(a) autor(a)); no campo Cc coloque: a pessoa que reportou o bug, nnn[email protected] e nnn@bugs.debian.org.

Peça ao(à) autor(a) para preservar o campo Cc deixando nnn[email protected] 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 com nnn-forwarded, ele marca o bug relevante como tendo sido encaminhado para o(s) endereço(s) no campo Para da mensagem que ele recebe, caso o bug já não esteja marcado como encaminhado.

Você pode também manipular a informação forwarded to enviando mensagens para [email protected].

Alterando o responsável pelo bug

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

O(A) dono(a) pode ser configurado(a) adicionando a linha Owner no pseudocabeç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(as) de pacotes listados(as) incorretamente

Se o(a) mantenedor(a) de um pacote está listado(a) incorretamente, é porque, geralmente, o(a) mantenedor(a) mudou recentemente e o(a) novo(a) mantenedor(a) não fez 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(as) mantenedores(as) do repositório podem sobrescrever o registro do(a) mantenedor(a) 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 [email protected] 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(a) 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 e-mails para [email protected].

O formato destas mensagens é descrito em outro documento disponível no web site, ou no arquivo bug-maint-mailcontrol.txt. Uma versão em texto puro também pode 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(as) desenvolvedores(as) e qualquer outra parte interessada, inscrevam-se em um bug específico. Esse recurso pode ser usado por aqueles(as) que desejam monitorar um bug, sem que seja necessário inscrever-se em um pacote através do rastreador de pacotes do Debian. Todas as mensagens recebidas em nnn@bugs.debian.org, são enviadas aos(às) inscritos(as).

A inscrição em um bug pode ser feita através do envio de um e-mail para nnn[email protected]. O assunto e o conteúdo do e-mail são ignorados pelo BTS. Uma vez que a mensagem seja processada, os(as) usuários(as) receberão um e-mail de confirmação que deve ser respondido para que eles(as) 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[email protected]. O assunto e o conteúdo do e-mail são novamente ignorados pelo BTS. Os(As) usuários(as) receberão uma mensagem de confirmação que deve ser respondida para que eles(as) tenham as inscrições do bug canceladas.

Por padrão, o endereço inscrito é aquele encontrado no campo De do cabeçalho da mensagem. Se você deseja inscrever um outro endereço de e-mail 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 à [email protected] 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 campo assunto inicie com Bug#nnn serão tratadas como tendo sido enviadas para nnn@bugs.debian.org. Isto é para compatibilidade retroativa 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 Subject como tendo sido enviadas para o endereço nnn-qualquercoisa@bugs.debian.org correspondente.

Mensagens que chegam com forwarded puro e done — isto é, sem o número do relatório de bugs no endereço — e sem um número de bug no campo assunto serão arquivadas como junk 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. Em vez disso, envie sua mensagem para quiet ou nnn-quiet (ou maintonly ou nnn-maintonly).

Other BTS pages:

Debian BTS administrators <[email protected]>

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