----- Forwarded message from Tassia Camoes <tassia@debian-ba.org> -----
Date: Mon, 26 Jun 2006 11:10:08 -0400
From: Tassia Camoes <tassia@debian-ba.org>
To: "Felipe Augusto van de Wiel (faw)" <felipe@cathedrallabs.org>
Subject: Re: [RFR] wml://webml/portuguese/Bugs/server-control.wml
User-Agent: Mutt/1.5.11+cvs20060403
Oi Faw,
Concordo com as suas alterações.
Adicionei aspas em "found" no paragrafo abaixo:
<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 é encontrado ("found") novamente após ter sido corrigido.
E ainda corrigi alguns errinhos, na mesma linha das suas correções.
Arquivo corrigido em anexo. Confere aí se está ok.
Abraços,
Tássia.
On Sun, Jun 25, 2006 at 10:53:12PM -0300, Felipe Augusto van de Wiel (faw) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/25/2006 02:32 PM, Tassia Camoes wrote:
> > Olá,
> >
> > Segue arquivo em anexo para revisao.
> > Abraços,
>
> Tassia, aproveitei pra revisar outros itens e sugerir mudanças.
> O diff está em anexo. Note que eu converti o formato de quebra de linha
> do dos para o unix. O patch atual não tem os ^M no final, portanto antes
> de aplicar o patch, se você usa vi, faça um :set ff=unix no ser arquivo
> .wml.
>
>
> Eu também reverti poucas mudanças que você fez e fiz ajustes de
> comprimento de linha, se aprovar as alterações envio ao repositório, se
> tiver dúvidas ou questionamentos vamos discutí-las para que o WML possa
> ser publicado o quanto antes.
>
>
> Abraço,
>
> - --
> Felipe Augusto van de Wiel (faw)
> "Debian. Freedom to code. Code to freedom!"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
>
> iD8DBQFEnz4HCjAO0JDlykYRAr9KAKCnl7jG8lR5GZNnhGTU0qAhjDKO+ACgzjJ8
> g+yoTZFVIKgK5DuD7c/xwME=
> =CwWJ
> -----END PGP SIGNATURE-----
> --- server-control.wml 2006-06-25 22:50:17.385101552 -0300
> +++ faw-server-control.wml 2006-06-25 22:50:21.885417400 -0300
> @@ -27,7 +27,7 @@
> <code>bug-log-mailserver.txt</code> ou enviando
> <code>help</code> para qualquer um dos servidores para detalhes b?sicos de
> opera??es dos servidores de e-mail e os comandos b?sicos dispon?veis ao enviar
> -mensagens para ambos os endere?os.</P>
> +mensagens para qualquer um dos endere?os.</P>
>
> <P>O <A href="server-refcard">cart?o de refer?ncia</A> para os servidores de
> e-mail est? dispon?vel via WWW em <code>bug-mailserver-refcard.txt</code> ou
> @@ -41,7 +41,7 @@
> [ <var>vers?o</var> ]
> <dd>
>
> -Registra que o bug #<var>n?mero do bug</var> ? um bug em <var>pacote</var>.
> +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 tenha esquecido o
> pseudo-cabe?alho ou para mudar uma atribui??o anterior. Nenhuma notifica??o
> ? enviada para ningu?m (a n?o ser a informa??o normal no processamento da
> @@ -50,45 +50,45 @@
> <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-do-remetente</var> | <code>=</code> | <code>!</code> ]
> +<dt><code>reopen</code> <var>n?mero-do-bug</var>
> + [ <var>endere?o-do-relator</var> | <code>=</code> | <code>!</code> ]
> <dd>
>
> -Reabre #<var>n?mero do bug</var> caso o mesmo esteja fechado.
> +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 o remetente 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-do-remetente</var> o remetente ser?
> +<p>Caso voc? forne?a um <var>endere?o-do-relator</var> o remetente ser?
> definido como o endere?o que voc? fornecer. Caso voc? deseje se tornar o novo
> remetente 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 avisar ? pessoa que est? prestes a ser
> -registrada como o remetente que voc? est? reabrindo o relat?rio, assim ela
> -saber? que poder? esperar a notifica??o que ela receber? quando o bug for
> +registrada como o relator que voc? est? reabrindo o relat?rio, assim ela
> +estar? avisada para esperar a notifica??o que 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 o remetente. Para alterar o remetente de um relat?rio de bug
> +mesmo mudar o relator. Para alterar o remetente de um relat?rio de bug
> aberto, use o comando <code>submitter</code>; note que isto notificar? o
> -remetente original de que esta mudan?a foi feita.
> +relator original sobre esta mudan?a.
>
> <p>Se o bug foi registrado como fechado em determinada vers?o de um pacote
> -mas reapareceu em uma vers?o posterior, ? prefer?vel utilizar o comando
> +mas reapareceu em uma vers?o posterior, ? melhor utilizar o comando
> <code>found</code>.
>
> -<dt><code>found</code> <var>n?mero do bug</var> [ <var>vers?o</var> ]
> +<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
> +<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 ? encontrado novamente ap?s ter sido corrigido.
> +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 ? encontrado (found) mais recentemente do que havia 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>.
> @@ -97,9 +97,9 @@
> 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>
> +<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
> +<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
> @@ -107,86 +107,94 @@
> sobre aquela vers?o ser? conhecida. O objetivo ? corrigir erros no registro de
> quando um bug foi encontrado.
>
> -<dt><code>submitter</code> <var>num?ro do bug</var>
> -<var>endere?o-do-remetente</var> | <code>!</code>
> +<dt><code>submitter</code> <var>n?mero-do-bug</var>
> +<var>endere?o-do-relator</var> | <code>!</code>
> <dd>
>
> -Altera o remetente do #<var>num?ro do bug</var> para
> -<var>endere?o-do-remetente</var>.
> +Altera o relador do #<var>n?mero-do-bug</var> para
> +<var>endere?o-do-relator</var>.
>
> <p>Se voc? deseja ser o novo remetente do relat?rio voc? pode usar o
> <code>!</code> ou especificar seu pr?prio endere?o de email.</p>
>
> -<p>Enquanto o comando <code>reopen</code> altera o remetente dos outros bugs
> -unidos com o que est? sendo aberto novamente, <code>submitter</code> n?o
> +<p>Enquanto o comando <code>reopen</code> altera o relator dos outros bugs
> +unidos com o que est? sendo aberto novamente, <code>submitter</code> n?o
> afeta bugs unidos.</p>
>
> -<dt><code>forwarded</code> <var>n?mero do bug</var> <var>endere?o</var>
> +<dt><code>forwarded</code> <var>n?mero-do-bug</var> <var>endere?o</var>
> <dd>
>
> -Marca que <var>n?mero do bug</var> foi encaminhado para o mantenedor original
> +Marca que <var>n?mero-do-bug</var> foi encaminhado para o mantenedor original
> em <var>endere?o</var>. Isto na verdade n?o encaminha o relat?rio. Isso pode
> -ser usado para modificar um endere?o de encaminhamento existente incorreto ou
> +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>
> +<dt><code>notforwarded</code> <var>n?mero-do-bug</var>
> <dd>
>
> -Esquece qualquer vest?gio de que <var>n?mero do bug</var> foi encaminhado para
> -qualquer mantenedor original. Caso o bug n?o tenha sido marcado como tendo
> -sido encaminhado ent?o isso n?o causar? nada.
> +Esquece qualquer vest?gio de que <var>n?mero do bug</var> foi encaminhado
> +para qualquer mantenedor original. Caso o bug n?o tenha sido marcado 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>
> +<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 campo <code>Assunto</code> do cabe?alho da mensagem do relat?rio original).
> +o cabe?alho <code>Subject</code> — Assunto — da mensagem do
> +relat?rio original).
>
> <p>Diferente da maioria dos outros comandos de manipula??o de bugs, quando
> -usado em um de 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.
> +usado em um relat?rio de 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>
> +<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>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 do sistema de bugs para desenvolvedores.
> +favor consulte a documenta??o geral dos desenvolvedores sobre o sistema de
> +bugs.
>
> -<dt><code>clone</code> <var>n?mero do bug</var> <var> novo ID</var> [ <var>novos IDs</var> ... ]
> +<dt><code>clone</code> <var>n?mero-do-bug</var> <var>NovoID</var> [ <var>Novos IDs</var> ... ]
>
> <dd>O comando de controle clone permite duplicar um relat?rio de bug. Ele ?
> - ?til quando um ?nico relat?rio na verdade 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 comandos de controle subseq?entes para se
> - referir aos novos bugs duplicados. Um novo relat?rio ? gerado para cada novo
> - ID.
> + ?til quando um ?nico relat?rio na verdade 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 comandos de controle
> + subseq?entes para se referir aos novos bugs duplicados. Um novo relat?rio
> + ? gerado para cada novo ID.
>
> - <p>Exemplo de uso :</p>
> + <p>Exemplo de uso:</p>
>
> <pre>
> clone 12345 -1 -2
> reassign -1 foo
> - retitle -1 foo: foo sucks
> + retitle -1 foo: foo fede
> reassign -2 bar
> - retitle -2 bar: bar sucks when used with foo
> + retitle -2 bar: bar fede quando usado com foo
> severity -2 wishlist
> clone 123456 -3
> reassign -3 foo
> - retitle -3 foo: foo sucks
> + retitle -3 foo: foo fede
> merge -1 -3
> </pre>
> +
> + <p>Lembre-se de escrever o seu relat?rio de bug em ingl?s, se precisar de
> + ajuda voc? pode enviar uma mensagem para
> + <email "debian-devel-portuguese@lists.debian.org"> ou para
> + <email "debian-l10n-portuguese@lists.debian.org">.</p>
> +
>
> -<dt><code>merge</code> <var>n?mero do bug</var> <var>n?mero do bug</var> ...
> +<dt><code>merge</code> <var>n?mero-do-bug</var> <var>n?mero-do-bug</var> ...
> <dd>
>
> Une dois ou mais relat?rios de bug. Quando relat?rios s?o unidos, abrir,
> @@ -196,43 +204,42 @@
>
> <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 n?o marcados
> -como encaminhados, todos atribu?dos para o(s) mesmo(s) pacote(s) (uma compara??o
> -exata de strings ? feita no pacote para o qual o bug est? 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 de usar
> -<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 ser?o
> -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 eq?alizar: ?
> +o mesmo endere?o de encaminhamento para o autor original ou todos n?o
> +marcados como encaminhados, todos atribu?dos para o(s) mesmo(s) pacote(s)
> +(uma compara??o exata de strings ? feita no pacote para o qual o bug est?
> +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 de usar <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 ser?o 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. Unir ? como a igualdade: ?
> 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 inclus?es de links para
> +<P>Unir relat?rios faz com que uma nota apare?a no log de cada relat?rio
> +de bug; nas p?ginas WWW isto faz com que sejam inclu?dos links para os
> 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.
> +<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>forcemerge</code> <var>n?mero do bug</var> <var>n?mero do bug</var>
> -...</dt>
> +<dt><code>forcemerge</code> <var>n?mero-do-bug</var> <var>n?mero-do-bug</var> ...</dt>
> <dd>Une for?adamente dois ou mais relat?rios de bug. O primeiro bug listado
> ? o bug principal, e suas configura??es (as configura??es que devem ser
> iguais numa uni?o normal) s?o atribu?das aos bugs listados em seguida.
> - Para evitar que erros tipogr?ficos unam bugs erroneamente, os bugs precisam
> - estar no mesmo pacote. Veja o texto acima para uma descri??o do que uni?o
> - significa.
> + Para evitar que erros de digita??o unam bugs erroneamente, os bugs precisam
> + estar no mesmo pacote. Veja o texto acima para uma descri??o do que uni?o
> + ("merge") significa.
>
> <p>Note que isto torna poss?vel o fechamento de bugs na uni?o; voc? ?
> - respons?vel por notificar as pessoas que relataram os bugs com uma
> - mensagem de fechamento apropriada se voc? fizer isto.</p>
> + respons?vel por notificar os relatores dos bugs com uma mensagem de
> + fechamento apropriada se voc? fizer isto.</p>
> </dd>
>
> -<dt><code>unmerge</code> <var>n?mero do bug</var>
> +<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
> @@ -249,14 +256,14 @@
> <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> ... ]
> +<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
> + <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 redefinido a partir da lista fornecida. A a??o padr?o ?
> + ser ignorado e definido a partir da lista fornecida. A a??o padr?o ?
> adicionar.
>
> <p>Exemplo de uso:</p>
> @@ -291,35 +298,36 @@
> <code>sid</code> e <code>experimental</code>.
>
> <p>Para <a href="Developer#tags">os significados das tags</a> por favor
> - consulte a documenta??o geral do sistema de bugs para desenvolvedores.
> + consulte a documenta??o geral dos desenvolvedores sobre sistema de bugs.
>
> -<dt><code>close</code> <var>n?mero do bug</var> [ <var>vers?o-corrigida</var> ]
> +<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>.
> +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 (ao inv?s
> -de enviar uma mensagem para
> -<var>n?mero do bug</var><code>-done@bugs.debian.org</code>) o texto da mensagem
> -que fechou o bug <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>Uma notifica??o ? enviada para o usu?rio que reportou o bug, mas (ao
> +contr?rio do envio de uma mensagem para
> +<var>n?mero-do-bug</var><code>-done@bugs.debian.org</code>) o texto da
> +mensagem que fechou o bug <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.
> +acompanhamento de bugs perceber? que o bug foi corrigido para aquela
> +vers?o do pacote.
>
> -<dt><code>package</code> [ <var>nome de pacote</var> ... ]
> +<dt><code>package</code> [ <var>nome-do-pacote</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 cso de voc? usar acidentalmente os n?meros de bug
> - errados.
> + ser?o aplicados em todos os bugs. Voc? ? encorajado a usar isto como uma
> + medida de seguran?a para o caso de voc?, acidentalmente, usar os n?meros
> + errados dos relat?rios de bug.
>
> <p>Exemplo de uso:</p>
>
> @@ -328,33 +336,33 @@
> reassign 123456 bar 1.0-1
>
> package bar
> - retitle 123456 bar: bar sucks
> + retitle 123456 bar: bar fede
> severity 123456 normal
> -
> +
> package
> severity 234567 wishlist
> </pre>
>
> -<dt><code>owner</code> <var>n?mero do bug</var> <var>endere?o</var> | <code>!</code>
> +<dt><code>owner</code> <var>n?mero-do-bug</var> <var>endere?o</var> | <code>!</code>
>
> - <dd>Define <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.
> + <dd>Define <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>
> +<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 registrado, 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
> + <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>
> @@ -362,8 +370,8 @@
> <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
> + <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>
> @@ -373,4 +381,3 @@
> #use "otherpages.inc"
>
> #use "$(ENGLISHDIR)/Bugs/footer.inc"
> -
--
Tássia Camões - http://tassia.org
0x1D1D1702 - http://pgp.mit.edu
#use wml::debian::template title="Debian BTS — servidor de controle" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.53"
<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 por possuir 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 qualquer um dos servidores para detalhes básicos de
operações dos servidores de e-mail e os comandos básicos disponíveis ao enviar
mensagens para qualquer um dos endereços.</P>
<P>O <A href="server-refcard">cartão de referência</A> para os servidores 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 tenha esquecido o
pseudo-cabeçalho ou para mudar uma 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-do-relator</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 o remetente 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-do-relator</var> o remetente será
definido como o endereço que você fornecer. Caso você deseje se tornar o novo
remetente 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 avisar à pessoa que está prestes a ser
registrada como o relator que você está reabrindo o relatório, assim ela
estará avisada para esperar a notificação que 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 o relator. Para alterar o remetente de um relatório de bug
aberto, use o comando <code>submitter</code>; note que isto notificará o
relator original sobre esta mudança.
<p>Se o bug foi registrado como fechado em determinada versão de um pacote
mas reapareceu em uma versão posterior, é melhor utilizar o comando
<code>found</code>.
<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 é encontrado ("found") novamente 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 aquela versão será conhecida. O objetivo é corrigir erros no registro de
quando um bug foi encontrado.
<dt><code>submitter</code> <var>numéro-do-bug</var>
<var>endereço-do-relator</var> | <code>!</code>
<dd>
Altera o relator do #<var>numéro-do-bug</var> para
<var>endereço-do-relator</var>.
<p>Se você deseja ser o novo relator do relatório você pode usar o
<code>!</code> ou especificar seu próprio endereço de email.</p>
<p>Enquanto o comando <code>reopen</code> altera o relator dos outros bugs
unidos com o que está sendo aberto novamente, <code>submitter</code> não
afeta bugs unidos.</p>
<dt><code>forwarded</code> <var>número-do-bug</var> <var>endereço</var>
<dd>
Marca que <var>número-do-bug</var> foi encaminhado para o mantenedor original
em <var>endereço</var>. Isto na verdade 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 de que <var>número-do-bug</var> foi encaminhado
para qualquer mantenedor original. Caso o bug não tenha sido marcado 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>Subject</code> — Assunto — da mensagem do
relatório original).
<p>Diferente da maioria dos outros comandos de manipulação de bugs, quando
usado em um relatório de 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 dos desenvolvedores sobre o sistema de
bugs.
<dt><code>clone</code> <var>número-do-bug</var> <var>novo ID</var> [ <var>Novos IDs</var> ... ]
<dd>O comando de controle clone permite duplicar um relatório de bug. Ele é
útil quando um único relatório na verdade 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 comandos de controle
subseqüentes 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>
<p>Lembre-se de escrever o seu relatório de bug em inglês. Se precisar de
ajuda você pode enviar uma mensagem para
<email "debian-devel-portuguese@lists.debian.org"> ou para
<email "debian-l10n-portuguese@lists.debian.org">.</p>
<dt><code>merge</code> <var>número-do-bug</var> <var>número-do-bug</var> ...
<dd>
Une 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 não
marcados como encaminhados, todos atribuídos para o(s) mesmo(s) pacote(s)
(uma comparação exata de strings é feita no pacote para o qual o bug está
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 de que os mesmos
estejam no mesmo estado antes de usar <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 serão 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. Unir é como a igualdade: é
reflexivo, transitivo e simétrico.</p>
<P>Unir relatórios faz com que uma nota apareça no log de cada relatório
de bug; nas páginas WWW isto faz com que sejam incluídos links para os
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>forcemerge</code> <var>número-do-bug</var> <var>número-do-bug</var>
...</dt>
<dd>Une forçadamente dois ou mais relatórios de bug. O primeiro bug listado
é o bug principal, e suas configurações (as configurações que devem ser
iguais numa união normal) são atribuídas aos bugs listados em seguida.
Para evitar que erros de digitação unam bugs erroneamente, os bugs precisam
estar no mesmo pacote. Veja o texto acima para uma descrição do que união
significa.
<p>Note que isto torna possível o fechamento de bugs na união; você é
responsável por notificar os relatores dos bugs com uma mensagem de
fechamento apropriada se você fizer isto.</p>
</dd>
<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 significados das tags</a> por favor
consulte a documentação geral dos desenvolvedores sobre o 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 (ao
contrário do envio de uma mensagem para
<var>número-do-bug</var><code>-done@bugs.debian.org</code>) o texto da
mensagem que fechou o bug <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>nome-de-pacote</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 todos os bugs. Você é encorajado a usar isto como uma
medida de segurança para caso de você, acidentalmente, usar os números
errados dos relatórios de bug.
<p>Exemplo de uso:</p>
<pre>
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar fede
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>Define <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 registrado, 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"
----- End forwarded message -----
--
Tássia Camões - http://tassia.org
0x1D1D1702 - http://pgp.mit.edu
Attachment:
signature.asc
Description: Digital signature