---------- Mensaje reenviado ---------- De: Diddier Hilarion <diddierhilar...@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?. -- Diddier A Hilarion B. -- 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.89" maintainer="Fernando Cerezal" # 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>requ...@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>cont...@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. = indica que afecta a los paquetes indicados y es la acción por omisión si no se indican paquetes; - remueve los paquetes indicados de la lista de afectados, + 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 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> Se borra el resumen si no se proporciona <var>número_de_mensaje</var>. <var>número_de_mensaje</var> es el número de mensaje tal y como se lista en la salida del programa CGI bugreport; si el <var>numero_de_mensaje</var> es 0, el mensaje actual es usado(el mensaje enviado a cont...@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 el texto como el texto a usar como <var>texto_de_resumen</var>. </p> </dd> <dt><a name="outlook"><code>outlook</code> <var>número_de_fallo</var> [<var>número_de_mensaje</var> | <var></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 caza de fallos). </p> <p> Se borra el outlook, si no se indica un <var>número_de_mensaje</var>. <var>número_de_mensaje</var> es el número de mensaje tal y como se lista en la salida del programa CGI bugreport; si el <var>número_de_mensaje</var> es 0, el mensaje actual es usado (el mensaje enviado a cont...@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 el texto como el texto a usar como el 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>-d...@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 requerimientos 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"