[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] wml://Bugs/server-control.wml



David Martínez Moreno wrote:
> El sábado, 3 de junio de 2006 11:24, Fernando Cerezal escribió:
>   
>>  <P>El servidor «control» trabaja igual que el servidor «request», excepto
>>  en que tiene algunas órdenes más; en realidad, es el mismo programa. Las
>>  dos direcciones están separadas sólo para evitar que los usuarios cometan
>> -errores y causen problemas si sólo intentan pedir información.</P>
>> +fallos y causen problemas si sólo intentan pedir información.</P>
>>     
>
> 	Esto no me gusta. ¿Qué tal esto?:
>
> «El servicio que atiende control@bugs.debian.org trabaja de la misma manera 
> que el que atiende request@bugs.debian.org; en realidad, son el mismo 
> programa.»
>
>   
Cambiado.
> 	Por otra parte, supongo que deberíamos rodear las direcciones de los 
> correspondientes <code>.
>
>   
Hecho.
> 	Ah, y observo que las etiquetas están en mayúsculas...Ya de paso, las 
> cambiamos, ¿no?
>
>   
Hecho y he cerrado algunas que estaban son cerrar.
> 	Un saludo,
>   
otro.
> 		Ender.
>   

--- server-control.wml.orig	2006-05-24 19:52:30.000000000 +0200
+++ server-control.wml	2006-07-03 00:01:15.000000000 +0200
@@ -1,67 +1,65 @@
 #use wml::debian::template title="Debian BTS - control del servidor" NOHEADER=yes NOCOPYRIGHT=true
-#use wml::debian::translation-check translation="1.49" maintainer="Fernando Cerezal"
+#use wml::debian::translation-check translation="1.53" maintainer="Fernando Cerezal"
 
-<h1>Información para desarrolladores sobre cómo manipular errores
+<h1>Información para desarrolladores sobre cómo manipular fallos
 utilizando el interfaz de correo electrónico.</h1>
 
-<P>Además del servidor de correo que hay en
-<code>request@bugs.debian.org</code> y que permite obtener datos de errores
+<p>Además del servidor de correo que hay en
+<code>request@bugs.debian.org</code> y que permite obtener datos de fallos
 y documentación mediante correo electrónico, hay otro servidor en
 <code>control@bugs.debian.org</code> que permite manipular los informes de
-errores de varias maneras.</P>
+fallos de varias maneras.</p>
 
-<P>El servidor «control» trabaja igual que el servidor «request», excepto
-en que tiene algunas órdenes más; en realidad, es el mismo programa. Las
-dos direcciones están separadas sólo para evitar que los usuarios cometan
-errores y causen problemas si sólo intentan pedir información.</P>
+<p>El servicio que atiende <code>control@bugs.debian.org</code> trabaja de la misma manera 
+que el que atiende <code>request@bugs.debian.org</code>; en realidad, son el mismo programa.</p>
 
 <p>Se envía una notificación al mantenedor del paquete o paquetes al
-que están asignados los errores ya que las órdenes especificas al 
-servidor de control cambian el estado de un error. Además, se registran
+que están asignados los fallos ya que las órdenes especificas 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 WWW.</p>
 
-<P>Si desea obtener detalles de operación básica de los servidores de
+<p>Si desea obtener detalles de operación básica de los servidores de
 correo y las órdenes comunes a ambos su disposición, lea por favor la
-página <A href="server-request#introduction">Cómo pedir informes de
-error por correo</A> disponible en el World Wide Web, en el fichero
+página <a href="server-request#introduction">Cómo pedir informes de
+fallo por correo</a> disponible en el World Wide Web, en el fichero
 <code>bug-log-mailserver.txt</code>, o envíe <code>help</code> a
-cualquiera de los servidores de correo.</P>
+cualquiera de los servidores de correo.</p>
 
-<P>La <A href="server-refcard">tarjeta de referencia</A> de los
+<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>
+usando la orden <code>refcard</code>.</p>
 
-<H1>Ordenes disponibles en el servidor de correo "control"</H1>
+<h1>Ordenes disponibles en el servidor de correo "control"</h1>
 
 <dl>
 
-<dt><code>reassign</code> <var>número de error</var> <var>paquete</var>
+<dt><code>reassign</code> <var>númerodefallo</var> <var>paquete</var>
  [ <var>versión</var> ]
 <dd>
 
-Registra que el error #<var>número de error</var> pertenece al
+Registra que el fallo #<var>númerodefallo</var> pertenece al
 <var>paquete</var>. Puede usarse para establecer el paquete si el usuario
 lo olvidó en la pseudocabecera, 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>Si proporciona una <var>versión</var>, el sistema de seguimiento de 
-errores notará que el error afecta a esa versión del nuevo paquete asignado.</p>
+fallos notará que el fallo afecta a esa versión del nuevo paquete asignado.</p>
 
-<dt><code>reopen</code> <var>número de error</var>
+<dt><code>reopen</code> <var>númerodefallo</var>
  [ <var>dirección del descubridor</var> | <code>=</code> | <code>!</code> ]
 <dd>
 
-Reabre el #<var>número de error</var> en caso de que estuviera cerrado.
+Reabre el #<var>númerodefallo</var> en caso de que estuviera cerrado.
 
 <p>Por defecto, o si especifica <code>=</code>, se mantendrá el informador
-original del error tal cual, de manera que obtendrá una notificación
+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 error por esta otra. Si
+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>
 
@@ -69,88 +67,88 @@
 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 error no está cerrado, reabrirlo no hará nada, siquiera
-cambiar quién envió el error. Para cambiar esto de un informe de error 
+<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>; percátese de que esto informará 
-a la persona que envió el error en primer lugar del cambio.
+a la persona que envió el fallo en primer lugar del cambio.
 
-<p>Si el error se registró como que había sido cerrado en una versión 
+<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 el comando <code>found</code> en su lugar.
 
-<dt><code>found</code> <var>número de error</var> [ <var>versión</var> ]
+<dt><code>found</code> <var>númerodefallo</var> [ <var>versión</var> ]
 
-<dd>Registra que #<var>número de error</var> se ha encontrado en la versión dada en
+<dd>Registra que #<var>númerodefallo</var> se ha encontrado en la versión dada en
 <var>versión</var> del paquete al que se asignó.
 
-<p>El sistema de seguimiento de errores utiliza esta información, junto con
-los registros de las versiones arregladas al cerrar los errores, para mostrar
-listas de errores abiertos en varias versiones de cada paquete. Considera abrir
-un error cuando no tiene versión arreglada, o cuando se ha encontrado mas 
+<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 abrir
+un fallo cuando no tiene versión arreglada, o cuando se ha encontrado más 
 recientemente de lo que ha sido arreglado.
 
 <p>Si no se da una <var>versión</var>, entonces la lista de versiones 
-arregladas para el error está clara. Es idéntico al comportamiento de 
+arregladas para el fallo está clara. Es idéntico al comportamiento de 
 <code>reopen</code>.
 
 <p>Este comando se introdujo prefiriéndose a <code>reopen</code>
 porque era difícil añadir una <var>versión</var> a ese sintaxis de comandos
 sin sufrir ambigüedad.
 
-<dt><code>notfound</code> <var>número de error</var> <var>versión</var>
+<dt><code>notfound</code> <var>númerodefallo</var> <var>versión</var>
 
-<dd>Borra el registro de #<var>número de error</var> que se encontró en la
+<dd>Borra el registro de #<var>númerodefallo</var> que se encontró en la
  <var>versión</var> dada del paquete al que está asignado.
 
-<p>Esto difiere de cerrar el error en esa versión en que no se lista
+<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 error.
+versión. Se pretende que sea para guardar en el registro cuándo se encontró un fallo.
 
-<dt><code>submitter</code> <var>número de error</var>
+<dt><code>submitter</code> <var>númerodefallo</var>
 <var>dirección del informador</var> | <code>!</code>
 <dd>
 
-Cambia el informador del error #<var>número</var> a 
+Cambia el informador del fallo #<var>número</var> a 
 <var>dirección del informador</var>.
 
-<p>Si desea ser la nueva persona origen del error, puede usar la 
+<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 
-errores fusionados con el que se está reabriendo, la orden <code>submitter</code>
-no afecta a los errores fusionados.</p>
+fallos fusionados con el que se está reabriendo, la orden <code>submitter</code>
+no afecta a los fallos fusionados.</p>
 
-<dt><code>forwarded</code> <var>número de error</var> <var>dirección</var>
+<dt><code>forwarded</code> <var>númerodefallo</var> <var>dirección</var>
 <dd>
 
-Indica que <var>número de error</var> ha sido informado al mantenedor
+Indica que <var>númerodefallo</var> ha sido informado al mantenedor
 oficial en <var>address</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 error del que no se había indicado que
+para registrar una nueva para un fallo del que no se había indicado que
 fue reenviado.
 
-<dt><code>notforwarded</code> <var>número de error</var>
+<dt><code>notforwarded</code> <var>númerodefallo</var>
 <dd>
 
-Elimina cualquier registro de que <var>número de error</var> haya sido
-reenviado a algún mantenedor oficial. Si este error no tenía registros
+Elimina cualquier registro de que <var>númerodefallo</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.
 
-<dt><code>retitle</code> <var>número de error</var> <var>nuevo título</var>
+<dt><code>retitle</code> <var>númerodefallo</var> <var>nuevo título</var>
 <dd>
 
-Cambia el título del informe de error por el que se especifica (por
+Cambia el título del informe de fallo por el que se especifica (por
 defecto se toma la cabecera <code>Asunto</code>) del mensaje original).
 
 <p>Al contrario que la mayoría de las otras órdenes de manipulación de
-errores, cuando se usa en un conjunto de mensajes fusionados, sólo cambiará
-el título del número de error solicitado, y no el de aquellos con los que
+fallos, cuando se usa en un conjunto de mensajes fusionados, sólo cambiará
+el título del número de fallo solicitado, y no el de aquellos con los que
 fue fusionado (<i>merged</i>).
 
-<dt><code>severity</code> <var>número de error</var> <var>gravedad</var>
+<dt><code>severity</code> <var>númerodefallo</var> <var>gravedad</var>
 <dd>
 
-<p>Establece el nivel de gravedad del informe de errores
+<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>
 
@@ -160,13 +158,13 @@
 
 <p>Si desea saber <A href="Developer#severities">sus significados</A>,
 sírvase consultar la documentación general para desarrolladores sobre el
-sistema de errores.
+sistema de fallos.
 
-<dt><code>clone</code> <var>número de error</var> [ <var>nuevos ID</var> ]
+<dt><code>clone</code> <var>númerodefallo</var> <var>nuevoID</var> [ <var>nuevosIDs</var> ... ]
 
   <dd>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
-  errores diferentes. "<var>Nuevos ID</var>" son números negativos,
+  fallos diferentes. «<var>NuevosIDs</var>» 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.
@@ -187,10 +185,10 @@
   </pre>
 
 
-<dt><code>merge</code> <var>número de error</var> <var>número de error</var> ...
+<dt><code>merge</code> <var>númerodefallo</var> <var>númerodefallo</var> ...
 <dd>
 
-Fusiona dos o más informes de error. Cuando se fusionan informes, las
+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
@@ -200,31 +198,44 @@
 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 error), y todos de la
+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 error, entonces todos los informes
+<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
+<p>Fusionar informes hace que aparezca una nota en cada uno de ellos; en
 la página WWW 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>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>
 
-<dt><code>unmerge</code> <var>número de error</var>
+<dt><code>forcemerge</code> <var>númerodefallo</var> <var>númerodefallo</var> ...</dt>
+  <dd>Fusiona a la fuerza dos o más informes de fallos. El primer fallo listado
+     es el maestro, y se le asignan sus parámetros (los parámetros que deben ser
+     iguales en una fusión normal) a los siguientes fallos en la lista. 
+     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. </dd>
+
+
+  <p>Dese cuenta que esto hace posible cerrar fallos fusionándolos; Es usted
+     responsable de avisar a los remitentes con un mensaje de cierre apropiado si lo hace.</p>
+  </dd>
+
+<dt><code>unmerge</code> <var>númerodefallo</var>
 <dd>
 
-Desconecta un informe de error de cualquier otro informe con el que esté
+<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.
+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,
@@ -232,13 +243,13 @@
 
 <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.
+órdenes <code>unmerge</code> en su mensaje.</p>
 
-<dt><code>tags</code> <var>número de error</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>etiqueta</var> [ <var>etiqueta</var> ...]
+<dt><code>tags</code> <var>númerodefallo</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>etiqueta</var> [ <var>etiqueta</var> ...]
 
-  <dd>Añade a las etiquetas del informe de error
+  <dd>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 error.
+  enviará notificación alguna al usuario que informó del fallo.
   Si la acción es <code>+</code> se añade, si la acción es <code>-</code>
   se sustrae y si es <code>=</code> se
   indica que se han de ignorar las etiquetas que hayan
@@ -276,37 +287,37 @@
   <code>etch-ignore</code>, <code>sid</code> y <code>experimental</code>.
 
   <p>Consulte la documentación general para desarrolladores sobre el
-  sistema de errores si desea conocer <a href="Developer#tags">sus
-  significados</a>.
+  sistema de fallos si desea conocer <a href="Developer#tags">sus
+  significados</a>.</p>
 
 
-<dt><code>close</code> <var>número de error</var> [ <var>versión arreglada</var> ]
+<dt><code>close</code> <var>númerodefallo</var> [ <var>versión arreglada</var> ]
 (obsoleto)
 <dd>
 
-Cierra el informe de error #<var>número de error</var>.
+Cierra el informe de fallo #<var>númerodefallo</var>.
 
-<p>Se envía una notificación al usuario que informó del error, pero (en
-contraste a enviar <var>número de error</var><code>-done@bugs.debian.org</code>)
+<p>Se envía una notificación al usuario que informó del fallo, pero (en
+contraste a enviar <var>númerodefallo</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 error. El mantenedor que cierra el error debería asegurarse,
+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 error sabe por qué ha sido cerrado.
+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 error correctamente</a>.
+<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 errores se dará cuenta de que el error se arregló en esa versión del
-paquete.
+de fallos se dará cuenta de que el fallo se arregló en esa versión del
+paquete.</p>
 
 <dt><code>package</code> [ <var>nombredelpaquete</var> ... ]
 
-  <dd>Limita las órdenes siguientes para que sólo se apliquen a los errores
+  <dd>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 errores. Se le anima a usar esta orden como medida de seguridad
-  para el caso en que use números de error erróneos accidentalmente.
+  todos los fallos. Se le anima a usar esta orden como medida de seguridad
+  para el caso en que use números de fallo erróneos accidentalmente.
 
   <p>Ejemplo de uso:</p>
 
@@ -322,20 +333,20 @@
         severity 234567 wishlist
   </pre>
 
-<dt><code>owner</code> <var>número de error</var> <var>dirección</var> | <code>!</code>
+<dt><code>owner</code> <var>númerodefallo</var> <var>dirección</var> | <code>!</code>
 
-  <dd>Hace que <var>dirección</var> sea el «dueño» de #<var>número de error</var>.
-  El dueño de un error se hace responsable de arreglarlo y recibirá todo
+  <dd>Hace que <var>dirección</var> sea el «dueño» de #<var>númerodefallo</var>.
+  El dueño de un fallo se hace responsable de arreglarlo y recibirá todo
   el correo al respecto. Esto es útil para compartir trabajo en caso de
   que un paquete tenga un equipo de mantenedores.
 
-  <p>Si desea convertirse en el dueño de un error, puede usar el atajo
+  <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>
 
-<dt><code>noowner</code> <var>número de error</var>
+<dt><code>noowner</code> <var>númerodefallo</var>
 
-  <dd>Olvida cualquier idea de que el error tenga un dueño diferente a su
-  mantenedor habitual. Si el error no tiene dueño asignado, no hará nada.
+  <dd>Olvida cualquier idea de que el fallo tenga un dueño diferente a su
+  mantenedor habitual. Si el fallo no tiene dueño asignado, no hará nada.
 
 <dt><code>#</code>...
 

Reply to: