[RFR] wml://www.debian.org/Bugs/server-control.wml
Segue o arquivo para revisão. Finalmente o último dos desatualizados, acredito!
Sugiro pedir ITR, pois o arquivo é grande.
Abraços,
Thiago Pezzo (Tico)
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, June 23, 2020 7:30 PM, Thiago Pezzo <pezzo@protonmail.com> wrote:
> Vou atualizar este arquivo.
>
> Abraços,
> Thiago Pezzo (Tico)
>
> Sent with ProtonMail Secure Email.
diff --git a/portuguese/Bugs/server-control.wml b/portuguese/Bugs/server-control.wml
index df26a7c8c34..8872fbee76c 100644
--- a/portuguese/Bugs/server-control.wml
+++ b/portuguese/Bugs/server-control.wml
@@ -1,20 +1,20 @@
#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="af6db568fa508f5c59388f1ddb1a44165e40a276"
+#use wml::debian::translation-check translation="d11193e66dd678156a1f8aa4c02b5ec7ae7eb116"
<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>
-permite que os relatórios de bug sejam manipulados de várias formas.
+<code>control@bugs.debian.org</code> permite que os relatórios de bug sejam
+manipulados de várias formas.
</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
+programa. Os dois endereços são separados somente para evitar que usuários(as)
cometam erros e causem problemas quando tentam meramente requisitar
informação.
</p>
@@ -22,7 +22,7 @@ informação.
<p>
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(s) pacote(s) para os quais os bugs alterados
+é enviado para o(a) mantenedor(a) do(s) pacote(s) cujos bugs alterados
estão designados. Adicionalmente, a mensagem para o servidor e as
alterações resultantes são registradas no relatório e portanto
disponibilizadas nas páginas WWW.
@@ -32,10 +32,10 @@ disponibilizadas nas páginas WWW.
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 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.
+<code>bug-log-mailserver.txt</code>, ou enviando
+<code>help</code> para qualquer servidor de e-mail, para detalhes básicos de
+operações dos servidores de e-mail e para os comandos básicos disponÃveis ao
+enviar mensagens para qualquer um dos endereços.
</p>
<p>
@@ -52,7 +52,7 @@ por e-mail usando o comando <code>refcard</code>.
<td align="center">Geral</td>
<td align="center">Versionamento</td>
<td align="center">Duplicados</td>
- <td align="center">Misc.</td>
+ <td align="center">Outros</td>
</tr>
<tr>
<!-- Geral -->
@@ -85,7 +85,7 @@ por e-mail usando o comando <code>refcard</code>.
<li><a href="#clone">clone</a></li>
</ul>
</td>
- <!-- Misc. -->
+ <!-- Outros -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#thanks">thanks</a></li>
@@ -108,20 +108,20 @@ por e-mail usando o comando <code>refcard</code>.
<dd>
<p>
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
+ Pode ser usado para definir o pacote caso o(a) usuário(a) tenha esquecido o
+ pseudocabeç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>
<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ó deve
- fazer isto se o bug pode ser corrigido por uma mudança em
+ fazê-lo se o bug pode ser corrigido por uma mudança em
<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>
@@ -129,7 +129,7 @@ por e-mail usando o comando <code>refcard</code>.
<dt><a name="reopen"><code>reopen</code> <var>número-do-bug</var>
- [ <var>endereço-do-relator</var> | <code>=</code> | <code>!</code> ]</a></dt>
+ [ <var>endereço-do(a)-relator(a)</var> | <code>=</code> | <code>!</code> ]</a></dt>
<dd>
<p>
Reabre #<var>número-do-bug</var> caso o mesmo esteja fechado.
@@ -137,34 +137,35 @@ por e-mail usando o comando <code>refcard</code>.
<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,
+ originalmente o relatório de bug continua como o(a) 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 original será
- definido como o endereço que você fornecer. Caso você deseje se tornar o
- 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.
+ Caso você forneça um <var>endereço-do(a)-relator(a)</var> o(a) remetente
+ original será definido(a) como o endereço que você fornecer. Caso você
+ deseje tornar-se o(a) novo(a) 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 ideia avisar à pessoa que está prestes a ser
- 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.
+ registrada como o(a) relator(a) 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 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.
+ mesmo mudar o(a) relator(a) original. Para alterar o(a) relator(a) original
+ de um relatório de bug aberto, use o comando <code>submitter</code>; note
+ que isto notificará o(a) relator(a) original sobre esta mudança.
</p>
<p>
- Se o bug foi registrado como fechado em determinada versão de um pacote
+ 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>.
</p>
@@ -186,7 +187,7 @@ por e-mail usando o comando <code>refcard</code>.
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 foi encontrado ("found") mais recentemente do que havia
+ ou quando o bug foi encontrado (found) mais recentemente do que havia
sido corrigido.
</p>
@@ -201,8 +202,8 @@ por e-mail usando o comando <code>refcard</code>.
<p>
Este comando só fará com que um bug seja marcado como não concluÃdo
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
+ 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>
@@ -276,21 +277,22 @@ por e-mail usando o comando <code>refcard</code>.
<dt><a name="submitter"><code>submitter</code> <var>número-do-bug</var>
- <var>endereço-do-relator</var> | <code>!</code></a></dt>
+ <var>endereço-do(a)-relator(a)</var> | <code>!</code></a></dt>
<dd>
<p>
- Altera o relator original do #<var>número-do-bug</var> para
- <var>endereço-do-relator</var>.
+ Altera o(a) relator(a) original do #<var>número-do-bug</var> para
+ <var>endereço-do(a)-relator(a)</var>.
</p>
<p>
- 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.
+ Se você deseja ser o(a) novo(a) 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 original dos outros
- bugs unidos (merged) com o que está sendo aberto novamente,
+ Enquanto o comando <code>reopen</code> altera o(a) relator(a) original dos
+ outros bugs unidos (merged) com o que está sendo aberto novamente,
<code>submitter</code> não afeta bugs unidos.
</p>
</dd>
@@ -300,11 +302,11 @@ por e-mail usando o comando <code>refcard</code>.
<var>endereço</var></a></dt>
<dd>
<p>
- Marca que <var>número-do-bug</var> foi encaminhado para o desenvolvedor
+ Marca que <var>número-do-bug</var> foi encaminhado para o(a) desenvolvedor(a)
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 foi
- anteriormente marcado como tendo sido encaminhado. <var>endereço</var>
+ anteriormente marcado como tendo sido encaminhado. O <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
@@ -325,9 +327,9 @@ por e-mail usando o comando <code>refcard</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 desenvolvedor 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 o <var>número-do-bug</var> foi encaminhado
+ para qualquer desenvolvedor(a) original. Caso o bug não tenha sido marcado
+ como tendo sido encaminhado então isso não causará nada.
</p>
</dd>
@@ -336,7 +338,7 @@ por e-mail usando o comando <code>refcard</code>.
<var>novo-tÃtulo</var></a></dt>
<dd>
<p>
- Muda o tÃtulo de um relatório de bug para o especificado (o padrão é
+ Muda o tÃtulo de um relatório de bug (o padrão é
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
@@ -350,8 +352,8 @@ por e-mail usando o comando <code>refcard</code>.
<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.
+ </var> para <var>severidade</var>. Nenhuma notificação é enviada para o(a)
+ usuário(a) que reportou o bug.
</p>
<p>
@@ -359,9 +361,9 @@ por e-mail usando o comando <code>refcard</code>.
</p>
<p>
- Para <a href="Developer#severities">os significados das severidades</a> por
- favor consulte a documentação geral dos desenvolvedores sobre o sistema de
- bugs.
+ Para <a href="Developer#severities">os significados das severidades</a>, por
+ favor, consulte a documentação geral dos(as) desenvolvedores(as) sobre o
+ sistema de bugs.
</p>
</dd>
@@ -371,14 +373,14 @@ por e-mail usando o comando <code>refcard</code>.
<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
+ <var>numero-do-bug</var> causa quebra no <var>pacote</var> apesar de que 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;
+ Isto geralmente deve ser usado quando o bug é grave o suficiente para
+ causar vários relatos de usuários(as) que está atribuÃdo ao pacote errado.
+ O <code>=</code> define os efeitos na lista de pacotes fornecida,
+ e é a ação padrão se nenhum pacote foi fornecido; o
+ <code>-</code> remove os pacotes fornecidos da lista de efeitos; o
<code>+</code> adiciona os pacotes fornecidos na lista de efeitos, e é o
padrão se pacotes são fornecidos.
</p>
@@ -389,14 +391,14 @@ por e-mail usando o comando <code>refcard</code>.
<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 é
+ parágrafo que não é um pseudocabeç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.
+ Se o <var>número-da-mensagem</var> não é dado, limpa o resumo. 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
@@ -416,7 +418,7 @@ por e-mail usando o comando <code>refcard</code>.
<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
+ pseudocabeç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
@@ -424,7 +426,7 @@ por e-mail usando o comando <code>refcard</code>.
</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
+ 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
@@ -488,9 +490,9 @@ por e-mail usando o comando <code>refcard</code>.
</p>
<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
+ 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(a) autor(a) original ou todos não
marcados como encaminhados, todos atribuÃdos para o(s) mesmo(s) pacote(s)
(uma comparação exata de cadeia de caracteres é feita no pacote para o qual
o bug está atribuÃdo), e todos da mesma severidade.
@@ -527,15 +529,15 @@ por e-mail usando o comando <code>refcard</code>.
<dd>
<p>
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.
+ bug listado, que deve ser igual à configuração de outros bugs numa união
+ normal, agora é atribuÃda aos bugs listados em seguida. Para evitar que
+ erros de digitação unam bugs incorretamente, os bugs precisam estar no mesmo
+ pacote. Veja o texto acima para uma descrição do que união significa.
</p>
<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
+ responsável por notificar os(as) relatores(as) dos bugs com uma mensagem de
fechamento apropriada se você fizer isto.
</p>
</dd>
@@ -546,15 +548,15 @@ por e-mail usando o comando <code>refcard</code>.
<p>
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;
+ 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>
<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
+ dois grupos de relatórios unidos, você deve desconectar cada
relatório em um dos novos grupos separadamente e então uni-los na forma
- do novo grupo requerido.
+ do novo grupo desejado.
</p>
<p>
@@ -573,7 +575,7 @@ por e-mail usando o comando <code>refcard</code>.
<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
+ notificação é enviada para o(a) usuário(a) que relatou o bug. Definir a ação
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.
@@ -600,6 +602,9 @@ por e-mail usando o comando <code>refcard</code>.
\# define as tags exatamente como 'moreinfo' e 'unreproducible'
tags 123456 = moreinfo unreproducible
+
+ \# remove a tag 'moreinfo' e adiciona a tag 'patch'
+ tags 123456 - moreinfo + patch
</pre>
<p>
@@ -607,8 +612,8 @@ por e-mail usando o comando <code>refcard</code>.
</p>
<p>
- Para <a href="Developer#tags">os significados das tags</a> por favor
- consulte a documentação geral dos desenvolvedores sobre o sistema de
+ Para <a href="Developer#tags">os significados das tags</a>, por favor,
+ consulte a documentação geral dos(as) desenvolvedores(as) sobre o sistema de
bugs.
</p>
</dd>
@@ -617,22 +622,19 @@ por e-mail usando o comando <code>refcard</code>.
<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>
[ <var>versão-corrigida</var> ] (obsoleto)</a></dt>
<dd>
@@ -641,14 +643,15 @@ por e-mail usando o comando <code>refcard</code>.
</p>
<p>
- Uma notificação é enviada para o usuário que relatou o bug, mas (ao
+ Uma notificação é enviada para o(a) usuário(a) 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 obsoleto. Veja as informações para desenvolvedores sobre
+ O(A) mantenedor(a) que fecha o relatório precisa certificar-se,
+ provavelmente enviando uma mensagem separada, que o(a) usuário(a) que
+ reportou o bug fique sabendo a razão pela qual o bug está sendo fechado. O
+ uso deste comando é, portanto, obsoleto. Veja as informações para
+ desenvolvedores(as) sobre
<a href="Developer#closing">como fechar um bug corretamente</a>.
</p>
@@ -667,7 +670,7 @@ por e-mail usando o comando <code>refcard</code>.
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
+ serão aplicados em todos os bugs. Você é encorajado(a) 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>
@@ -694,14 +697,14 @@ por e-mail usando o comando <code>refcard</code>.
<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 reivindica a responsabilidade de corrigi-lo.
+ Define <var>endereço</var> como dono(a) do #<var>número-do-bug</var>.
+ O(A) dono(a) de um bug reivindica a responsabilidade de corrigi-lo.
Isto é útil para dividir o trabalho em
- pacotes que possuem equipes de mantenedores.
+ pacotes que possuem equipes de mantenedores(as).
</p>
<p>
- Se você quer se tornar o dono de um bug, você pode usar a abreviação
+ Se você quer se tornar o(a) dono(a) de um bug, você pode usar a abreviação
<code>!</code> ou especificar seu endereço de e-mail.
</p>
</dd>
@@ -709,48 +712,40 @@ por e-mail usando o comando <code>refcard</code>.
<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.
- </p>
+ Esquece qualquer dono(a) que o bug tenha além do(a) mantenedor(a) usual. Se
+ o bug não tiver algum(a) dono(a) registrado(a), esta opção não fará nada.
</dd>
<dt><a name="archive"><code>archive</code> <var>número-do-bug</var></a></dt>
<dd>
- <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>
+ Arquiva um bug que foi arquivado em algum ponto no passado, mas que não
+ está atualmente arquivado, se o bug preencher os requisitos para
+ arquivamento, e ignorando o tempo.
</dd>
<dt><a name="unarchive"><code>unarchive</code>
<var>número-do-bug</var></a></dt>
<dd>
- <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
+ 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>
+ como por exemplo mudar o(a) relator(a) original; o propósito primário é
+ permitir a reabertura de bugs que foram arquivados sem a intervenção dos(as)
+ administradores(as) do BTS.
</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 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>
+ enviada para o(a) remetente e para os(as) mantenedores(as) afetados(as),
+ portanto você pode utilizar isto para documentar as razões de seus comandos.
</dd>
@@ -765,13 +760,11 @@ por e-mail usando o comando <code>refcard</code>.
<!-- <dt><code>kthxbye</code></dt> -->
<!-- See... I documented it! -->
<dd>
- <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; 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>
Reply to: