Re: [RFR] wml://Bugs/Developer.wml
Rudy Godoy wrote:
> On 01/07/2006 at 10:11 Fernando Cerezal wrote...
>
>
>> Actualización, corregidos faltas de ortografía, comillas, palabras
>> comidas y que sobraban, cambiado error por fallo y corregido el fallo de
>> la explicación de la etiqueta upstream.... Vamos, un buen repasito.
>>
>
>
>> --- Developer.wml.orig 2006-07-01 15:34:47.000000000 +0200
>> +++ Developer.wml 2006-07-01 16:48:45.000000000 +0200
>> @@ -1,8 +1,8 @@
>> #use wml::debian::template title="Debian BTS- informaci?n para desarrolladores" NOHEADER=yes NOCOPYRIGHT=true
>> -#use wml::debian::translation-check translation="1.63" maintainer="Fernando Cerezal"
>> -<H1>Informaci?n para desarrolladores sobre el sistema de seguimiento de errores</H1>
>> +#use wml::debian::translation-check translation="1.67" maintainer="Fernando Cerezal"
>> +<H1>Informaci?n para desarrolladores sobre el sistema de seguimiento de fallos</H1>
>>
>> -<p>Inicialmente, un usuario remite un informe de error como un mensaje de correo
>> +<p>Inicialmente, un usuario remite un informe de fallo como un mensaje de correo
>> a <code>submit@bugs.debian.org</code>. Entonces se le asigna un n?mero,
>> se confirma al usuario, y se reenv?a a
>> <code>debian-bugs-dist</code>. Si el remitente incluy? una l?nea
>> @@ -17,15 +17,15 @@
>> <hrline>
>>
>> <ul>
>> - <li><a href="#closing">Cerrar informes de errores</a></li>
>> + <li><a href="#closing">Cerrar informes de fallos</a></li>
>>
>
> Creo que el término correcto es: informes de fallo, plural de
> informe de fallo.
>
>
Corregido
>> -<p>Los informes de error se deber?an cerrar enviando un correo a
>> +<p>Los informes de fallo se deber?an cerrar enviando un correo a
>>
>
> Aquí si está correcto.
>
>
>
>> <p>Ciertas severidades se consideran
>> <em><a href="http://bugs.debian.org/release-critical/";>release-critical</a></em>,
>> -que significa que el error tendr? un impacto en la publicaci?n del paquete
>> +que significa que el fallo tendr? un impacto en la publicaci?n del paquete
>> con la publicaci?n estable de Debian. Actualmente, estos son
>> <strong>critical</strong>,
>>
>
> ... con la versión estable de Debian.
>
Corregido.
>
>> <strong>grave</strong> y <strong>serious</strong>. Para obtener unas reglas
>> completas y can?nicas sobre qu? asuntos merecen estas severidades, mire la
>> lista de <a href="http://release.debian.org/etch_rc_policy.txt";>Asuntos de
>> Publicaci?n-Cr?ticos para Sarge</a>.</p>
>>
> ... para Etch</a>. ...
>
Corregido.
>
>>
>> <dt><code>unreproducible</code>
>> - <dd>Este error no lo puede reproducir el responsable del sistema. Se necesita
>> + <dd>Este fallo no lo puede reproducir el responsable del
>> sistema. Se necesita
>>
> El original dice:
> This bug can't be reproduced on the maintainer's system.
> Es decir:
> Este fallo no puede ser reproducido en el sistema del
> encargado/responsable.
>
Corregido.
>
>> -<var>nnn</var><code>-forwarded@bugs.debian.org</code>.</p>
>> +<code>CC</code> la persona que inform? del fallo,
>> +<var>nnn</var><code>-forwarded@bugs.debian.org</code>
>> +y <var>nnn</var><code>@bugs.debian.org</code>.</p>
>>
>> <p>Pregunte al autor si conservar el <code>CC</code> a
>>
>
> Pida / Solicite al autor conversar el ...
>
>
Esto no lo entiendo ¿estás seguro de esa traducción?
>> <var>nnn</var><code>-forwarded@bugs.debian.org</code> cuando contesten, de
>> -forma que el sistema de seguimiento de errores almacene su respuesta con el
>> -informe original.</p>
>> +forma que el sistema de seguimiento de fallos almacene su respuesta con el
>> +informe original. Estos mensajes s?lo se archivan y no se env?an; para mandar un mensaje normal, m?ndelos tambi?n a <var>nnn</var><code>@bugs.debian.org</code>.</p>
>>
>>
>
>
>>
>> -<h2><A name="requestserv">Reabrir, reasignar y manipular errores</A></h2>
>> +<h2><A name="requestserv">Reabrir, reasignar y manipular fallos</A></h2>
>>
>> -<p>Es posible reasignar los informes de errores a otros paquetes, reabrir
>> +<p>Es posible reasignar los informes de fallos a otros paquetes, reabrir
>> los cerrados err?neamente, modificar la informaci?n diciendo a donde, si
>> -hay alg?n sitio, se debe reenviar un informe de errores, cambiar las
>> -severidades y t?tulos de informes, establecer la propiedad de los errores y
>> -unir y separar informes de errores. Esto se hace enviando un correo a
>> +hay alg?n sitio, se debe reenviar un informe de fallo, cambiar las
>> +severidades y t?tulos de informes, establecer la propiedad de los
>> fallos y
>>
>
> ... títulos de los informes ...
>
>
>> +unir y separar informes de fallos. Esto se hace enviando un correo a
>> <code>control@bugs.debian.org</code>.</p>
>>
>> <p>El <A href="server-control">formato de estos mensajes</A> se describe
>> @@ -360,35 +361,35 @@
>> texto sin formato enviando la palabra <code>help</code> a la direcci?n del
>> servidor de m?s arriba.</p>
>>
>> -<h2><a name="subscribe">Suscribirse a errores</a></h2>
>> +<h2><a name="subscribe">Suscribirse a fallos</a></h2>
>>
>> -<p>El sistema de seguimiento de errores tambi?n permite a los remitentes,
>> -desarrolladores y otras terceras partes interesadas suscribirse a errores
>> +<p>El sistema de seguimiento de fallos tambi?n permite a los remitentes,
>> +desarrolladores y otras terceras partes interesadas en suscribirse a fallos
>> individuales. Esta capacidad la pueden usar aquellos que deseen
>> -mantener un
>>
>
> ... interesadas suscribirse ... (sin el en).
>
Corregido.
>
>> -ojo en un error, sin tener que suscribirse a un paquete a trav?s del PTS
>> -(Package Tracking System, Sistema de seguimiento de paquetes).
>> +ojo en un fallo, sin tener que suscribirse a un paquete a trav?s del <a href="http://packages.qa.debian.org";>PTS
>> +(Package Tracking System, Sistema de seguimiento de paquetes)</a>.
>> Todos los mensajes recibidos en <var>nnn</var><code>@debian.org</code>,
>> se enviar?n a los suscriptores.</p>
>>
>>
>
>
>
>> <var>nnn-loquesea</var><code>@bugs.debian.org</code>.</p>
>>
>> <p>Los mensajes que lleguen sin mayores indicaciones a <code>forwarded</code> y
>> -<code>done</code>-es decir, sin un n?mero de error en la direcci?n-
>> y sin un
>>
>
> </code> -es decir, ...
>
Esto ya estaba cambiado, en lugar del guión hay puesta una coma.
>
>> -n?mero de error en el Asunto se almacenar?n en el buz?n de ?basura? y se guardar?n
>> +<code>done</code>-es decir, sin un n?mero de fallo en la direcci?n- y sin un
>> +n?mero de fallo en el Asunto se almacenar?n en el buz?n de ?basura? y se guardar?n
>> unas pocas semanas, y por lo dem?s quedar?n en el olvido.</p>
>>
>>
>
> Si no hay más comentario avisame cuando lo tengas para subirlo.
>
Aquí va la revisión, gracias por echarle.. los dos ojos, tiene su merito ;)
un saludo.
> -Rudy
>
>
--- Developer.wml.orig 2006-07-01 15:34:47.000000000 +0200
+++ Developer.wml 2006-07-21 16:17:04.000000000 +0200
@@ -1,8 +1,8 @@
#use wml::debian::template title="Debian BTS- información para desarrolladores" NOHEADER=yes NOCOPYRIGHT=true
-#use wml::debian::translation-check translation="1.63" maintainer="Fernando Cerezal"
-<H1>Información para desarrolladores sobre el sistema de seguimiento de errores</H1>
+#use wml::debian::translation-check translation="1.67" maintainer="Fernando Cerezal"
+<H1>Información para desarrolladores sobre el sistema de seguimiento de fallos</H1>
-<p>Inicialmente, un usuario remite un informe de error como un mensaje de correo
+<p>Inicialmente, un usuario remite un informe de fallo como un mensaje de correo
a <code>submit@bugs.debian.org</code>. Entonces se le asigna un número,
se confirma al usuario, y se reenvía a
<code>debian-bugs-dist</code>. Si el remitente incluyó una línea
@@ -17,15 +17,15 @@
<hrline>
<ul>
- <li><a href="#closing">Cerrar informes de errores</a></li>
+ <li><a href="#closing">Cerrar informes de fallo</a></li>
<li><a href="#followup">Mensajes de respuesta</a></li>
<li><a href="#severities">Niveles de severidad</a></li>
- <li><a href="#tags">Etiquetas para informes de errores</a></li>
- <li><a href="#forward">Registrar que ha aprobado un informe de error</a></li>
- <li><a href="#owner">Cambiar la propiedad del error</a></li>
+ <li><a href="#tags">Etiquetas para informes de fallos</a></li>
+ <li><a href="#forward">Registrar que ha aprobado un informe de fallo</a></li>
+ <li><a href="#owner">Cambiar la propiedad del fallo</a></li>
<li><a href="#maintincorrect">Responsables de paquetes mal mostrados</a></li>
- <li><a href="#requestserv">Reabrir, reasignar y manipular errores</a></li>
- <li><a href="#subscribe">Suscribirse a errores</a></li>
+ <li><a href="#requestserv">Reabrir, reasignar y manipular fallos</a></li>
+ <li><a href="#subscribe">Suscribirse a fallos</a></li>
<li><a href="#subjectscan">Característica de escaneo de asunto más o menos obsoleto</a></li>
<li><a href="#x-debian-pr">Característica obsoleta <code>X-Debian-PR: quiet</code></a></li>
</ul>
@@ -33,35 +33,35 @@
<hrline>
-<h2><a name="closing">Cerrar informes de errores</a></h2>
+<h2><a name="closing">Cerrar informes de fallos</a></h2>
-<p>Los informes de errores en Debian se deberían cerrar cuando el problema esté
+<p>Los informes de fallos en Debian se deberían cerrar cuando el problema esté
resuelto. Los problemas en paquetes solo se pueden considerar arreglados una vez
-que un paquete incluya el arreglo del error y entre en el archivo de Debian.</p>
+que un paquete incluya el arreglo del fallo y entre en el archivo de Debian.</p>
<p>Generalmente, las únicas personas a las que se le permite cerrar un informe
-de error son el remitente del error y el(los) responsable(s) del paquete que lo
-contiene. Hay excepciones a esta regla, por ejemplo, los errores
+de fallo son el remitente del fallo y el(los) responsable(s) del paquete que lo
+contiene. Hay excepciones a esta regla, por ejemplo, los fallos
contenidos en paquetes desconocidos o ciertos pseudopaquetes genéricos. Cuando
-dude, no cierre errores, primero pregunte en la lista de correo debian-devel.</p>
+dude, no cierre fallos, primero pregunte en la lista de correo debian-devel.</p>
-<p>Los informes de error se deberían cerrar enviando un correo a
+<p>Los informes de fallo se deberían cerrar enviando un correo a
<var>nnn</var><code>-done@bugs.debian.org</code>. El cuerpo del mensaje tiene
-que contener una explicación de cómo se arregló el error.</p>
+que contener una explicación de cómo se arregló el fallo.</p>
-<p>Con los correos recibidos del sistema de seguimiento de errores, todo lo
-que necesita hacer para cerrar el error es responder con su gestor de
+<p>Con los correos recibidos del sistema de seguimiento de fallos, todo lo
+que necesita hacer para cerrar el fallo es responder con su gestor de
correo y editar el campo <code>Para:</code> o <code>A:</code> para que diga
<var>nnn</var><code>-done@bugs.debian.org</code> en lugar de
<var>nnn</var><code>@bugs.debian.org</code>
(<var>nnn</var><code>-close</code> se utiliza como un alias para
<var>nnn</var><code>-done</code>).</p>
-<p>Cuando sea posible, por favor, agregue una línea <code>Version</code> en el
+<p>Cuando sea posible, por favor, agregue una línea <code>Version</code> en la
<a href="Reporting#pseudoheader">pseudocabecera</a> de su mensaje, al cerrar
-un fallo, para que el sistema de seguimiento de errores sepa qué versión del paquete
+un fallo, para que el sistema de seguimiento de fallos sepa qué versión del paquete
contiene el arreglo.</p>
-<p>La persona que cierre el error, la que lo remitió y la lista de correo
+<p>La persona que cierre el fallo, la que lo remitió y la lista de correo
<code>debian-bugs-closed</code> recibirán cada una una notificación sobre
el cambio de estado del informe. El remitente y la lista de correo también
recibirán el contenido del mensaje enviado a
@@ -70,32 +70,32 @@
<h2><a name="followup">Mensajes de respuesta</a></h2>
-<p>El sistema de seguimiento de errores incluirá la dirección del remitente
-y la dirección del error (<var>nnn</var><code>@bugs.debian.org</code>) en el
-encabezado <code>Reply-To</code> tras reenviar el informe de error. Por
+<p>El sistema de seguimiento de fallos incluirá la dirección del remitente
+y la dirección del fallo (<var>nnn</var><code>@bugs.debian.org</code>) en el
+encabezado <code>Reply-To</code> tras reenviar el informe de fallo. Por
favor, dése cuenta de que son dos direcciones distintas.</p>
-<p>Si un desarrollador desea contestar a un informe de error simplemente
+<p>Si un desarrollador desea contestar a un informe de fallo simplemente
debería contestar al mensaje, respetando el encabezado <code>Reply-To</code>.
-Esto <strong>no</strong> cerrará el error.</p>
+Esto <strong>no</strong> cerrará el fallo.</p>
-<p>El sistema de seguimiento de errores recibirá los mensajes en
+<p>El sistema de seguimiento de fallos recibirá los mensajes en
<var>nnn</var><code>@bugs.debian.org</code>, lo pasará al responsable del
paquete, almacenará la respuesta con el resto de registros para ese informe y lo reenviará a <code>debian-bugs-dist</code>.</p>
<p>Enviando un mensaje a <var>nnn</var><code>-submitter@bugs.debian.org</code>
-enviará un correo explicitamente al remitente del error y alojará una copia en
-el sistema de seguimiento de errores. El mensaje no se enviará al desarrollador del paquete.</p>
+enviará un correo explícitamente al remitente del fallo y alojará una copia en
+el sistema de seguimiento de fallos. El mensaje no se enviará al desarrollador del paquete.</p>
<p>Si desea enviar un mensaje de respuesta que no es apropiado para
<code>debian-bugs-dist</code> puede hacerlo enviándolo a
<var>nnn</var><code>-quiet@bugs.debian.org</code> o
<var>nnn</var><code>-maintonly@bugs.debian.org</code>.
EL correo enviado a <var>nnn</var><code>-quiet@bugs.debian.org</code> se
-almacena en el sistema de seguimiento de errores pero no se envía a particulares
+almacena en el sistema de seguimiento de fallos pero no se envía a particulares
o listas de correo. El correo enviado a
<var>nnn</var><code>-maintonly@bugs.debian.org</code> se almacena
-en el sistema de seguimiento de errores y se entrega solo al responsable del
+en el sistema de seguimiento de fallos y se entrega sólo al responsable del
paquete en cuestión.</p>
<p><EM>No</EM> use las capacidades «responder a todos los buzones» o «responder»
@@ -104,18 +104,18 @@
<code>submit@bugs.debian.org</code>.</p>
<p>Para más información sobre los encabezados para suprimir los mensajes ACK
-y como enviar copias usando el sistema de seguimiento de errores,
-mire las <a href="Reporting">instrucciones para informar de errores</a>.</p>
+y como enviar copias usando el sistema de seguimiento de fallos,
+mire las <a href="Reporting">instrucciones para informar de fallos</a>.</p>
<h2><A name="severities">Niveles de severidad</A></h2>
-<p>El sistema de seguimiento de errores registra un nivel de severidad con
-cada informe de error. Este se establece como <code>normal</code>
+<p>El sistema de seguimiento de fallos registra un nivel de severidad con
+cada informe de fallo. Este se establece como <code>normal</code>
por omisión, pero se puede corregir
incluyendo una línea <code>Severity</code> en el pseudo-encabezado cuando se
-remite el error (mire las <A href="Reporting#pseudoheader">instrucciones para
-informar de errores</A>), o usando el comando <code>severity</code> en el
+remite el fallo (mire las <A href="Reporting#pseudoheader">instrucciones para
+informar de fallos</A>), o usando la orden <code>severity</code> en el
<A href="#requestserv">servidor de peticiones de control</A>.</p>
<p>Los niveles de severidad son:
@@ -138,11 +138,11 @@
hace que el paquete no se pueda publicar.
<DT><code>important</code>
-<DD>un error que tiene un efecto importante en la usabilidad de un paquete,
+<DD>un fallo que tiene un efecto importante en la usabilidad de un paquete,
sin hacerle completamente inútil para todo el mundo.
<DT><code>normal</code>
-<DD>el valor por omisión, aplicable a la mayoría de los errores.
+<DD>el valor por omisión, aplicable a la mayoría de los fallos.
<DT><code>minor</code>
<DD>un problema que no afecta a la utilidad del paquete, y presumiblemente es
@@ -150,184 +150,185 @@
<DT><code>wishlist</code>
<DD>para la petición de cualquier característica, y también para cualquier
-error que sea muy difícil de arreglar debido a consideraciones de diseño
+fallo que sea muy difícil de arreglar debido a consideraciones de diseño
mayores.</DL>
<p>Ciertas severidades se consideran
-<em><a href="http://bugs.debian.org/release-critical/";>release-critical</a></em>,
-que significa que el error tendrá un impacto en la publicación del paquete
-con la publicación estable de Debian. Actualmente, estos son <strong>critical</strong>,
+<em><a href="http://bugs.debian.org/release-critical/";>«release-critical»</a></em>,
+que significa que el fallo tendrá un impacto en la publicación del paquete
+con la versión estable de Debian. Actualmente, estos son <strong>critical</strong>,
<strong>grave</strong> y <strong>serious</strong>. Para obtener unas reglas
completas y canónicas sobre qué asuntos merecen estas severidades, mire la
lista de <a href="http://release.debian.org/etch_rc_policy.txt";>Asuntos de
-Publicación-Críticos para Sarge</a>.</p>
+Publicación-Críticos para Etch</a>.</p>
-<h2><a name="tags">Etiquetas para informes de errores</a></h2>
+<h2><a name="tags">Etiquetas para informes de fallos</a></h2>
-<p>Cada error puede tener cero o más de un conjunto de etiquetas dadas. Estas
-etiquetas se muestran en la lista de errores cuando mire en la página del
-paquete, y cuando mire el registro completo del error.
+<p>Cada fallo puede tener cero o más de un conjunto de etiquetas dadas. Estas
+etiquetas se muestran en la lista de fallos cuando mire en la página del
+paquete, y cuando mire el registro completo del fallo.
<p>Las etiquetas se pueden establecer poniendo una línea <code>Tags</code>
-en el pseudo-encabezado cuando se remite el error (mire las
-<a href="Reporting#pseudoheader">instrucciones para informar de errores</a>),
+en el pseudoencabezado cuando se remite el fallo (mire las
+<a href="Reporting#pseudoheader">instrucciones para informar de fallos</a>),
o usando el comando <code>tags</code> en el <a href="#requestserv">servidor de
peticiones de control</a>. Separe varias etiquetas con comas, espacios, o ambos.
-<p>Las actuales etiquetas para errores son:
+<p>Las actuales etiquetas para fallos son:
<dl>
<dt><code>patch</code>
<dd>Un parche o cualquier otro procedimiento fácil para arreglarlo se
- incluye en el registro de error. Si hay un parche, pero no resuelve el error
+ incluye en el registro de fallo. Si hay un parche, pero no resuelve el fallo
adecuadamente o causa algún otro problema, no se debería usar esta etiqueta.
<dt><code>wontfix</code>
- <dd>Este error no se quiere arreglar. Posiblemente porque sea una elección
+ <dd>Este fallo no se quiere arreglar. Posiblemente porque sea una elección
entre dos formas arbitrarias de hacer las cosas y el responsable y el
remitente prefieren formas distintas de hacerlas, posiblemente porque
cambiar el comportamiento causará otros, peores, problemas para otras personas,
o posiblemente por otras razones.
<dt><code>moreinfo</code>
- <dd>Este error no se puede tratar hasta que el remitente proporcione más
- información. El error se puede cerrar si el remitente no proporciona más
+ <dd>Este fallo no se puede tratar hasta que el remitente proporcione más
+ información. El fallo se puede cerrar si el remitente no proporciona más
información en un período de tiempo razonable (unos pocos meses). Esto es para
- errores como "No funciona". ¿Qué no funciona?
+ fallos como «No funciona». ¿Qué no funciona?
<dt><code>unreproducible</code>
- <dd>Este error no lo puede reproducir el responsable del sistema. Se necesita
+ <dd>Este fallo no puede ser reproducido en el sistema del responsable. Se necesita
la asistencia de terceras partes para diagnosticar las causa del problema.
<dt><code>help</code>
- <dd>El responsable está pidiendo ayuda para tratar este error.
+ <dd>El responsable está pidiendo ayuda para tratar este fallo.
<dt><code>pending</code>
- <dd>Se ha encontrado una solución a este error y se enviará pronto.
+ <dd>Se ha encontrado una solución a este fallo y se enviará pronto.
<dt><code>fixed</code>
- <dd>Este error está arreglado o hay un arreglo temporal (por un envío de una persona
+ <dd>Este fallo está arreglado o hay un arreglo temporal (por un envío de una persona
que no es la responsable, por ejemplo), pero todavía hay un asunto que hay que resolver.
- Esta etiqueta reemplaza la antigua severidad "fixed".
+ Esta etiqueta reemplaza la antigua severidad «fixed».
<dt><code>security</code>
- <dd>Este error describe un problema de seguridad en un paquete (e.g., malos
+ <dd>Este fallo describe un problema de seguridad en un paquete (e.g., malos
permisos permitiendo el acceso a datos que no deberían ser accesibles;
sobre-ejecución de «buffer» permitiendo a la gente controlar un sistema de
formas que no debería poder; denegación de servicio que se debería arreglar,
- etc). La mayoría de los errores de seguridad también se deberían establecer en
- severidad critical o grave.
+ etc). La mayoría de los fallos de seguridad también se deberían establecer en
+ severidad «critical» o «grave».
<dt><code>upstream</code>
- <dd>Este error se aplica a la parte del paquete que se envía.
+ <dd>Este error se aplica a la parte del paquete proporcionada por el desarrollador del programa.
<dt><code>confirmed</code>
<dd>El responsable ha mirado, entiende, y básicamente está de acuerdo con
- el error, pero todavía no lo ha arreglado. (El Uso de esta etiqueta es
+ el fallo, pero todavía no lo ha arreglado. (El Uso de esta etiqueta es
opcional; se pretende que sea para los responsables de paquetes que
- necesitan gestionar un gran número de errores abiertos.)
+ necesitan gestionar un gran número de fallos abiertos.)
<dt><code>fixed-upstream</code>
- <dd>El error ha sido arreglado por el responsable principal, pero todavía
+ <dd>El fallo ha sido arreglado por el responsable principal, pero todavía
no está en el paquete (por la razón que sea: quizás es muy complicado
hacer el cambio compatible con versiones anteriores o tenga muy poco valor
para tomarse la molestia).
<dt><code>fixed-in-experimental</code>
- <dd>El error ha sido arreglado en el paquete de la distribución experimental,
+ <dd>El fallo ha sido arreglado en el paquete de la distribución experimental,
pero todavía no en la distribución inestable.
<dt><code>d-i</code>
- <dd>Este error es relevante para el desarrollo del instalador de Debian. Se
- espera que se use cuando el error afecte al desarrollo del instalador, pero
+ <dd>Este fallo es relevante para el desarrollo del instalador de Debian. Se
+ espera que se use cuando el fallo afecte al desarrollo del instalador, pero
no está en un paquete que forme parte directa del instalador mismo.
<dt><code>ipv6</code>
- <dd>Este error afecta al soporte de la versión 6 del Protocolo de Internet.
+ <dd>Este fallo afecta al soporte de la versión 6 del Protocolo de Internet.
<dt><code>lfs</code>
- <dd>Este error afecta al soporte para archivos grandes (más de 2 gigabytes).
+ <dd>Este fallo afecta al soporte para archivos grandes (más de 2 gigabytes).
<dt><code>l10n</code>
- <dd>Este error es relevante para la localización del paquete.
+ <dd>Este fallo es relevante para la localización del paquete.
<dt><code>potato</code>
- <dd>Este error afecta particularmente a la publicación potato de Debian.
+ <dd>Este fallo afecta particularmente a la publicación potato de Debian.
<dt><code>woody</code>
- <dd>Este error afecta particularmente a la publicación woody de Debian.
+ <dd>Este fallo afecta particularmente a la publicación woody de Debian.
<dt><code>sarge</code>
- <dd>Este error afecta particularmente a la publicación sarge de Debian.
+ <dd>Este fallo no se debería archivar hasta que esté arreglado en sarge.
<dt><code>sarge-ignore</code>
- <dd>Este error «release-critical» se va a ignorar para los propósitos de
+ <dd>Este fallo «release-critical» se va a ignorar para los propósitos de
publicación de sarge. <strong>Esta etiqueta solo la deberían usar los
gestores de publicación; no la ponga usted mismo sin autorización
explícita de ellos.</strong>
<dt><code>etch</code>
- <dd>Este error afecta particularmente a la (no publicada) distribución etch.
+ <dd>Este fallo no se debería archivar hasta que esté arreglado en etch.
<dt><code>etch-ignore</code>
- <dd>Este error «release-critical» se va a ignorar para los propósitos de
+ <dd>Este fallo «release-critical» se va a ignorar para los propósitos de
publicación de etch. <strong>Esta etiqueta solo la deberían usar los
gestores de publicación; no la ponga usted mismo sin autorización
explícita de ellos.</strong>
<dt><code>sid</code>
- <dd>Este error afecta particularmente a una arquitectura que actualmente
- no está publicada (que es, en la distribución sid).
+ <dd>Este fallo no se debería archivar hasta que esté arreglado en sid.
<dt><code>experimental</code>
- <dd>Este error afecta particularmente a la distribución experimental.
-
-</dl>
+ <dd>Este fallo no se debería archivar hasta que esté arreglado en experimental.
-<p>Las últimas cinco etiquetas se pretende que se usen principalmente para
-la publicación de errores críticos, para los que es importante saber a qué
-distribuciones afectan para asegurarse de que se hacen los arreglos (o se
-quita lo necesario) en los lugares adecuados.
+</dl>
+<p>El significado de las últimas seis etiquetas se ha cambiado recientemente;
+ las etiquetas «ignore» ignoran el fallo para el propósito de una propagación
+ a «testing». Las etiquetas «release», que se utilizaban para indicar qué
+ fallos afectaban a una publicación específica, ahora indican cuando se puede
+ archivar un fallo.
+</p>
-<h2><A name="forward">Registrar que ha aprobado un informe de error</A></h2>
+<h2><A name="forward">Registrar que ha aprobado un informe de fallo</A></h2>
-<p>Cuando un desarrollador reenvía un informe de error al responsable
+<p>Cuando un desarrollador reenvía un informe de fallo al responsable
principal del paquete fuente del cual deriva el paquete Debian,
-deberían anotarlo en el sistema de seguimiento de errores de la siguiente manera:</p>
+deberían anotarlo en el sistema de seguimiento de fallos de la siguiente manera:</p>
<p>Asegúrese de que el campo <code>To</code> de su mensaje al autor
tiene solo la(s) dirección(es) de el(los) autor(es); ponga en el campo
-<code>CC</code>tanto la persona que informó del error como
-<var>nnn</var><code>-forwarded@bugs.debian.org</code>.</p>
+<code>CC</code> la persona que informó del fallo,
+<var>nnn</var><code>-forwarded@bugs.debian.org</code>
+y <var>nnn</var><code>@bugs.debian.org</code>.</p>
<p>Pregunte al autor si conservar el <code>CC</code> a
<var>nnn</var><code>-forwarded@bugs.debian.org</code> cuando contesten, de
-forma que el sistema de seguimiento de errores almacene su respuesta con el
-informe original.</p>
+forma que el sistema de seguimiento de fallos almacene su respuesta con el
+informe original. Estos mensajes sólo se archivan y no se envían; para mandar un mensaje normal, mándelos también a <var>nnn</var><code>@bugs.debian.org</code>.</p>
-<p>Cuando el sistema de seguimiento de errores reciba un mensaje en
-<var>nnn</var><code>-forwarded</code> marcará el error como que ha sido
+<p>Cuando el sistema de seguimiento de fallos reciba un mensaje en
+<var>nnn</var><code>-forwarded</code> marcará el fallo como que ha sido
reenviado a la(s) dirección(es) en el campo <code>To</code>
-del mensaje recibido, si el error no se ha marcado ya como reenviado.</p>
+del mensaje recibido, si el fallo no se ha marcado ya como reenviado.</p>
<p>También puede manipular la información «reenviado a» enviando mensajes a
<A href="server-control"><code>control@bugs.debian.org</code></A>.</p>
-<h2><a name="owner">Cambiar la propiedad de un error</a></h2>
+<h2><a name="owner">Cambiar la propiedad de un fallo</a></h2>
-<p>En los casos donde la persona responsable de arreglar un error no es el
+<p>En los casos donde la persona responsable de arreglar un fallo no es el
responsable asignado al paquete asociado (por ejemplo, cuando el paquete es
mantenido por un equipo), puede ser útil registrar este hecho en el sistema
-de seguimiento de errores. Para ayudar a esto, cada error puede opcionalmente
+de seguimiento de fallos. Para ayudar a esto, cada fallo puede opcionalmente
tener un propietario.
<p>Se puede establecer el propietario incluyendo una línea <code>Owner</code>
-en el pseudo-encabezado cuando se remita el error (mire las
-<a href="Reporting#pseudoheader">instrucciones para informar de errores</a>),
+en el pseudo-encabezado cuando se remita el fallo (mire las
+<a href="Reporting#pseudoheader">instrucciones para informar de fallos</a>),
o usando los comandos <code>owner</code> y <code>noowner</code> en el
<a href="#requestserv">servidor de peticiones de control</a>.
@@ -345,13 +346,13 @@
reescritura en el archivo.</p>
-<h2><A name="requestserv">Reabrir, reasignar y manipular errores</A></h2>
+<h2><A name="requestserv">Reabrir, reasignar y manipular fallos</A></h2>
-<p>Es posible reasignar los informes de errores a otros paquetes, reabrir
+<p>Es posible reasignar los informes de fallos a otros paquetes, reabrir
los cerrados erróneamente, modificar la información diciendo a donde, si
-hay algún sitio, se debe reenviar un informe de errores, cambiar las
-severidades y títulos de informes, establecer la propiedad de los errores y
-unir y separar informes de errores. Esto se hace enviando un correo a
+hay algún sitio, se debe reenviar un informe de fallo, cambiar las
+severidades y títulos de los informes, establecer la propiedad de los fallos y
+unir y separar informes de fallos. Esto se hace enviando un correo a
<code>control@bugs.debian.org</code>.</p>
<p>El <A href="server-control">formato de estos mensajes</A> se describe
@@ -360,35 +361,35 @@
texto sin formato enviando la palabra <code>help</code> a la dirección del
servidor de más arriba.</p>
-<h2><a name="subscribe">Suscribirse a errores</a></h2>
+<h2><a name="subscribe">Suscribirse a fallos</a></h2>
-<p>El sistema de seguimiento de errores también permite a los remitentes,
-desarrolladores y otras terceras partes interesadas suscribirse a errores
+<p>El sistema de seguimiento de fallos también permite a los remitentes,
+desarrolladores y otras terceras partes interesadas suscribirse a fallos
individuales. Esta capacidad la pueden usar aquellos que deseen mantener un
-ojo en un error, sin tener que suscribirse a un paquete a través del PTS
-(Package Tracking System, Sistema de seguimiento de paquetes).
+ojo en un fallo, sin tener que suscribirse a un paquete a través del <a href="http://packages.qa.debian.org";>PTS
+(Package Tracking System, Sistema de seguimiento de paquetes)</a>.
Todos los mensajes recibidos en <var>nnn</var><code>@debian.org</code>,
se enviarán a los suscriptores.</p>
-<p>Se puede suscribir a un error enviando un correo a
+<p>Se puede suscribir a un fallo enviando un correo a
<var>nnn</var><code>-subscribe@bugs.debian.org</code>. El BTS ignorará
el asunto y el cuerpo del mensaje. Una vez que se procese el mensaje, se les
manda un mensaje de confirmación a los usuarios que necesita que hay que
-contestar antes de que envíen mensajes relacionados con el error.</p>
+contestar antes de que envíen mensajes relacionados con el fallo.</p>
-<p>También es posible darse de baja de un error. Se puede dar de baja
+<p>También es posible darse de baja de un fallo. Se puede dar de baja
enviando un correo a <var>nnn</var><code>-unsubscribe@bugs.debian.org</code>.
De nuevo el BTS ignorará el asunto y el cuerpo del mensaje. Se les enviará
un mensaje de confirmación a los usuarios, que tienen que contestar
-si desean que se les dé de baja de un error.</p>
+si desean que se les dé de baja de un fallo.</p>
<p>Por omisión, la dirección que se da baja es la que se encuentre en el
-encabezado <code>From</code>. Si desea suscribir otra dirección al error,
+encabezado <code>From</code>. Si desea suscribir otra dirección al fallo,
necesitará codificar la dirección a suscribir en el mensaje de suscripción,
de la siguiente forma:
<var>nnn</var><code>-subscribe-</code><var>correoespecial</var><code>=</code><var>ejemplo.com</var><code>@bugs.debian.org</code>.
Este ejemplo enviaría a <code>correoespecial@ejemplo.com</code> un mensaje de
-suscripción para el error <var>nnn</var>. El signo <code>@</code> se debe
+suscripción para el fallo <var>nnn</var>. El signo <code>@</code> se debe
codificar cambiándolo por un signo <code>=</code>. De forma similar, darse
de baja toma la forma
<var>nnn</var><code>-unsubscribe-</code><var>correoespecial</var><code>=</code><var>ejemplo.com</var><code>@bugs.debian.org</code>.
@@ -413,14 +414,14 @@
<var>nnn-loquesea</var><code>@bugs.debian.org</code>.</p>
<p>Los mensajes que lleguen sin mayores indicaciones a <code>forwarded</code> y
-<code>done</code>-es decir, sin un número de error en la dirección- y sin un
-número de error en el Asunto se almacenarán en el buzón de «basura» y se guardarán
+<code>done</code>, es decir, sin un número de fallo en la dirección, y sin un
+número de fallo en el Asunto se almacenarán en el buzón de «basura» y se guardarán
unas pocas semanas, y por lo demás quedarán en el olvido.</p>
<h2><a name="x-debian-pr">Característica obsoleta <code>X-Debian-PR: quiet</code></a></h2>
-<p>Solía poderse evitar que el sistema de seguimiento de errores de
+<p>Solía poderse evitar que el sistema de seguimiento de fallos
reenviase a <code>debian-bugs</code> los mensajes que recibía,
poniendo una línea <code>X-Debian-PR: quiet</code> en la cabecera real
del correo.</p>
Reply to: