[RFR2] wml://Bugs/server-control.wml
Gracias por tan exhaustiva revisión. He corregido todos los errores
mencionados, creo que de tanto ver Starwars se me ha pegado la voz
pasiva de Yoda :D .
El día 7 de mayo de 2015, 12:39, Laura Arjona Reina
<larjona@larjona.net> escribió:
> Hola Diddier
>
> ¡Lo primero, enhorabuena por esta traducción, que es bastante dura!
>
> El 07/05/15 a las 07:16, Diddier Hilarion escribió:
>> ---------- Mensaje reenviado ----------
>> De: Diddier Hilarion <diddierhilarion@gmail.com>
>> Fecha: 7 de mayo de 2015, 0:11
>> Asunto: [rfr] wml://Bugs/server-control.wml
>> Para: Debian-es-l10n <debian-l10n-spanish@lists.debian.org>
>>
>>
>> Hola a todos.
>>
>> En la traducción del fichero he usado panorama para outlook aunque
>> también me parecería adecuado perspectiva, ¿qué opinan? ¿cual es la
>> más adecuada?.
>>
>
> Yo veo bien panorama.
>
> Te envío mis aportaciones:
>
> L3: #use wml::debian::translation-check translation="1.89" >> actualiza
> el nº de versión a 1.102, y si quieres, ponte de mantenedor :)
>
> L68 y siguientes: En las listas <li> al principio, donde pones la
> etiqueta en inglés y la traducción entre paréntesis, creo que se ve más
> claro si dejas un espacio entre la palabra en inglés y el paréntesis,
> por ejemplo:
>
> L68 <li><a href="#reassign">reasign (reasignar)</a></li>
>
> L390 y siguientes: los signos + - = van entre etiquetas: <code>=</code>
>
> L392: remueve >> quita
>
> L404 y siguientes: no entiendo muy bien la frase:
> Se trata el primer párrafo que no forme parte de las pseudo-cabeceras o
> no sea una orden de control se utiliza como resumen del fallo.
>
> Creo que falta una "y":
>
> Se trata el primer párrafo que no forme parte de las pseudo-cabeceras o
> no sea una orden de control y se utiliza como resumen del fallo.
>
> L413: Se borra el resumen si no se proporciona <var>número_de_mensaje</var>.
>
> creo que se entiende mejor al revés:
>
> Si no se proporciona <var>número_de_mensaje</var>, se borra el resumen.
>
> L415: en la salida del programa CGI bugreport;
>
> Creo que se refiere al informe del bug como se ve en la web, así que no
> traduciría script como programa, yo lo dejaría como "script".
>
> L416-417 "<var>numero_de_mensaje</var> es 0, el mensaje actual
> es usado(el" >>> "<var>número_de_mensaje</var> es 0, se usa
> el mensaje actual (el"
>
> L421 "el texto como el texto a usar como <var>texto_de_resumen</var>.">>
> "que es el texto a usar como resumen."
>
> L425: [<var>número_de_mensaje</var> | <var></var>]</a></dt> >>
> creo que falta "texto_de_panorama" entre las últimas etiquetas "var".
>
> L436: "reunión de caza de fallos" > francamente, no sé cómo traducir Bug
> Squashing Party, aunque tendería a enfocarlo en la corrección, más que
> en la "caza" (que parece "descubrir fallos"). ¿"fiesta/reunión de
> corrección de fallos"?
>
> L439: Se borra el outlook, si no se indica un
> <var>número_de_mensaje</var>. >> Si no se indica un
> <var>número_de_mensaje</var>, se borra el panorama.
>
> L441: programa CGI > lo que decidas sobre la sugerencia anterior, debe
> ir igual aquí también.
> L442: el mensaje actual es usado >> se usa el mensaje actual
>
> L448: asume el texto como el texto a usar como el panorama. > asume que
> es el texto a usar como panorama.
>
>
> L572: Añade a las etiquetas del informe de fallo #<var>número de
> fallo</var> >> <var>número_de_fallo</var>
>
> L719: cambiaría "requerimientos" por "requisitos"
>
> Un saludo
> --
> Laura Arjona
> https://wiki.debian.org/LauraArjona
>
--
Diddier A Hilarion B.
#use wml::debian::template title="Debian BTS — control del servidor" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="1.102" maintainer="Diddier Hilarion"
# Note to translators: please, do fix the command name:
# they must not be translated -- taffit, 2012-11-17
<h1>Información para desarrolladores sobre cómo manipular fallos
utilizando la interfaz de correo electrónico.</h1>
# Nota para los traductores:
# Se puede utilizar 'fallo' o 'errata' en el texto, pero intentar no
# utilizar 'arreglo' (véanse las notas de traducción)
<p>
Sólo <code>request@bugs.debian.org</code> permite la <a
href="server-request">obtención de datos y documentación de fallos por correo
electrónico</a>, <code>control@bugs.debian.org</code> permite manipular
informes de fallos de varias maneras.
</p>
<p>
El servidor de control funciona de la misma manera que el de peticiones
(«request»); en realidad, son el mismo programa. Sencillamente, las dos
direcciones están separadas para evitar errores de los usuarios y que puedan
causar problemas cuando sólo quieran obtener información.
</p>
<p>
Se envía una notificación al mantenedor del paquete o paquetes al que están
asignados los fallos, ya que las órdenes específicas al servidor de control
cambian el estado de un fallo. Además, se registran el mensaje enviado al
servidor y los cambios realizados y están disponibles en las páginas web.
</p>
<p>
Si desea obtener detalles de operación básica de los servidores de correo y las
órdenes comunes, lea por favor la página <a
href="server-request#introduction">Cómo pedir informes de fallo por correo</a>
disponible en Internet, en el fichero <code>bug-log-mailserver.txt</code>, o
envíe <code>help</code> a cualquiera de los servidores de correo.
</p>
<p>
La <A href="server-refcard">tarjeta de referencia</A> de los servidores de
correo está disponible mediante WWW, en <code>bug-mailserver-refcard.txt</code>
o mediante correo electrónico usando la orden <code>refcard</code>.
</p>
<h1>Órdenes disponibles en el servidor de correo «control»</h1>
<table style="margin-left:auto;margin-right:auto">
<tr>
<td align="center">General</td>
<td align="center">Versionado</td>
<td align="center">Duplicados</td>
<td align="center">Varios</td>
</tr>
<tr>
<!-- General -->
# TODO:
# Habría que pensar en utilizar los nombres reales de las órdenes (dado
# que se están documentando) con la traducción de la orden entre paréntesis.
# No creo que tal y como esté esté claro (jfs)
<td valign="top">
<ul class="nodecoration">
<li><a href="#reassign">reasign (reasignar)</a></li>
<li><a href="#severity">severity (gravedad)</a></li>
<li><a href="#tag">tags (etiquetas)</a></li>
<li><a href="#retitle">retitle (retitulación)</a></li>
<li><a href="#submitter">submitter (remitente)</a></li>
<li><a href="#affects">affects (afecta)</a></li>
<li><a href="#summary">summary (resumen)</a></li>
<li><a href="#outlook">outlook (panorama)</a></li>
</ul>
</td>
<!-- Versioning -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#found">found (encontrado)</a> | <a href="#notfound">notfound(no encontrado)</a></li>
<li><a href="#fixed">fixed (arreglado)</a> | <a href="#notfixed">notfixed(no arreglado)</a></li>
<li><a href="#reopen">reopen (reabierto)</a></li>
<!-- <dt>(close)</dt> Deprecated -->
</ul>
</td>
<!-- Duplicates -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#merge">merge (fusionar)</a> | <a href="#unmerge">unmerge(desunir)</a></li>
<li><a href="#forcemerge">forcemerge (fusión forzada)</a></li>
<li><a href="#clone">clone (clonar)</a></li>
</ul>
</td>
<!-- Misc. -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#thanks">thanks (gracias)</a></li>
<li><a href="#comment">#</a></li>
<li><a href="#forwarded">forwarded (reenvío)</a> | <a href="#notforwarded">notforwarded(sin reenvío)</a></li>
<li><a href="#owner">owner (propietario)</a> | <a href="#noowner">noowner(sin propietario)</a></li>
<li><a href="#block">block (bloqueo)</a> | <a href="#unblock">unblock(desbloqueo)</a></li>
<li><a href="#archive">archive (archivar)</a> | <a href="#unarchive">unarchive(sacar del archivo)</a></li>
<li><a href="server-request#user">user (usuario)</a> |
<a href="server-request#usertag">usertag (etiqueta de usuario)</a> |
<a href="server-request#usercategory">usercategory (categoría de usuario</a></li>
</ul>
</td>
</tr>
</table>
<dl>
<dt><a name="reassign"><code>reassign</code> <var>número_de_fallo</var>
<var>paquete</var> [ <var>versión</var> ]</a></dt>
<dd>
<p>
Registra que el fallo #<var>número_de_fallo</var> pertenece al
<var>paquete</var>. Puede usarse para establecer el paquete si el usuario
lo olvidó en la pseudo-cabecera, o para cambiar una asignación previa. No se
enviarán notificaciones a nadie (excepto la información normal en la
transcripción del proceso).
</p>
<p>
Si proporciona una <var>versión</var>, el sistema de seguimiento de fallos
notará que el fallo afecta a esa versión del nuevo paquete asignado.
</p>
<p>
Puede asignar un fallo a dos paquetes a la vez separando los nombres de los
paquetes con una coma. <em>Sin embargo</em>, sólo debería hacerlo si el fallo
se puede arreglar mediante un cambio en <em>cualquiera</em> de ellos. Si no es
este el caso, debería <a href="#clone">clonar</a> el fallo y reasignar el clon
al otro paquete.
</p>
</dd>
<dt><a name="reopen"><code>reopen</code> <var>número_de_fallo</var>
[ <var>dirección_del_originador</var> | <code>=</code> | <code>!</code>
]</a></dt>
<dd>
<p>
Reabre el #<var>número_de_fallo</var> en caso de que estuviera cerrado.
</p>
<p>
Por omisión, o si específica <code>=</code>, se mantendrá el informador
original del fallo tal cual, de manera que obtendrá una notificación cuando
vuelva a ser cerrado.
</p>
<p>
Si proporciona una <var>dirección del descubridor</var> entonces se
cambiará la dirección de correo del informador del fallo por esta otra. Si
desea ser el nuevo informador del informe reabierto, puede usar el atajo
<code>!</code> o especificar su propia dirección de correo.
</p>
<p>
Suele ser buena idea decirle a la persona que va a ser registrada como
descubridor que está usted reabriendo el informe, de manera que sepa que
recibirá una notificación cuando vuelva a ser cerrado.
</p>
<p>
Si el fallo no está cerrado, reabrirlo no hará nada, siquiera cambiar quién
envió el fallo. Para cambiar esto de un informe de fallo abierto, use la
orden <code>submitter</code>; tenga en cuenta de que esto informará a la persona
que envió el fallo en primer lugar del cambio.
</p>
<p>
Si el fallo se registró como que había sido cerrado en una versión
particular de un paquete pero reapareció en una versión posterior, es mejor
usar la orden <code>found</code> en su lugar.
</p>
</dd>
<dt><a name="found"><code>found</code> <var>número_de_fallo</var> [
<var>versión</var> ]</a></dt>
<dd>
<p>
Registra que #<var>número_de_fallo</var> se ha encontrado en la versión dada
en <var>versión</var> del paquete al que se asignó.
<var>versión</var> puede ser una versión totalmente
cualificada, con el formato <var>nombre_paquete_fuente/versión</var>.
</p>
<p>
El sistema de seguimiento de fallos utiliza esta información, junto con los
registros de las versiones arregladas al cerrar los fallos, para mostrar
listas de fallos abiertos en varias versiones de cada paquete. Considera
que un fallo está abierto cuando no tiene versión arreglada, o cuando se ha
encontrado más recientemente de lo que ha sido arreglado.
</p>
<p>
Si no se da una <var>versión</var>, entonces la lista de versiones
arregladas para el fallo se limpia. Este comportamiento es idéntico al de
<code>reopen</code>.
<var>versión</var> puede ser una versión totalmente
cualificada, con el formato <var>nombre_paquete_fuente/versión</var>.
</p>
<p>
Esta orden sólo hará que un fallo como no arreglado si no se especifica una
versión, o si la <var>versión</var> que está marcada es igual o mayor a la
<var>versión</var> más alta marcada como arreglada. Si está seguro de que
quiere marcar el fallo como no arreglado, use <code>reopen</code> junto a
<code>found</code>.
</p>
<p>
Esta orden se introdujo, prefiriéndose a <code>reopen</code>, porque era
difícil añadir una <var>versión</var> a esa sintaxis de órdenes sin sufrir
ambigüedad.
</p>
</dd>
<dt><a name="notfound"><code>notfound</code> <var>número_de_fallo</var>
<var>versión</var></a></dt>
<dd>
<p>
Borra el registro de #<var>número_de_fallo</var> que se encontró en la
<var>versión</var> dada del paquete al que está asignado.
<var>versión</var> puede ser una versión totalmente
cualificada, con el formato <var>nombre_paquete_fuente/versión</var>.
</p>
<p>
Esto difiere de cerrar el fallo en esa versión en que no se lista como
arreglado en versión alguna; no se conocerá información sobre esa versión.
Se pretende que sea para guardar en el registro cuándo se encontró un
fallo.
</p>
</dd>
<dt><a name="fixed"><code>fixed</code> <var>número_de_fallo</var>
<var>versión</var></a></dt>
<dd>
<p>
Indica que el fallo #<var>número_de_fallo</var> se arregló en la
<var>versión</var> dada del paquete al que está asignado.
</p>
<p>
Esto <em>no</em> hace que se marque el fallo como cerrado, simplemente
añade otra versión en la que el fallo está arreglado. use la dirección
número_de_fallo-done para cerrar un fallo y marcarlo como arreglado en una
versión particular.
</p>
</dd>
<dt><a name="notfixed"><code>notfixed</code> <var>número_de_fallo</var>
<var>versión</var></a></dt>
<dd>
<p>
Elimina el registro de que el fallo #<var>número_de_fallo</var> está
arreglado en la versión <var>versión</var>.
<var>versión</var> puede ser una versión totalmente
cualificada, con el formato <var>nombre_paquete_fuente/versión</var>.
</p>
<p>
Esta orden es equivalente a <code>found</code> seguida de
<code>notfound</code>. La orden <code>found</code> elimina el fallo en
una versión particular, y el <code>notfound</code> elimina el
<code>found</code>. La diferencia es que no se reabre el fallo si
la versión de <code>found</code> es mayor que cualquiera de las versiones
de <code>fixed</code>. Está pensando para arreglar errores en la
indicación de cuándo se arregló una errata. En la mayoría de los
casos querrá utilizar <code>found</code>, no <code>notfixed</code>.
</p>
</dd>
<dt><a name="submitter"><code>submitter</code> <var>número_de_fallo</var>
<var>dirección_del_originador</var> | <code>!</code></a></dt>
<dd>
<p>
Cambia el informador del fallo #<var>número</var> a <var>dirección del
informador</var>.
</p>
<p>
Si desea ser la nueva persona origen del fallo, puede usar la abreviatura
<code>!</code> o especificar su propia dirección de correo.
</p>
<p>
Mientras la orden <code>reopen</code> cambia también el origen de otros
fallos fusionados con el que se está reabriendo, la orden
<code>submitter</code> no afecta a los fallos fusionados.
</p>
</dd>
<dt><a name="forwarded"><code>forwarded</code> <var>número_de_fallo</var>
<var>dirección</var></a></dt>
<dd>
<p>
Indica que <var>número_de_fallo</var> ha sido informado al mantenedor oficial
en <var>dirección</var>. En sí, esto no reenvía el informe. Se puede usar
para cambiar una dirección <I>forwarded-to</I> incorrecta, o para registrar
una nueva para un fallo del que no se había indicado que fue reenviado.
El valor de <var>dirección</var> debería ser habitualmente una URI
o una dirección de correo. Utilice URIs siempre que sea posible para
permitir el uso de herramientas que permiten consultar los sistemas
de seguimiento de erratas (como bugzilla) para conocer el estado de
un fallo.
</p>
<p>
Ejemplo de uso:
</p>
<pre>
forwarded 12345 http://bugz.illa.foo/cgi/54321
</pre>
</dd>
<dt><a name="notforwarded"><code>notforwarded</code>
<var>número_de_fallo</var></a></dt>
<dd>
<p>
Elimina cualquier registro de que <var>número_de_fallo</var> haya sido
reenviado a algún mantenedor oficial. Si este fallo no tenía registros que
indicasen tal reenvío, entonces no sucederá nada.
</p>
</dd>
<dt><a name="retitle"><code>retitle</code> <var>número_de_fallo</var> <var>nuevo título</var></a></dt>
<dd>
<p>
Cambia el título del informe de fallo por el que se específica (por omisión
se toma la cabecera de correo <code>Asunto</code>) del mensaje original).
</p>
<p>
También cambiará el título de todos aquellos fallos con los que
<var>número_de_fallo</var> esté fusionado (<code>merged</code>).
</p>
</dd>
<dt><a name="severity"><code>severity</code> <var>número_de_fallo</var>
<var>gravedad</var></a></dt>
<dd>
<p>
Establece el nivel de gravedad del informe de fallo
\#<var>número_de_fallo</var>. No se enviará notificación alguna al usuario
que informó de él.
</p>
<p>
Las posibles gravedades son <bts_severities>.
</p>
<p>
Si desea saber <A href="Developer#severities">sus significados</A>, sírvase
consultar la documentación general para desarrolladores sobre el sistema de
fallos.
</p>
</dd>
<dt><a name="affects"><code>affects</code> <var>número_de_fallo</var>
[ <code>+</code> | <code>-</code> | <code>=</code>
] <var>paquete</var> [ <var>paquete</var> ... ]</a></dt>
<dd>
<p>
Indica que un fallo afecta a otro paquete. En el caso
de que <var>número_de_fallo</var> cause un problema en <var>paquete</var>
aunque el fallo está de hecho presente en el paquete al que está
asignado. Esto hace que la errata se muestre por omisión
en la lista de paquetes de <var>paquete</var>. Esto debería
utilizarse cuando la errata es suficientemente importante para
causar que múltiples informes de error enviados por los usuarios
se asociaran al paquete incorrecto. <code>=</code> indica que
afecta a los paquetes indicados y es la acción
por omisión si no se indican paquetes; <code>-</code> quita
los paquetes indicados de la lista de afectados,
<code>+</code> añade los paquetes indicados a la lista de afectados
y es la acción por omisión si se indican paquetes.
</p>
</dd>
<dt><a name="summary"><code>summary</code> <var>número_de_fallo</var>
[<var>número_de_mensaje</var> | <var>texto_de_resumen</var>]</a></dt>
<dd>
<p>
Selecciona el mensaje a utilizar como resumen del fallo. Se trata el
primer párrafo que no forme parte de las pseudo-cabeceras o no sea una orden de control
y se utiliza como resumen del fallo. Este resumen se muestra al principio
de la página de informe de fallos. Esto es útil en los casos en los
que el informe original no describe correctamente los problemas o
cuando el fallo tiene demasiados mensajes y se hace difícil identificar
el problema existente.
</p>
<p>
Si no se proporciona <var>número_de_mensaje</var>, se borra el resumen.
<var>número_de_mensaje</var> es el número de mensaje tal y como se
lista en la salida del script CGI bugreport; si el
<var>numero_de_mensaje</var> es 0, se usa el mensaje actual
(el mensaje enviado a control@bus.debian.org el cual contiene la orden de control summary).
</p>
<p>
Si el <var>número_de_mensaje</var> no es numérico y es una cadena no vacía, se asume
que es el texto a usar como resumen.
</p>
</dd>
<dt><a name="outlook"><code>outlook</code> <var>número_de_fallo</var>
[<var>número_de_mensaje</var> | <var>texto_de_panorama</var>]</a></dt>
<dd>
<p>
Selecciona el mensaje a utilizar como el panorama
usado para solucionar un fallo (o el estado actual
de la solución de un fallo). El primer párrafo que
no forme parte de las pseudo-cabeceras o no sea una
orden de control se utiliza como panorama del fallo,
el panorama del fallo se muestra en la parte superior
de la página del reporte de fallo. Esto es útil para
coordinar con otros que estén solucionando este fallo
(por ejemplo, en una reunión de corrección de fallos).
</p>
<p>
Si no se indica un <var>número_de_mensaje</var>, se borra el panorama,.
<var>número_de_mensaje</var> es el número de mensaje tal y como se
lista en la salida del script CGI bugreport; si el
<var>número_de_mensaje</var> es 0, se usa el mensaje actual
(el mensaje enviado a control@bus.debian.org el cual contiene
la orden de control outlook).
</p>
<p>
Si el <var>número_de_mensaje</var> no es numérico y es una cadena no vacía, se
asume que es el texto a usar como panorama.
</p>
</dd>
<dt><a name="clone"><code>clone</code> <var>número_de_fallo</var>
<var>nuevoID</var> [ <var>nuevosIDs</var> ... ]</a></dt>
<dd>
<p>
La orden de control clone le permite duplicar un informe. Es útil en caso
de que un mismo informe indique realmente que han ocurrido varios fallos
diferentes. <q><var>NuevosIDs</var></q> son números negativos, separados
por espacios, que se usarán en órdenes de control subsecuentes para
referirse a los informes recién duplicados. Se genera un nuevo informe por
cada nuevo ID.
</p>
<p>
Ejemplo de uso:
</p>
<pre>
clone 12345 -1 -2
reassign -1 foo
retitle -1 foo: foo apesta
reassign -2 bar
retitle -2 bar: bar apesta cuando se usa con foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
retitle -3 foo: foo apesta
merge -1 -3
</pre>
</dd>
<dt><a name="merge"><code>merge</code> <var>número_de_fallo</var> <var>número_de_fallo</var> ...</a></dt>
<dd>
<p>
Fusiona dos o más informes de fallo. Cuando se fusionan informes, las
operaciones de apertura apertura y cierre; marcado y desmarcado como
reenviados; y la reasignación de cualquiera de los informes a un nuevo
paquete, tendrán un efecto idéntico en el resto de los informes fusionados.
</p>
<p>
Antes de que se puedan fusionar mensajes, deben encontrarse exactamente en
el mismo estado: todos abiertos, o todos cerrados; indicando la misma
dirección de reenvío al autor original, o sin marcar; todos asignados al
mismo paquete o paquetes (se realiza una comparación exacta sobre el nombre
del paquete al que se asignó el fallo), y todos de la gravedad. Si no
comienzan en el mismo estado, debería usar <code>reassign</code>
(reasignar), <code>reopen</code> (reabrir), etc., para asegurarse de que lo
están antes usar <code>merge</code> (fusionar). No es necesario que
coincidan los títulos ya que no afectará a la fusión. Tampoco es necesario
que coincidan las etiquetas ya que se unirán éstas.
</p>
<p>
Si cualquiera de los informes listados en una orden <code>merge</code> ya
se encuentra fusionado con otro fallo, entonces todos los informes
fusionados con cualquiera de los indicados entrará en la fusión. La fusión
es como la igualdad: es reflexiva, transitiva y simétrica.
</p>
<p>
Fusionar informes hace que aparezca una nota en cada uno de ellos; en la
página web se reflejan como enlaces a los otros.
</p>
<p>
Los informes fusionados expiran todos a la vez, y sólo cuando todos y cada
uno, por se parado, cumplan el criterio de expiración.
</p>
</dd>
<dt><a name="forcemerge"><code>forcemerge</code> <var>número_de_fallo</var> <var>número_de_fallo</var> ...</a></dt>
<dd>
<p>
Fusiona a la fuerza dos o más informes de fallos. Todos los valores
definidos para el primer fallo (que deben ser iguales en una fusión
normal) se asignan a los fallos listados a continuación. Para evitar
fusionar fallos por erratas al escribir, los fallos deben estar en el mismo
paquete. Mire un poco más arriba en el texto si desea una descripción de lo
que significa fusionar.
</p>
<p>
Tenga en cuenta que esto hace posible cerrar fallos fusionándolos. Es su
responsabilidad avisar a los remitentes con un mensaje de cierre apropiado
si lo hace así.
</p>
</dd>
<dt><a name="unmerge"><code>unmerge</code> <var>número_de_fallo</var></a></dt>
<dd>
<p>
Desconecta un informe de fallo de cualquier otro informe con el que esté
fusionado. El resto de los paquetes con los que estuviera fusionado quedan
unidos; sólo se elimina su asociación con el informe indicado
explícitamente.
</p>
<p>
Si tiene muchos informes fusionados y desea separarlos en dos grupos,
deberá separar cada uno de los mensajes que quiera poner en otro grupo,
para luego fusionarlos en el nuevo grupo que se desea.
</p>
<p>
Sólo puede separar un informe con cada orden <code>unmerge</code>. Si desea
desconectar más de un informe, no tiene más que incluir varias órdenes
<code>unmerge</code> en su mensaje.
</p>
</dd>
<dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>número_de_fallo</var> [ <code>+</code> |
<code>-</code> | <code>=</code> ] <var>etiqueta</var>
[ <var>etiqueta</var> ...]</a></dt>
<dd>
<p>
Añade a las etiquetas del informe de fallo #<var>número_de_fallo</var> la
etiqueta <var>etiqueta</var>. No se enviará notificación alguna al usuario
que informó del fallo. Si la acción es <code>+</code> se añade cada
<var>etiqueta</var> listada a continuación, si la acción es <code>-</code>
se eliminan todas las <var>etiqueta</var> listadas a continuación, y si es
<code>=</code> se indica que se deben fijar los valores que se indican en
este momento. La acción por omisión
es añadir.
</p>
<p>
Ejemplo de uso:
</p>
<pre>
\# lo mismo que 'tags 123456 + patch'
tags 123456 patch
\# lo mismo que 'tags 123456 + help security'
tags 123456 help security
\# añadir las etiquetas 'fixed' y 'pending'
tags 123456 + fixed pending
\# eliminar la etiqueta 'unreproducible'
tags 123456 - unreproducible
\# fijar las etiquetas a 'moreinfo'y 'unreproducible'
tags 123456 = moreinfo unreproducible
\# quitar la etiqueta 'moreinfo' y añadir la etiqueta 'patch'
tags 123456 - moreinfo + patch
</pre>
<p>
Entre las etiquetas disponibles en este momento se incluyen
<bts_tags>.
</p>
<p>Consulte la documentación general para desarrolladores sobre el
sistema de fallos si desea conocer <a href="Developer#tags">sus
significados</a>.
</p>
</dd>
<dt><a name="block"><code>block</code> <var>número_de_fallo</var> <code>by</code>
<var>fallo</var> ...</a></dt>
<dd>
Anota de que la errata del primer fallo está bloqueado por el otro.
</dd>
<dt><a name="unblock"><code>unblock</code> <var>número_de_fallo</var>
<code>by</code> <var>fallo</var> ...</a></dt>
<dd>
Anota que el arreglo del primer fallo ya no está bloqueado por el otro.
</dd>
<dt><a name="close"><code>close</code> <var>número_de_fallo</var> [ <var>versión
arreglada</var> ] (obsoleto)</a></dt>
<dd>
<p>
Cierra el informe de fallo #<var>número_de_fallo</var>.
</p>
<p>
Se envía una notificación al usuario que informó del fallo, pero (en
contraste a enviar
<var>número_de_fallo</var><code>-done@bugs.debian.org</code>) <em>no</em> se
incluirá en la notificación el texto del mensaje que causó el cierre del
fallo. El mantenedor que cierra el fallo debería asegurarse, probablemente
enviando un mensaje aparte, de que el usuario que informó del fallo sabe
por qué ha sido cerrado. Por tanto, el uso de esta orden es obsoleto.
Consulte la información dirigida a mantenedores para ver <a
href="Developer#closing">cómo cerrar un fallo correctamente</a>.
</p>
<p>
Si proporciona una <var>versión arreglada</var>, el sistema de seguimiento
de fallos anotará que el fallo se arregló en esa versión del
paquete.
</p>
</dd>
<dt><a name="package"><code>package</code> [ <var>nombre_del_paquete</var> ... ]</a></dt>
<dd>
<p>
Limita las órdenes siguientes para que sólo se apliquen a los fallos
registrados sobre los paquetes indicados. Puede listar uno o más
paquetes. Si no indica ninguno, las órdenes siguientes se aplicarán a
todos los fallos. Se le anima a usar esta orden como medida de seguridad
para el caso en que use accidentalmente números de fallo erróneos.
</p>
<p>
Ejemplo de uso:
</p>
<pre>
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar apesta
severity 123456 normal
package
severity 234567 wishlist
</pre>
</dd>
<dt><a name="owner"><code>owner</code> <var>número_de_fallo</var> <var>dirección</var> | <code>!</code></a></dt>
<dd>
<p>
Hace que <var>dirección</var> sea el «dueño» de #<var>número_de_fallo</var>.
El dueño de un fallo se hace responsable de arreglarlo. Esto es útil para
compartir trabajo en caso de que un paquete tenga un equipo de mantenedores.
</p>
<p>Si desea convertirse en el dueño de un fallo, puede usar el atajo
<code>!</code> o especificar su propia dirección de correo.</p>
</dd>
<dt><a name="noowner"><code>noowner</code> <var>número_de_fallo</var></a></dt>
<dd>
Olvida cualquier hecho que apunte a que el fallo tenga un dueño diferente a
su mantenedor habitual. Si el fallo no tiene dueño asignado, no hará
nada.
</dd>
<dt><a name="archive"><code>archive</code> <var>número_de_fallo</var></a></dt>
<dd>
Archiva un fallo que se archivó previamente si el fallo cumple todos los
requerimientos para archivarse, ignorando el tiempo transcurrido.
</dd>
<dt><a name="unarchive"><code>unarchive</code> <var>número_de_fallo</var></a></dt>
<dd>
Saca del archivo un fallo que se archivó previamente. Generalmente cuando
se saca del archivo, la orden debería ir acompañado de <code>reopen</code> y
<code>found/fixed</code> según sea apropiado. Los fallos que se han sacado
del archivo se pueden volver a archivar usando <code>archive</code>,
asumiendo que se cumplen todos los requisitos para ser archivados
excepto el de tiempo transcurrido. No se debe usar unarchive para
hacer cambios triviales a fallos archivados, como cambiar el remitente
del fallo; el propósito principal de unarchive es permitir la reapertura
de fallos que han sido archivados sin la intervencíón de los administradores
del sistema de seguimiento de fallos.
</dd>
<dt><a name="comment"><code>#</code>...</a></dt>
<dd>
Comentario de una línea. El símbolo <code>#</code> debe estar al inicio de
la línea. El texto de los comentarios será incluido en los créditos
enviados al emisor y a los mantenedores afectados, para que así pueda
utilizarlo para documentar las razones de sus órdenes.
</dd>
<dt><a name="thanks"><code>quit</code></a></dt>
<dt><code>stop</code></dt>
<dt><code>thank</code></dt>
<dt><code>thanks</code></dt>
<dt><code>thankyou</code></dt>
<dt><code>thank you</code></dt>
<dt><code>--</code></dt>
<!-- #366093, I blame you! -->
<!-- <dt><code>kthxbye</code></dt> -->
<!-- See... I documented it! -->
<dd>
En una sola línea, en mayúsculas o minúsculas, posiblemente seguida
de espacio en blanco, le indica al servidor de control que debe parar el
proceso del mensaje; el resto puede incluir explicaciones, firmas, o
cualquier otra cosa, pero nada de esto lo detectará el servidor de control.
</dd>
</dl>
<hr />
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
Reply to: