[LCFC] wml://webwml/portuguese/Bugs/server-control.wml
On 10/14/05, Augusto Cezar Amaral <augusto.cezar@gmail.com> wrote:
> --
> Augusto Cezar Amaral <augusto.cezar@gmail.com>
>
>
>
--
Augusto Cezar Amaral <augusto.cezar@gmail.com>
#use wml::debian::template title="Debian BTS - servidor de controle" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.49"
<h1>Introdução ao servidor de e-mail para controle e manipulação de bugs</h1>
<P>Em adição ao servidor de e-mail em <code>request@bugs.debian.org</code>,
o qual permite a recuperação de dados e documentação de bugs por e-mail,
existe um outro servidor em <code>control@bugs.debian.org</code>, o qual
também permite que relatórios de bugs sejam manipulados de várias maneiras.</P>
<P>O servidor de controle funciona da mesma maneira que o servidor de requisição,
exceto que ele possui comandos adicionais; de fato, é o mesmo programa. Os dois
endereços são separados somente para evitar que usuários cometam erros e causem
problemas quando tentam meramente requisitar informação.</P>
<p>Como os comandos específicos para o servidor de controle alteram o
estado de um bug, uma notificação sobre o processamento dos comandos
é enviado para o mantenedor do pacote para os quais os bugs alterados
estão designados. Adicionalmente, a mensagem para o servidor e as
alterações resultantes são registradas no relatório e portanto
disponiblizadas nas páginas WWW.</p>
<P>Por favor consulte a
<A href="server-request#introduction">introdução ao servidor de requisição</A>
disponível na World Wide Web, no arquivo
<code>bug-log-mailserver.txt</code> ou enviando
<code>help</code> para o servidor de e-mail para detalhes básicos de operações do
servidor de e-mail e os comandos básicos disponíveis ao enviar mensagens para
ambos os endereços.</P>
<P>O <A href="server-refcard">cartão de referência</A> para o servidor de e-mail
está disponível via WWW em <code>bug-mailserver-refcard.txt</code> ou por e-mail
usando o comando <code>refcard</code>.</P>
<H1>Comandos disponíveis no servidor de e-mail de controle</H1>
<dl>
<dt><code>reassign</code> <var>número do bug</var> <var>pacote</var>
[ <var>versão</var> ]
<dd>
Registra que o bug #<var>número do bug</var> é um bug em <var>pacote</var>.
Pode ser usado para definir o pacote caso o usuário esqueça o pseudo-cabeçalho
ou para mudar a atribuição anterior. Nenhuma notificação é enviada para ninguém
(a não ser a informação normal no processamento da transcrição).
<p>Se você fornecer uma <var>versão</var>, o sistema de acompanhamento de bugs
perceberá que o bug afeta aquela versão do pacote recém-atribuído.
<dt><code>reopen</code> <var>número do bug</var>
[ <var>endereço-de-origem</var> | <code>=</code> | <code>!</code> ]
<dd>
Reabre #<var>número do bug</var> caso o mesmo esteja fechado.
<p>Por padrão, ou se você especificar <code>=</code>, a pessoa que enviou
originalmente o relatório de bug continua como a origem do relatório, assim
a mesma poderá receber uma notificação quando o bug for fechado novamente.</p>
<p>Caso você forneça um <var>endereço-de-origem</var> a origem será definida
para o endereço que você fornecer. Caso você deseje se tornar a nova origem
do relatório reaberto você pode usar o atalho <code>!</code> ou especificar
seu próprio endereço de e-mail.</p>
<p>Normalmente é uma boa idéia dizer para a pessoa que está prestes a ser
registrada como a origem que você está reabrindo o relatório, assim ela saberá
que poderá esperar a notificação que ela receberá quando o bug for fechado
novamente.</p>
<p>Caso o bug não esteja fechado, reabrir o mesmo não resultará em nada, nem mesmo
mudar a origem. Para alterar a origem de um relatório de bug aberto, use o
comando <code>submitter</code>; note que isto informará o endereço da pessoa que fez a mudança.
<p>Se o bug foi registrado como fechado em determinada versão de um pacote
mas reapareceu em uma versão posterior, utilize o comando <code>found</code>
em vez disso.
<dt><code>found</code> <var>número do bug</var> [ <var>versão</var> ]
<dd>Registra que #<var>número do bug</var> foi encontrado em determinada
<var>versão</var> do pacote ao qual ele está atribuído.
<p>O sistema de acompanhamento de bugs utiliza essa informação, em conjunto
com as versões corrigidas que são registradas quando bugs são fechados, para
exibir listas de bugs abertos em várias versões de cada pacote. O sistema considera
um bug como aberto quando não há uma versão corrigida, ou quando o bug é descoberto após
ter sido corrigido.
<p>Caso nenhuma <var>versão</var> seja fornecida, a lista de versões corrigidas para o bug
é esvaziada. Isto é idêntico ao comportamento do <code>reopen</code>.
<p>Este comando foi introduzido como substituto do <code>reopen</code> porque
era difícil adicionar uma <var>versão</var> à sintaxe desse comando sem sofrer
ambigüidade.
<dt><code>notfound</code> <var>número do bug</var> <var>versão</var>
<dd>Remove o registro de que #<var>número do bug</var> foi encontrado em determinada
<var>versão</var> do pacote ao qual ele está atribuído.
<p>Isso é diferente de fechar o bug na versão especificada, uma vez que o bug
também não está listado como corrigido naquela versão; nenhuma informação sobre a
versão será conhecida. O objetivo é corrigir erros no registro de um bug quando foi encontrado.
<dt><code>submitter</code> <var>bugnumber</var>
<var>originator-address</var> | <code>!</code>
<dd>
Altere a origem do #<var>bugnumber</var> para
<var>originator-address</var>.
<p>Se você deseja ser a nova origem do relatório voce pode usar o
<code>!</code> ou especificar seu próprio endereço de email.</p>
<p>Enquanto o comando <code>reopen</code> altera a origem dos outros bugs mesclados com um que está sendo aberto novamente, <code>submiiter</code> não afeta bugs mesclados.</p>
<dt><code>forwarded</code> <var>número do bug</var> <var>endereço</var>
<dd>
Note que <var>número do bug</var> foi encaminhado para o mantenedor original
em <var>endereço</var>. Atualmente isso não encaminha o relatório. Isso pode
ser usado para modificar um endereço de encaminhamento incorreto existente ou
para registrar um novo endereço para um bug que não tenha sido marcado como
tendo sido encaminhado.
<dt><code>notforwarded</code> <var>número do bug</var>
<dd>
Esquece qualquer vestígio que <var>número do bug</var> foi encaminhado para
qualquer mantenedor original. Caso o bug não tenha sido registrado como tendo
sido encaminhado então isso não causará nada.
<dt><code>retitle</code> <var>número do bug</var> <var>novo-título</var>
<dd>
Muda o título de um relatório de bug para o especificado (o padrão é
o cabeçalho <code>Assunto</code> da mensagem do relatório original).
<p>Diferente da maioria dos outros comandos de manipulação de bugs, quando
usado em um ou em um conjunto de relatórios unidos, modificará somente o
título do bug individual requisitado e não todos aqueles com os quais o mesmo
está unido.
<dt><code>severity</code> <var>número do bug</var> <var>severidade</var>
<dd>
<p>Define o nível de severidade para o relatório de bug #<var>número do bug</var>
para <var>severidade</var>. Nenhuma notificação é enviada para o usuário que
reportou o bug.</p>
<p>As severidades são <code>critical</code>, <code>grave</code>,
<code>serious</code>, <code>important</code>, <code>normal</code>,
<code>minor</code>, e <code>wishlist</code>.
<p>Para <A href="Developer#severities">os significados das severidades</A> por
favor consulte o documentação geral para desenvolvedores do sistema de bugs.
<dt><code>clone</code> <var>número do bug</var> [ <var>novos IDs</var> ]
<dd>O controle de comando clone permite duplicar um relatório de bug. Ele é
útil quando um único relatório indica que múltiplos bugs distintos ocorreram.
"<var>Novos IDs</var>" são números negativos, separados por espaços, que podem
ser usados em subsequentes comandos control para se referir aos novos bugs
duplicados. Um novo relatório é gerado para cada novo ID.
<p>Exemplo de uso :</p>
<pre>
clone 12345 -1 -2
reassign -1 foo
retitle -1 foo: foo fede
reassign -2 bar
retitle -2 bar: bar fede quando usado com foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
retitle -3 foo: foo fede
merge -1 -3
</pre>
<dt><code>merge</code> <var>número do bug</var> <var>número do bug</var> ...
<dd>
Junta dois ou mais relatórios de bug. Quando relatórios são unidos, abrir,
fechar, marcar ou desmarcar como encaminhados e reatribuir quaisquer dos bugs
para um novo pacote terá o efeito idêntico em todos os relatórios que foram
unidos.
<p>Antes que os bugs possam ser unidos os mesmos precisam estar exatamente
no mesmo estado: ou todos são bugs abertos ou todos são bugs fechados, com
o mesmo endereço de encaminhamento para o autor original ou todos marcados
como encaminhados, todos atribuídos para o mesmo pacote(s) (uma comparação
exata de strings é feita no pacote para o qual o bug está sendo atribuído),
e todos da mesma severidade. Caso os mesmos não estejam inicialmente no mesmo
estado você deve usar <code>reassign</code>, <code>reopen</code> e assim por
diante para certificar-se que os mesmos estejam no mesmo estado antes, usando
<code>merge</code>. Os títulos não precisam ser os mesmos, e não serão
afetados pelo merge. As tags também não precisam ser as mesmas, elas seram
unidas.</p>
<p>Caso qualquer um dos bugs listados em um comando <code>merge</code> já esteja
unido com um outro bug, todos os relatórios unidos com quaisquer um dos relatórios
listados serão todos unidos juntamente. Unir é como equalizar: é reflexivo,
transitivo e simétrico.</p>
<P>Unir relatórios faz com que uma nota apareça no relatório de log de cada
relatório de bug; nas páginas WWW isto se reflete em ligações de inclusões para
outros bugs.</p>
<P>Relatórios unidos são todos expirados simultaneamente e somente quando todos
os relatórios separadamente atinjam os critérios para expiração.
<dt><code>unmerge</code> <var>número do bug</var>
<dd>
Desconecta um relatório de bug de quaisquer outros relatórios com os quais o
relatório em questão possa ter sido unido. Caso o relatório listado seja unido
com diversos outros então os mesmos serão todos mantidos unidos; somente suas
associações com o bug explicitamente nomeado serão removidas.
<p>Caso muitos relatórios de bugs sejam unidos e você deseje separá-los em dois
grupos separados de relatórios unidos você deve desconectar cada relatório em
um dos novos grupos separadamente e então uní-los na forma do novo grupo
requerido.</p>
<p>Você pode somente desconectar um relatório com cada comando
<code>unmerge</code>; caso você queira desconectar mais de um bug simplesmente
inclua diversos comandos <code>unmerge</code> em sua mensagem.
<dt><code>tags</code> <var>número_do_bug</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var> ... ]
<dd>Define tags para o relatório de bug #<var>número_do_bug</var>. Nenhuma
notificação é enviada para o usuário que relatou o bug. Definir a ação
como <code>+</code> significa que cada <var>tag</var> dada deve ser
adicionada, <code>-</code> significa que cada <var>tag</var> deve ser
removida, e <code>=</code> significa que o conjunto atual de tags deve
ser ignorado e definido a partir da lista fornecida. A ação padrão é
adicionar.
<p>Exemplo de uso:</p>
<pre>
\# o mesmo que 'tags 123456 + patch'
tags 123456 patch
\# o mesmo que 'tags 123456 + help security'
tags 123456 help security
\# adiciona as tags 'fixed' e 'pending'
tags 123456 + fixed pending
\# remove a tag 'unreproducible'
tags 123456 - unreproducible
\# define as tags exatamente como 'moreinfo' e 'unreproducible'
tags 123456 = moreinfo unreproducible
</pre>
<p>As tags disponíveis atualmente incluem <code>patch</code>, <code>wontfix</code>,
<code>moreinfo</code>, <code>unreproducible</code>, <code>help</code>,
<code>pending</code>, <code>fixed</code>,
<code>fixed-in-experimental</code>, <code>fixed-upstream</code>,
<code>security</code>,
<code>upstream</code>, <code>confirmed</code>, <code>d-i</code>,
<code>ipv6</code>, <code>lfs</code>, <code>l10n</code>
<code>potato</code>, <code>woody</code>, <code>sarge</code>,
<code>sarge-ignore</code>, <code>etch</code>, <code>etch-ignore</code>,
<code>sid</code> e <code>experimental</code>.
<p>Para <a href="Developer#tags">os siginficados das tags</a> por favor consulte
a documentação geral para desenvolvedores do sistema de bugs.
<dt><code>close</code> <var>número do bug</var> [ <var>versão-corrigida</var> ]
(ultrapassado)
<dd>
Fecha o relatório de bug #<var>número do bug</var>.
<p>Uma notificação é enviada para o usuário que reportou o bug, mas (em contraste
de enviar uma mensagem para <var>número do bug</var><code>-done@bugs.debian.org</code>) o texto
da mensagem <strong>não</strong> é incluído na notificação. O mantenedor que fecha o relatório precisa
certificar-se, provavelmente enviando uma mensagem separada, que o usuário que
reportou o bug fique sabendo a razão pela qual o bug está sendo fechado. O uso deste
comando é portanto desencorajado. Veja as informações para desenvolvedores
sobre <a href="Developer#closing">como fechar um relatório de bug</a>.
<p>Se você fornecer uma <var>versão-corrigida</var>, o sistema de acompanhamento de bugs
perceberá que o bug foi corrigido para aquela versão do pacote.
<dt><code>package</code> [ <var>packagename</var> ... ]
<dd>Limita os próximos comandos, fazendo com que eles sejam aplicados
somente em erros relativos aos pacotes listados. Você pode listar um ou
mais pacotes. Se você não listar nenhum pacote, os próximos comandos
serão aplicados em qualquer erro. Você é encorajado a usar isto como uma
medida de segurança para se você usar os números de erro errados.
<p>Exemplo de uso:</p>
<pre>
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar sucks
severity 123456 normal
package
severity 234567 wishlist
</pre>
<dt><code>owner</code> <var>número do bug</var> <var>endereço</var> | <code>!</code>
<dd>Coloca <var>endereço</var> como "dono" do #<var>número do bug</var>.
O dono de um bug clama a responsabilidade de corrigí-lo e irá receber todos
os e-mails a seu respeito. Isto é útil para dividir o trabalho em pacotes que
possuem equipes de mantenedores.
<p>Se você quer se tornar o dono de um bug, você pode usar a abreviação <code>!</code>
ou especificar seu endereço de e-mail.</p>
<dt><code>noowner</code> <var>número do bug</var>
<dd>Esquece qualquer dono que o bug tenha além do mantenedor usual. Se o bug não tiver
algum dono gravado, esta opção não fará nada.
<dt><code>#</code>...
<dd>Comentário de uma linha. O <code>#</code> precisa estar no começo da linha.
O texto dos comentários será incluído na mensagem enviada pelo remetente e
para os mantenedores afetados, portanto você pode utilizar isto para documentar
as razões de seus comandos.
<dt><code>quit</code>
<dt><code>stop</code>
<dt><code>thank</code>...
<dt><code>--</code>...
<dd>Informa ao servidor de controle para parar de processar a mensagem; é possível incluir explicações, assinaturas
ou qualquer outra coisa no resto da mensagem, nada disso será detectado pelo servidor de controle.
</dl>
<hr>
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
Reply to: