|
Olá, Em 2012 o Claudio Filho enviou uma revisão [1] desse arquivo que não foi aproveitado na época. A versão atual [2] em português no site do Debian é de 2012, e está desatualizada em relação a versão em inglês que é de 2015. Fiz uma revisão da versão atual de 2015, aproveitando boa parte do arquivo do Claudio, e inserindo novos trechos. Estou enviando em anexo o patch para revisão/aplicação. [1] https://lists.debian.org/debian-l10n-portuguese/2012/05/msg00086.html [2] https://anonscm.debian.org/viewvc/webwml/webwml/portuguese/Bugs/server-control.wml Abraços, -- Paulo Henrique de Lima Santana (phls) Membro da Comunidade Curitiba Livre Fone: +55 (41) 9198-1897 Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450 |
Index: server-control.wml
===================================================================
RCS file: /cvs/webwml/webwml/portuguese/Bugs/server-control.wml,v
retrieving revision 1.47
diff -u -r1.47 server-control.wml
--- server-control.wml 17 Nov 2012 20:36:23 -0000 1.47
+++ server-control.wml 6 Oct 2016 20:23:26 -0000
@@ -1,13 +1,13 @@
#use wml::debian::template title="Debian BTS — servidor de controle" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
-#use wml::debian::translation-check translation="1.76" translation_maintainer="Felipe Augusto van de Wiel (faw)"
+#use wml::debian::translation-check translation="1.103" translation_maintainer="Felipe Augusto van de Wiel (faw)"
<h1>Introdução ao servidor de e-mail para controle e manipulação de bugs</h1>
<p>
-Assim como <code>request@bugs.debian.org</code> permite a <a
-href="server-request">obtenção de dados e documentação de bugs por
-e-mail</a>, <code>control@bugs.debian.org</code>,
+Assim como <code>request@bugs.debian.org</code> permite a
+<a href="server-request">obtenção de dados e documentação de bugs por e-mail</a>,
+<code>control@bugs.debian.org</code>
permite que os relatórios de bug sejam manipulados de várias formas.
</p>
@@ -20,9 +20,9 @@
</p>
<p>
-Como os comandos especÃficos para o servidor de controle alteram o
+Como os comandos especÃficos para o servidor de controle na realidade 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
+é enviado para o mantenedor do(s) pacote(s) 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.
@@ -33,7 +33,7 @@
<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
+<code>help</code> para qualquer servidor de e-mail 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>
@@ -55,7 +55,7 @@
<td align="center">Misc.</td>
</tr>
<tr>
- <!-- General -->
+ <!-- Geral -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#reassign">reassign</a></li>
@@ -63,9 +63,12 @@
<li><a href="#tag">tags</a></li>
<li><a href="#retitle">retitle</a></li>
<li><a href="#submitter">submitter</a></li>
+ <li><a href="#affects">affects</a></li>
+ <li><a href="#summary">summary</a></li>
+ <li><a href="#outlook">outlook</a></li>
</ul>
</td>
- <!-- Versioning -->
+ <!-- Versionamento -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#found">found</a> | <a href="#notfound">notfound</a></li>
@@ -74,7 +77,7 @@
<!-- <dt>(close)</dt> Obsoleto -->
</ul>
</td>
- <!-- Duplicates -->
+ <!-- Duplicados -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#merge">merge</a> | <a href="#unmerge">unmerge</a></li>
@@ -104,7 +107,7 @@
<var>pacote</var> [ <var>versão</var> ]</a></dt>
<dd>
<p>
- 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 no <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
@@ -113,14 +116,14 @@
<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.
+ perceberá que o bug afeta aquela versão do pacote recém atribuÃdo.
</p>
<p>
Você pode atribuir um bug para dois pacotes de uma vez separando os
- nomes dos pacotes com uma vÃrgula. <em>Entretanto</em>, você só deveria
+ nomes dos pacotes com uma vÃrgula. <em>Entretanto</em>, você só deve
fazer isto se o bug pode ser corrigido por uma mudança em
- <em>qualquer</em> um dos pacotes. Se este não é o caso, você
- <a href="#clone">clona</a> o bug e o atribui para o outro pacote.
+ <em>qualquer</em> um dos pacotes. Se este não é o caso, você deve
+ <a href="#clone">clonar</a> o bug e o atribuir para o outro pacote.
</p>
</dd>
@@ -140,24 +143,24 @@
</p>
<p>
- Caso você forneça um <var>endereço-do-relator</var> o remetente será
+ Caso você forneça um <var>endereço-do-relator</var> o remetente original 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.
+ novo remetente original do relatório reaberto você pode usar a abreviação
+ <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
+ registrada como o relator original 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.
+ mesmo mudar o relator original. Para alterar o relator original 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>
<p>
@@ -174,6 +177,8 @@
<p>
Registra que #<var>número-do-bug</var> foi encontrado em determinada
<var>versão</var> do pacote ao qual ele está atribuÃdo.
+ A <var>versão</var> pode ser uma versão totalmente qualificada do
+ formulário <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
@@ -186,23 +191,26 @@
</p>
<p>
- Caso nenhuma <var>versão</var> seja fornecida, a lista de versões
+ Caso nenhuma <var>versão</var> seja fornecida, então a lista de versões
corrigidas para o bug é esvaziada. Isto é idêntico ao comportamento do
<code>reopen</code>.
+ A <var>versão</var> pode ser uma versão totalmente qualificada do
+ formulário <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
Este comando só fará com que um bug seja marcado como não concluÃdo
- se a versão não for especificada, ou se a <var>versão</var> sendo marcada
- como encontrada (found) é igual à <var>versão</var> que foi marcada como
- corrigida (fixed). (Se você tem certeza de que quer o bug marcado como
- não concluÃdo, use <code>reopen</code> em conjunto com <code>found</code>).
+ se nenhuma versão for especificada, ou se a <var>versão</var> sendo marcada
+ como encontrada ("found") é igual ou maior que a maior <var>versão</var>
+ que foi marcada como corrigida ("fixed"). (Se você tem certeza de que quer
+ o bug marcado como não concluÃdo, use <code>reopen</code> em conjunto
+ com <code>found</code>).
</p>
<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.
+ sofrer ambiguidade.
</p>
</dd>
@@ -213,6 +221,8 @@
<p>
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.
+ A <var>versão</var> pode ser uma versão totalmente qualificada do
+ formulário <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
@@ -230,13 +240,15 @@
<p>
Indica que o bug #<var>número-do-bug</var> foi corrigido na
<var>versão</var> informada do pacote para o qual está designado.
+ A <var>versão</var> pode ser uma versão totalmente qualificada do
+ formulário <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
Isto <em>não</em> faz com que o bug seja marcado como fechado,
- isto meramente adiciona outra versão na qual o bug foi corrigido.
- Use o endereço número-do-bug-done para fechar um bug e marcá-lo como
- corrigido numa versão particular.
+ isto apenas adiciona outra versão na qual o bug foi corrigido.
+ Use o endereço número-do-bug<code>-done</code> para fechar um bug e marcá-lo como
+ corrigido em uma versão particular.
</p>
</dd>
@@ -247,12 +259,18 @@
<p>
Remove o registro que o bug #<var>número-do-bug</var> foi corrigido
na <var>versão</var> informada.
+ A <var>versão</var> pode ser uma versão totalmente qualificada do
+ formulário <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
Este comando é equivalente ao <code>found</code> seguido pelo
- <code>notfound</code> (<q>found</q> remove o estado de fechado de
- uma versão particular e <q>notfound</q> remove o <q>found</q>).
+ <code>notfound</code> (o <q>found</q> remove o estado de corrigido de
+ uma versão particular e o <q>notfound</q> remove o <q>found</q>) com a
+ exceção que o bug não é reaberto se a versão encontrada é maior que
+ qualquer versão corrigida existente. O objetivo é corrigir erros no registro
+ de quando um bug foi encontrado; na maioria dos casos, o que você realmente
+ quer é <code>found</code>, e não <code>notfixed</code>.
</p>
</dd>
@@ -261,19 +279,19 @@
<var>endereço-do-relator</var> | <code>!</code></a></dt>
<dd>
<p>
- Altera o relator do #<var>número-do-bug</var> para
+ Altera o relator original do #<var>número-do-bug</var> para
<var>endereço-do-relator</var>.
</p>
<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 e-mail.
+ Se você deseja ser o novo remetente original do relatório você pode usar a
+ abreviação <code>!</code> ou especificar seu próprio endereço de e-mail.
</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.
+ Enquanto o comando <code>reopen</code> altera o relator original dos outros
+ bugs unidos (merged) com o que está sendo aberto novamente,
+ <code>submitter</code> não afeta bugs unidos.
</p>
</dd>
@@ -281,20 +299,36 @@
<dt><a name="forwarded"><code>forwarded</code> <var>número-do-bug</var>
<var>endereço</var></a></dt>
<dd>
- Marca que <var>número-do-bug</var> foi encaminhado para o mantenedor
+ <p>
+ Marca que <var>número-do-bug</var> foi encaminhado para o desenvolvedor
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.
+ existente, ou para registrar um novo endereço para um bug que não foi
+ anteriormente marcado como tendo sido encaminhado. <var>endereço</var>
+ geralmente deveria ser uma URI, ou possivelmente um endereço de e-mail.
+ Use uma URI onde for possÃvel para permitir que as ferramentas consultem
+ um sistema de rastreamento de bugs remoto (como bugzilla) para saber o
+ estado de um bug.
+ </p>
+
+ <p>
+ Exemplo de uso:
+ </p>
+
+ <pre>
+ forwarded 12345 http://bugz.illa.foo/cgi/54321
+ </pre>
</dd>
<dt><a name="notforwarded"><code>notforwarded</code>
<var>número-do-bug</var></a></dt>
<dd>
+ <p>
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
+ para qualquer desenvolvedor original. Caso o bug não tenha sido marcado como
tendo sido encaminhado então isso não causará nada.
+ </p>
</dd>
@@ -303,15 +337,10 @@
<dd>
<p>
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>
-
- <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.
+ o cabeçalho <code>Subject</code> (<code>Assunto</code>) da mensagem do
+ relatório original).
+ Também mudará os tÃtulos de todos os relatórios de bug em que este bugs
+ estejam unidos (merged).
</p>
</dd>
@@ -336,6 +365,77 @@
</p>
</dd>
+ <dt><a name="affects"><code>affects</code> <var>número-do-bug</var>
+ [ <code>+</code> | <code>-</code> | <code>=</code>
+ ] <var>pacote</var> [ <var>pacote</var> ... ]</a></dt>
+ <dd>
+ <p>
+ Indica que um bug afeta outro pacote. No caso onde o
+ <var>numero-do-bug</var> causa quebra no <var>pacote</var> apesar de o
+ bug está realmente presente no pacote para qual foi atribuÃdo, isto faz
+ com que o bug seja listado por padrão na lista de bugs do <var>pacote</var>.
+ Isto geralmente deve ser usado onde o bug é grave o suficiente para
+ causar vários relatos de usuários que está atribuÃdo ao pacote errado.
+ <code>=</code> define os efeitos na lista de pacotes fornecida,
+ e é a ação padrão se nenhum pacote foi fornecido;
+ <code>-</code> remove os pacotes fornecidos da lista de efeitos;
+ <code>+</code> adiciona os pacotes fornecidos na lista de efeitos, e é o
+ padrão se pacotes são fornecidos.
+ </p>
+ </dd>
+
+ <dt><a name="summary"><code>summary</code> <var>número-do-bug</var>
+ [<var>número-da-mensagem</var> | <var>texto do resumo</var>]</a></dt>
+ <dd>
+ <p>
+ Seleciona uma mensagem para usar como um resumo de um bug. O primeiro
+ parágrafo que não é um pseudo-cabeçalho/controle dessa mensagem é
+ analisado e definido como o resumo do bug, que é apresentado na parte
+ superior da página do relatório de bug. Isto é útil nos casos em que
+ o relatório original não descreve corretamente o problema ou o bug tem
+ muitas mensagens que tornam difÃcil identificar o problema real.
+ </p>
+ <p>
+ Se o <var>número-da-mensagem</var> não é dado, limpa o resumo.
+ <var>número-da-mensagem</var> é o número da mensagem como
+ listada na saÃda do script cgi do relatório do bug; se
+ um <var>número-da-mensagem</var> igual a 0 é dado, a mensagem atual
+ é utilizada (isto é, a mensagem que foi enviada para o
+ control@bugs.debian.org que contém o resumo do comando de controle).
+ </p>
+ <p>
+ Se <var>número-da-mensagem</var> não é numérico e não é uma cadeia de
+ caracteres vazia, presume-se que seja o texto para definir o resumo.
+ </p>
+ </dd>
+
+
+ <dt><a name="outlook"><code>outlook</code> <var>número-do-bug</var>
+ [<var>número-da-mensagem</var> | <var>texto da observação</var>]</a></dt>
+ <dd>
+ <p>
+ Selecione uma mensagem para usar como observação de correção de um bug (ou
+ a situação atual da correção de um bug). O primeiro parágrafo que não é um
+ pseudo-cabeçalho/controle dessa mensagem é analisado
+ e definido como a observação do bug que é que é apresentado na parte
+ superior da página do relatório de bug. Isso é útil para coordenar com
+ outras pessoas que estão trabalhando na correção do bug (por exemplo, em
+ uma festa de caça a bugs).
+ </p>
+ <p>
+ Se <var>número-da-mensagem</var> não é fornecido, limpa a observação.
+ <var>número-da-mensagem</var> é o número da mensagem como
+ listada na saÃda do script cgi do relatório do bug; se
+ um <var>número-da-mensagem</var> igual a 0 é dado, a mensagem atual
+ é utilizada (isto é, a mensagem que foi enviada para o
+ control@bugs.debian.org que contém a observação do comando de controle).
+ </p>
+ <p>
+ Se <var>número-da-mensagem</var> não é numérico e não é uma cadeia de
+ caracteres vazia, presume-se que seja o texto para definir a osbervação.
+ </p>
+ </dd>
+
<dt><a name="clone"><code>clone</code> <var>número-do-bug</var>
<var>NovoID</var> [ <var>Novos IDs</var> ... ]</a></dt>
@@ -345,7 +445,7 @@
útil quando um único relatório na verdade indica que múltiplos bugs
distintos ocorreram. <q><var>Novos IDs</var></q> 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
+ subsequentes para se referir aos novos bugs duplicados. Um novo relatório
é gerado para cada novo ID.
</p>
@@ -381,9 +481,9 @@
<var>número-do-bug</var> ...</a></dt>
<dd>
<p>
- 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
+ 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>
@@ -392,13 +492,14 @@
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.
+ (uma comparação exata de cadeia de caracteres é 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 pela unificação. As tags também não precisam ser as mesmas,
+ elas serão unidas.
</p>
<p>
@@ -409,7 +510,7 @@
</p>
<p>
- Unir relatórios faz com que uma nota apareça no log de cada relatório
+ Unir relatórios faz com que uma nota apareça no registro de cada relatório
de bug; nas páginas WWW isto faz com que sejam incluÃdos links para os
outros bugs.
</p>
@@ -425,12 +526,11 @@
<var>número-do-bug</var> ...</a></dt>
<dd>
<p>
- 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
- (<q>merge</q>) significa.
+ Une forçadamente dois ou mais relatórios de bug. As configuração do primeiro
+ bug listado que devem ser iguais em uma 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>
<p>
@@ -453,7 +553,7 @@
<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
+ relatório em um dos novos grupos separadamente e então uni-los na forma
do novo grupo requerido.
</p>
@@ -466,18 +566,19 @@
</dd>
- <dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>número-do-bug</var>
- [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var>
- [ <var>tag</var> ... ]</a></dt>
+ <dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>número-do-bug</var> [ <code>+</code> |
+ <code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var>
+ ... ] [ <code>+</code> | <code>-</code>
+ | <code>=</code> <var>tag</var> ... ] ]</a></dt>
<dd>
<p>
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.
+ como <code>+</code> significa adicionar cada <var>tag</var> seguinte,
+ <code>-</code> significa remover cada <var>tag</var> seguinte,
+ e <code>=</code> significa marcar as tags seguintes para a lista fornecida.
+ Intervir com <code>+</code>, <code>-</code>, ou <code>=</code> muda a ação
+ das tags seguintes. A ação padrão é adicionar.
</p>
<p>
@@ -516,16 +617,20 @@
<dt><a name="block"><code>block</code> <var>número-do-bug</var>
<code>by</code> <var>bug</var> ...</a></dt>
<dd>
+ <p>
Note que a correção para o primeiro bug está bloqueada pelos outros bugs
listados.
+ </p>
</dd>
<dt><a name="unblock"><code>unblock</code> <var>número-do-bug</var>
<code>by</code> <var>bug</var> ...</a></dt>
<dd>
+ <p>
Note que a correção para o primeiro bug deixou de estar bloqueada pelos
outros bugs listados.
+ </p>
</dd>
<dt><a name="close"><code>close</code> <var>número-do-bug</var>
@@ -536,15 +641,15 @@
</p>
<p>
- Uma notificação é enviada para o usuário que reportou o bug, mas (ao
+ Uma notificação é enviada para o usuário que relatou 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>.
+ portanto obsoleto. Veja as informações para desenvolvedores sobre
+ <a href="Developer#closing">como fechar um bug corretamente</a>.
</p>
<p>
@@ -589,8 +694,8 @@
<var>endereço</var> | <code>!</code></a></dt>
<dd>
<p>
- 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.
+ Define <var>endereço</var> como dono do #<var>número-do-bug</var>.
+ O dono de um bug reivindica a responsabilidade de corrigÃ-lo.
Isto é útil para dividir o trabalho em
pacotes que possuem equipes de mantenedores.
</p>
@@ -604,35 +709,48 @@
<dt><a name="noowner"><code>noowner</code> <var>número-do-bug</var></a></dt>
<dd>
+ <p>
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
+ bug não tiver algum dono registrado, esta opção não fará nada.
+ </p>
</dd>
<dt><a name="archive"><code>archive</code> <var>número-do-bug</var></a></dt>
<dd>
- Arquiva um bug que foi arquivado em algum ponto no passado mas não
+ <p>
+ Arquiva um bug que foi arquivado em algum ponto no passado mas que não
está atualmente arquivado se o bug preenche os requisitos para
arquivamento, ignorando o tempo.
+ </p>
</dd>
<dt><a name="unarchive"><code>unarchive</code>
<var>número-do-bug</var></a></dt>
<dd>
- Desarquiva um bug que foi previamente arquivado. Desarquivar deveria ser
- geralmente acompanhado com reopen e found/fixed conforme for apropriado.
- Bugs que foram desarquivados podem ser arquivados usando archive assumindo
- que os requisitos de arquivamentos não baseados em tempo sejam atendidos.
+ <p>
+ Desarquiva um bug que foi previamente arquivado. Desarquivar deve ser
+ geralmente acompanhado com <code>reopen</code> e <code>found/fixed</code>
+ conforme for apropriado. Bugs que foram desarquivados podem ser arquivados
+ usando <code>archive</code> assumindo
+ que os requisitos de arquivamento não baseados em tempo sejam atendidos.
+ Você não deve desarquivar para fazer mudanças triviais em um bug arquivado,
+ como por exemplo mudar o relator original; o propósito primário é permitir
+ a reabertura de bugs que foram arquivados sem a intervenção dos administradores
+ do BTS.
+ </p>
</dd>
<dt><a name="comment"><code>#</code>...</a></dt>
<dd>
+ <p>
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.
+ linha. O texto dos comentários será incluÃdo na mensagem de confirmação
+ enviada para o remetente e para os mantenedores afetados, portanto você pode
+ utilizar isto para documentar as razões de seus comandos.
+ </p>
</dd>
@@ -647,11 +765,13 @@
<!-- <dt><code>kthxbye</code></dt> -->
<!-- See... I documented it! -->
<dd>
- Numa linha sozinho, em qualquer caso, possivelmente seguido por um
+ <p>
+ Em uma linha sozinha, em qualquer caso, possivelmente seguido por um
espaço em branco, 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
+ processar a mensagem; no restante da mensagem é possÃvel incluir explicações,
+ assinaturas ou qualquer outra coisa, nada disso será detectado
pelo servidor de controle.
+ </p>
</dd>
</dl>