[lcfr] wml://portuguese/Bugs/Developer.wml
commit, please
#use wml::debian::template title="Debian BTS - informações para desenvolvedores" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.55"
<H1>Informações para Desenvolvedores sobre o sistema de processamento de bugs</H1>
<P>Inicialmente, um relatório de bug é enviado por um usuário como
uma mensagem de e-mail comum para <CODE>submit@bugs.debian.org</CODE>.
Um número é então atribuído ao relatório, informado ao usuário, e
encaminhado para <CODE>debian-bugs-dist</CODE>. Caso o usuário que
reportou o bug tenha incluído uma linha <CODE>Package</CODE> listando
um pacote com um mantenedor conhecido o mantenedor receberá também
uma cópia.</P>
<P>A linha <CODE>Subject</CODE> terá
<CODE>Bug#</CODE><VAR>nnn</VAR><CODE>:</CODE> adicionado, e o
<CODE>Reply-To</CODE> será ajustado para incluir o usuário que
enviou o relatório e também
<VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>.</P>
<hrline>
<ul>
<li><a href="#closing">Fechando relatórios de bugs</a></li>
<li><a href="#followup">Mensagens de Acompanhamento</a></li>
<li><a href="#severities">Níveis de Severidade</a></li>
<li><a href="#tags">Tags para relatórios de bugs</a></li>
<li><a href="#forward">Registrando que você passou adiante um relatório de bug</a></li>
<li><a href="#owner">Alterando o responsável pelo bug</a></li>
<li><a href="#maintincorrect">Mantenedores de pacotes incorretamente listados</a></li>
<li><a href="#requestserv">Reabrindo, redesignando e manipulando bugs</a></li>
<li><a href="#subjectscan">Recurso de procura-no-assunto mais-ou-menos obsoleto</a></li>
<li><a href="#x-debian-pr">Recurso <code>X-Debian-PR: quiet</code> obsoleto</a></li>
</ul>
<hrline>
<h2><a name="closing">Fechando relatórios de bugs</a></h2>
<p>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.</p>
<p>Normalmente, as únicas pessoas autorizadas a fechar um relatório
de bug são o usuário que relatou o bug e o(s) mantendor(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.</p>
<p>Relatórios de bugs devem ser fechados através do envio de uma
mensagem para <var>nnn</var><code>-done@bugs.debian.org</code>.
O corpo da mensagem precisa conter uma explicação de como o bug
foi corrigido.</p>
<p>Com as mensagens recebidas do sistema de gerenciamento 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 <code>To</code> para
<VAR>nnn</VAR><CODE>-done@bugs.debian.org</CODE> ao
invés de <VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>
(<VAR>nnn</VAR><CODE>-close</CODE> é fornecido como uma apelido para
<VAR>nnn</VAR><CODE>-done</CODE>).</P>
<p>Onde aplicável, por favor forneça uma linha <code>Version</code> no
<a href="Reporting.html#pseudoheader">pseudo-header</a> de sua
mensagem quando fechar um bug, de forma que o sistema de gerenciamento
de bugs saiba quais releases do pacote contém o conserto.</p>
<p>A pessoa fechando o bug, a pessoa que o relatou e a lista de discussão
<code>debian-bugs-closed</code> irão todos receber uma notificação sobre
o 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
<var>nnn</var><code>-done</code>.</p>
<h2><a name="followup">Mensagens de Acompanhamento</a></h2>
<p>O sistema de gerenciamento de bugs incluirá o endereço da pessoa que
relatou o bug e o endereço do bug (<var>nnn</var><code>@bugs.debian.org</code>) no
cabeçalho <code>Reply-To</code> depois de encaminhar o relatório do bug.
Por favor note que estes são dois endereços distintos.</p>
<p>Caso um desenvolvedor deseje responder a um relatório de bugs o mesmo
deve simplesmente responder a mensagem, respeitando o cabeçalho
<code>Reply-To</code>. Isto <strong>não</strong> fechará o bug.</p>
<p>O sistema de gerenciamento de bugs receberá a mensagem em
<VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>, irá passá-la para o mantenedor do
pacote, arquivar a resposta com o restante dos logs para este relatório
de bugs e encaminhá-lo para <CODE>debian-bugs-dist</CODE>.</P>
<p>Um desenvolvedor pode explicitamente enviar mensagens para a pessoa
que relatou o bug com mensagens para
<var>nnn</var><code>-submitter@bugs.debian.org</code>.</p>
<P>Caso você deseje enviar um acompanhamento para a mensagem que não seja
apropriado para <CODE>debian-bugs-dist</CODE> você pode fazer isso
enviando o mesmo para <VAR>nnn</VAR><CODE>-quiet@bugs.debian.org</CODE> ou para
<VAR>nnn</VAR><CODE>-maintonly@bugs.debian.org</CODE>.
Mensagens para <VAR>nnn</VAR><CODE>-quiet@bugs.debian.org</CODE> são arquivadas no
Sistema de Gerenciamento de Bugs mas não são entregues para quaisquer
indivíduos ou listas de discussão. Mensagens para
<VAR>nnn</VAR><CODE>-maintonly@bugs.debian.org</CODE> são arquivadas no Sistema de
Gerenciamento de Bugs e são entregues somente para o mantenedor do
pacote em questão.</P>
<P><EM>Não</EM> use os recursos `Responder a todos os detinatários' ou
`Acompanhar' de seu cliente de e-mail a menos que você edite os
destinatários para retirá-los substancialmente. Em particular, certifique-se
de não enviar acompanhamentos para <CODE>submit@bugs.debian.org</CODE>.</P>
<p>Para mais informações sobre cabeçalhos para suprimir mensagens de
confirmação e como enviar cópias carbono usando o Sistema de Gerenciamento
de Bugs, veja as <a href="Reporting">instruções para relatar bugs</a>.</P>
<H2><A name="severities">Níveis de Severidade</A></H2>
<P>O sistema de gerenciamento de bugs grava um nível de severidade com
cada relatório de bug. Este é definido como <CODE>normal</CODE> por
padrão, mas pode ser sobreescrito incluindo uma linha
<CODE>Severity</CODE> no pseudo-cabeçalho quando o bug é enviado
(consulte as <A href="Reporting#pseudoheader">instruções para reportar
bugs</A>) ou usando o comando <CODE>severity</CODE> com o
<A href="#requestserv">servidor de requisição de controle</A>.</P>
Múltiplas tags separadas por vírgula, espaço ou ambos.
<P>Os níveis de severidade são :
<DL>
<DT><CODE>critical</CODE>
<DD>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.
<DT><CODE>grave</CODE>
<DD>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.
<DT><CODE>serious</CODE>
<DD>é uma <a href="http://release.debian.org/sarge_rc_policy.txt";>severa
violação da política Debian</a> (isto é, viola uma diretiva
"deve" ou "requerida"), ou, na opinião do mantenedor do pacote, torna o
pacote impróprio para o release.
<DT><CODE>important</CODE>
<DD>um bug que tem um efeito maior na usabilidade de um pacote, sem
torná-lo completamente inutizável para todos.
<DT><CODE>normal</CODE>
<DD>o valor padrão, aplicável a maioria dos bugs.
<DT><CODE>minor</CODE>
<DD>um problema que não afeta a utilidade do pacote e de correção
presumivelmente trivial.
<DT><CODE>wishlist</CODE>
<DD>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.
</DL>
<p>Certas severidades são consideradas
<em><a href="http://bugs.debian.org/release-critical/";>release-critical</a></em>,
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 <strong>critical</strong>, <strong>grave</strong> e
<strong>serious</strong>. Para regras completas e canônicas sobre que questões
merecem tais severidades, veja a lista
<a href="http://release.debian.org/sarge_rc_policy.txt";>Release-Critical
Issues for Sarge</a></p>
<H2><a name="tags">Tags para relatórios de bugs</a></H2>
<p>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.
<p>Tags podem ser definidas incluíndo uma linha <code>Tags</code> no
pseudo-cabeçalho quando o bug é reportado (consulte as
<a href="Reporting#pseudoheader">instruções para reportar bugs</a>)
ou usando o comando <code>tags</code> com o
<a href="#requestserv">servidor de requisição de controle</a>.
<p>As tags de bugs atuais são :
<dl>
<dt><code>patch</code>
<dd>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.
<dt><code>wontfix</code>
<dd>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 corrigir o
problema, possivelmente porque a mudança de comportamento causará
outros problemas, piores, ou possivelmente por outras razões.
<dt><code>moreinfo</code>
<dd>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 como "Isso não funciona".
O que não funciona ?
<dt><code>unreproducible</code>
<dd>Este bug não pode ser reproduzido no sistema do mantenedor.
Assistência de terceiros é necessária para diagnosticar a causa do
problema.
<dt><code>help</code>
<dd>O mantenedor está requisitando ajuda para lidar com este bug.
<dt><code>pending</code>
<dd>Uma solução para este bug foi encontrada e um upload será feito em breve.
<dt><code>fixed</code>
<dd>Este bug está corrigido (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".
<dt><code>security</code>
<dd>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 fazê-lo; 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.
<dt><code>upstream</code>
<dd>Este bug aplica-se a parte do pacote de responsabilidade do
desenvolvedor original.
<dt><code>confirmed</code>
<dd>O mantenedor do pacote verificou, entendeu e concorda com o bug, mas
ainda não consertou. (O use dessa tag é opcional; ela é usada para aqueles
mantenedores que precisam gerenciar uma grande quantidade de bugs em aberto.)
<dt><code>fixed-upstream</code>
<dd>O bug foi corrigido pelo autor, mas não no pacote ainda (por uma razão qualquer:
talvez seja muito complicado fazer o backport da mudança ou uma mudança muito pequena, que
não vale a pena).
<dt><code>fixed-in-experimental</code>
<dd>O bug foi corrigido no pacote da distribuição experimental,
mas ainda nào foi corrigido na distribuição instável.
<dt><code>d-i</code>
<dd>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.
<dt><code>ipv6</code>
<dd>Esse bug está relacionado com o suporte a versão 6 do Protocolo de Internet.
<dt><code>lfs</code>
<dd>Esse bug está relacionado com o suporte a arquivos grandes (maiores que 2 gigabytes).
<dt><code>l10n</code>
<dd>Este bug é relevante para a localização de um pacote.
<dt><code>potato</code>
<dd>Este bug particularmente aplica-se ao release potato do Debian.
<dt><code>woody</code>
<dd>Este bug particularmente aplica-se a distribuição woody.
<dt><code>sarge</code>
<dd>Este bug particularmente aplica-se a distibuição sarge.
<dt><code>sarge-ignore</code>
<dd>Este bug crítico de lançamento será ignorado para permitir o lançamento do sarge.
<strong>Esta tag deve ser usada somente pelo gerente de lançamento; não defina isso sozinho
sem sua autorização explícita.</strong>
<dt><code>etch</code>
<dd>Este bug se aplica particularmente à (ainda não lançada) distribuição etch.
<dt><code>etch-ignore</code>
<dd>Este bug crítico de lançamento será ignorado para permitir o lançamento do etch.
<strong>Esta tag deve ser usada somente pelo gerente de lançamento; não defina isso sozinho
sem sua autorização explícita.</strong>
<dt><code>sid</code>
<dd>Este bug particularmente aplica-se a uma arquitetura que atualmente
ainda não foi lançada (isto é, na distribuição sid).
<dt><code>experimental</code>
<dd>Este bug particularmente aplica-se a distribuição experimental.
</dl>
<p>As últimas cinco tags foram criadas param ser usadas especialmente para
bugs críticos ao release, para os quais é importante conhecer qual
distribuição é afetada para certificar-se que as correções (ou remoções)
aconteçam no local correto.
<H2><A name="forward">Registrando que você passou adiante um relatório de bug</A></H2>
<P>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 gerenciamento de
bugs como abaixo :</P>
<P>Certifique-se de que o campo <CODE>To</CODE> de sua mensagem possua
apenas o(s) endereçõ(s) do(s) autor(es); coloque ambos a pessoa que
reportou o bug e <VAR>nnn</VAR><CODE>-forwarded@bugs.debian.org</CODE>
no campo <CODE>CC</CODE>.</P>
<P>Peça ao autor para preservar o <CODE>CC</CODE> para
<VAR>nnn</VAR><CODE>-forwarded@bugs.debian.org</CODE> quando responder, assim
o sistema de gerenciamento de bugs irá arquivar a resposta com o
relatório original.</P>
<P>Quando o sistema de gerenciamento de bugs recebe uma mensagem em
<VAR>nnn</VAR><CODE>-forwarded</CODE> o mesmo marca o bug relevante
como tendo sido encaminhado para o(s) endereço(s) no campo
<CODE>To</CODE> da mensagem que ele recebe, caso o bug já não esteja
marcado como encaminhado.</P>
<P>Você pode também manipular a informação `encaminhado para' enviando
mensagens para
<A href="server-control"><CODE>control@bugs.debian.org</CODE></A>.</P>
<h2><a name="owner">Alterando o responsável pelo bug</a></h2>
<p>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 um time de desenvolvedores), pode ser útil registrar esse
fato no sistema de processamento de bugs. Para ajudar com isso,
cada bug pode opcionalmente ter um dono.
<p>O dono pode ser configurado adicionando a linha <code>Owner</code> no
pseudo-header quando o bug é enviado (veja as
<a href="Reporting#pseudoheader">instruções para relatar bugs</a>),
ou usando os comandos <code>owner</code> e <code>noowner</code> no
with the <a href="#requestserv">servidor de requisição de controle</a>.
<H2><a name="maintincorrect">Mantenedores de pacotes incorretamente listados</a></H2>
<p>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 <CODE>Maintainer</CODE> do arquivo de controle
modificado. Isto será corrigido quando o upload do pacote for feito;
alternativamente, os mantenedores do repositório podem sobreescrever
o registro do mantenedor de um pacote manualmente, por exemplo se uma
recompilação e re-upload do pacote não é esperada como necessária tão cedo.
Contacte <CODE>override-change@debian.org</CODE> para mudanças no arquivo
de sobreescrita (override file).</P>
<H2><A name="requestserv">Reabrindo, redesignando e manipulando bugs</A></H2>
<P>É possível redesignar 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 os
bugs foram corrigidos. Isto é feito enviando mensagens para
<CODE>control@bugs.debian.org</CODE>.</P>
<P>O <A href="server-control">formato destas mensagens</A> é descrito em
outro documento disponível na World Wide Web ou no arquivo
<CODE>bug-maint-mailcontrol.txt</CODE>. Uma versão em texto puro
pode também ser obtida enviando uma mensagem com a palavra
<CODE>help</CODE> para o servidor no endereço acima.</P>
<h2><a name="subjectscan">Recurso de procura-no-assunto mais-ou-menos obsoleto</a></h2>
<P>Mensagens que chegam em <CODE>submit</CODE> ou <CODE>bugs</CODE> as
quais o Assunto inicie com <CODE>Bug#</CODE><VAR>nnn</VAR> serão tratadas
como tendo sido enviadas para <VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>. Isto é para
compatibilidade anterior com mensagens encaminhadas a partir do endereço
antigo e para pegar mensagens enviadas para <CODE>submit</CODE> por
engano (por exemplo, usando responder para todos os destinatários).</P>
<P>Um esquema similar opera para <CODE>maintonly</CODE>,
<CODE>done</CODE>, <CODE>quiet</CODE> e <CODE>forwarded</CODE>,
os quais tratam mensagens que chegam com uma tag Assunto como tendo
sido enviadas para o endereço
<VAR>nnn-whatever</VAR><CODE>@bugs.debian.org</CODE> correspondente.</P>
<P>Mensagens que chegam com <CODE>forwarded</CODE> puro e
<CODE>done</CODE> - por exemplo, 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.</P>
<h2><a name="x-debian-pr">Recurso <code>X-Debian-PR: quiet</code> obsoleto</a></h2>
<P>É usado para ser possível prevenir que o sistema de gerenciamento
de bugs encaminhe a qualquer lugar mensagens que o mesmo recebeu em
<CODE>debian-bugs</CODE>, colocando uma linha
<CODE>X-Debian-PR: quiet</CODE> no cabeçaho da mensagem atual.</P>
<P>Esta linha de cabeçalho é agora ignorada. Ao invés disso, envie
sua mensagem para <CODE>quiet</CODE> ou
<VAR>nnn</VAR><CODE>-quiet</CODE> (ou <CODE>maintonly</CODE> ou
<VAR>nnn</VAR><CODE>-maintonly</CODE>).</P>
<HR>
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
Reply to: