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

Informações para desenvolvedores sobre o sistema de processamento 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. Um número é então atribuído ao relatório, informado ao usuário, e encaminhado para debian-bugs-dist. Caso o usuário que reportou o bug tenha incluído uma linha Package listando um pacote com um mantenedor conhecido, o mantenedor também receberá uma cópia.

A linha Subject (Assunto) terá Bug#nnn: adicionado, e o Reply-To 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 um problema é corrigido. Problemas em pacotes 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. Em caso de dúvidas, 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 um 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 uma 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 o conserto.

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 depois de encaminhar o relatório do bug. Por favor, note que estes são dois endereços distintos.

Caso um desenvolvedor deseje responder a um relatório de bugs, o mesmo deve simplesmente responder a mensagem, respeitando o cabeçalho Reply-To. Isto não fechará o bug.

O sistema de acompanhamento de bugs receberá a mensagem em nnn@bugs.debian.org, irá encaminhá-la ao mantenedor do pacote, arquivar a resposta com o restante dos logs para este relatório de bugs e encaminhá-la para debian-bugs-dist.

Ao enviar uma mensagem para nnn-submitter@bugs.debian.org, um e-mail será explicitamente enviado à pessoa que relatou o bug e uma cópia será submetida ao sistema de acompanhamento de bugs. A mensagem não será enviada ao mantenedor.

Caso deseje enviar um acompanhamento para a mensagem que não seja apropriado para debian-bugs-dist, você pode fazer isso enviando o mesmo para nnn-quiet@bugs.debian.org ou para nnn-maintonly@bugs.debian.org. Mensagens para nnn-quiet@bugs.debian.org são arquivadas no Sistema de Acompanhamento de Bugs mas não são entregues para quaisquer indivíduos ou listas de discussão. Mensagens para nnn-maintonly@bugs.debian.org são arquivadas no Sistema de Acompanhamento de Bugs e são entregues somente para o mantenedor do pacote em questão.

Não use os recursos Responder a todos os destinatários ou Acompanhar de seu cliente de e-mail a menos que você edite os destinatários para reduzí-los substancialmente. Em particular, certifique-se de não enviar acompanhamentos para submit@bugs.debian.org.

Para mais informações sobre cabeçalhos para suprimir mensagens de confirmação e como enviar cópias carbono 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 softwares não-relacionados no sistema (ou o sistema todo) parem, ou causa séria perda 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 severa violação da política Debian (isto é, viola uma diretiva deve – must, ou requerida – required), 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 quaisquer requisições de inclusão de novos recursos e também para quaisquer bugs que sejam muito difíceis de corrigir devido a considerações maiores de design.

Certas severidades são consideradas release-critical, significando que o bug terá um impacto caso o pacote que o contém seja fornecido em uma versão estável do Debian. Atualmente, as severidades nesta categoria são critical, grave e serious. Para regras completas e canônicas sobre que aspectos merecem tais severidades, veja a lista Problemas Críticos de Lançamento para o Lenny

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 log 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írgula, espaço ou ambos.

As tags de bugs atuais são:

patch
Um patch ou outro procedimento fácil para corrigir o bug é incluído nos logs 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 corrigir o problema, e o mantenedor e a pessoa que relatou o bug preferem maneiras diferentes de agir, ou porque a mudança de comportamento causará outros problemas, piores, para outros, ou talvez por outras razões.
moreinfo
Este bug não pode ser corrigido 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 Isso não funciona. O que não funciona?
unreproducible
Este bug não pode ser reproduzido no sistema do mantenedor. Assistência de terceiros é necessária para diagnosticar a causa do problema.
help
O mantenedor está requisitando ajuda para lidar com este bug.
pending
Uma solução para este bug foi encontrada e um upload será feito em breve.
fixed
Este bug está corrigido ou superado (por um upload de 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 concorda com o bug, mas ainda não consertou. (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 autor 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 está relacionado com o suporte à versão 6 do Protocolo de Internet (IP).
lfs
Esse bug está relacionado com o suporte a arquivos grandes (maiores que 2 gigabytes).
l10n
Este bug é relevante para a localização de um pacote.
potato
Este bug aplica-se particularmente à distribuição potato do Debian.
woody
Este bug aplica-se particularmente à distribuição woody.
sarge
Esta é uma tag de distribuição que possui dois efeitos. Quando aparece em um bug, este só pode afetar a distribuição sarge (embora também possa afetar outras distribuições se outras tags de distribuição estiverem configuradas), caso contrário as regras normais se aplicam. O bug não será arquivado até que seja corrigido na distribuição sarge.
sarge-ignore
Este bug crítico de lançamento será ignorado para permitir o lançamento do sarge. Esta tag deve ser usada somente pelo gerente de lançamento; não defina isso sozinho sem sua autorização explícita.
etch
Esta é uma tag de distribuição que possui dois efeitos. Quando aparece em um bug, este só pode afetar a distribuição etch (embora também possa afetar outras distribuições se outras tags de distribuição estiverem configuradas), caso contrário as regras normais se aplicam. O bug não será arquivado até que seja corrigido na distribuição etch.
etch-ignore
Este bug crítico de lançamento será ignorado para o propósito do lançamento do etch. Esta tag deve ser usada apenas pelo gerente de lançamento, não a ative sem sua autorização explícita.
lenny
Esta é uma tag de lançamento que possui dois efeitos. Quando aparece em um bug, este só pode afetar o lançamento do lenny (embora também possa afetar outros lançamentos se outras tags de lançamento estiverem configuradas), caso contrário as regras normais se aplicam. O bug não será arquivado até que seja corrigido no lenny.
lenny-ignore
Este bug crítico de lançamento será ignorado para o propósito do lançamento do lenny. Esta tag deve ser usada apenas pelo(s) gerente(s) de lançamento; não a ative sem a autorização explícita deles.
squeeze
Esta é uma tag de lançamento que possui dois efeitos. Quando aparece em um bug, este só pode afetar o lançamento do squeeze (embora também possa afetar outros lançamentos se outras tags de lançamento estiverem configuradas), caso contrário as regras normais se aplicam. O bug não será arquivado até que seja corrigido no squeeze.
squeeze-ignore
Este bug crítico de lançamento será ignorado para o propósito do lançamento do squeeze. Esta tag deve ser usada apenas pelo(s) gerente(s) de lançamento; não a ative sem a autorização explícita deles.
sid
Esta é uma tag de distribuição que possui dois efeitos. Quando aparece em um bug, este só pode afetar o sid (embora também possa afetar outras distribuições se outras tags de distribuição estiverem configuradas), caso contrário as regras normais se aplicam. O bug não será arquivado até que seja corrigido no sid.
experimental
Esta é uma tag de distribuição que possui dois efeitos. Quando aparece em um bug, este só pode afetar a experimental (embora também possa afetar outras distribuições se outras tags de distribuição estiverem configuradas), caso contrário as regras normais se aplicam. O bug não será arquivado até que seja corrigido no experimental.

Os significados das últimas 8 tags mudou recentemente; as tags ignore vão ignorar o bug para o propósito de propagação para a testing. As tags de distribuição/lançamento (release), que costumavam apenas indicar quais bugs afetavam um lançamento específico, agora indicam quando um bug pode ser arquivado e o conjunto de distribuições/lançamentos para os quais um bug pode ser considerado como encontrado (found) ou corrigido (fixed).

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 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.

Peça ao autor para preservar o CC 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 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

Em alguns casos onde a pessoa responsável por consertar o bug não é necessariamente 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 incorretamente listados

Caso o mantenedor de um pacote esteja listado incorretamente, isto é normalmente devido ao mantenedor ter mudado recentemente e o novo mantenedor não ter ainda feito upload de uma nova versão do pacote com um campo Maintainer do arquivo de controle modificado. Isto será corrigido quando o upload do pacote for feito; 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. Contate 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 para reabrir bugs fechados erroneamente, para modificar a informação dizendo para onde, caso exista, um relatório de bug foi encaminhado, para mudar as severidades e títulos de relatórios, para configurar o responsável pelos bugs, para juntar e separar relatórios de bugs e para 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, ou qualquer outra parte interessada, inscrevam-se em um bug específico. Esse recurso pode ser útil para 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, o usuário receberá um e-mail de confirmação que deve ser respondido para que ele comece a receber as mensagens relacionadas ao bug.

Também é possível desinscrever-se de um bug. A desinscriçã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 também são ignorados pelo BTS. Os usuários receberão uma mensagem de confirmação que deve ser respondida para que eles sejam desinscritos do bug.

Por padrão, o endereço inscrito é aquele encontrado no campo From 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 modificado para =. Similarmente, uma desinscrição utilizaria o seguinte formato: nnn-unsubscribe-localpart=example.com@bugs.debian.org. Em ambos os casos, o campo Assunto e o corpo do e-mail serão encaminhados ao endereço contido na requisição de confirmação.

Recurso de procura-no-assunto mais-ou-menos obsoleto

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 sob junk e mantidas por algumas poucas semanas, mas de outra forma ignoradas.

Recurso X-Debian-PR: quiet obsoleto

É usado para ser possível prevenir que o sistema de acompanhamento de bugs encaminhe a 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.