[LCFC] wml://Bugs/Developer.wml
Hola a todos/as
Gracias Rafa por la revisión.
Sin cambios desde el RFR.
Saludos
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
#use wml::debian::template title="Debian BTS — información para desarrolladores" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="859f960fa633147bac5504a51b2e29800627217a" maintainer="Laura Arjona Reina"
<h1>Información sobre el sistema de seguimiento de fallos para desarrolladores
y personas que tratan fallos</h1>
<p>Inicialmente, un usuario remite un informe de fallo como un mensaje de correo
a <code>submit@bugs.debian.org</code> que debe incluir una lÃnea <code>Package</code>
(vea <a href="Reporting">cómo informar de un fallo</a> para más detalles).
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
<code>Package</code> listando un paquete con responsable conocido,
al responsable también le llegará una copia.</p>
<p>La lÃnea <code>Asunto</code> contendrá añadido
<code>Bug#</code><var>nnn</var><code>:</code>, y el
<code>Reply-To</code> estará hecho para incluir al remitente del informe
y <var>nnn</var><code>@bugs.debian.org</code>.</p>
<ul class="toc">
<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 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 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>
<h2><a name="closing">Cerrar informes de fallos</a></h2>
<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 fallo y entre en el archivo de Debian.</p>
<p>Generalmente, las únicas personas que deberÃan cerrar un informe
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 fallos, primero pregunte en la lista de correo debian-devel.</p>
<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 fallo.</p>
<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 la
<a href="Reporting#pseudoheader">pseudocabecera</a> de su mensaje, al cerrar
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 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
<var>nnn</var><code>-done</code>.</p>
<h2><a name="followup">Mensajes de respuesta</a></h2>
<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>Cualquier desarrollador que desee 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 fallo.</p>
<p><em>No</em> use las capacidades <q>responder a todos los buzones</q> o <q>responder</q>
de su gestor de correo a menos que pretenda editar los buzones sustancialmente.
En concreto, mire que no envÃa mensajes de respuesta a
<code>submit@bugs.debian.org</code>.</p>
<p>
Para comunicarse con el sistema de seguimiento de fallos, se pueden enviar mensajes
a las siguientes direcciones:
</p>
<ul>
<li>
<var>nnn</var><code>@bugs.debian.org</code> â?? estos mensajes también se envÃan al
mantenedor del paquete y se reenvÃan a <code>debian-bugs-dist</code>,
pero <strong>no</strong> al remitente del informe de fallo;
</li>
<li>
<var>nnn</var><code>-submitter@bugs.debian.org</code> â?? estos mensajes también se
envÃan al remitente del informe de fallo y se reenvÃan a <code>debian-bugs-dist</code>,
pero <strong>no</strong> al mantenedor del paquete;
</li>
<li>
<var>nnn</var><code>-maintonly@bugs.debian.org</code> â?? estos mensajes se envÃan sólo
al mantenedor del paquete, <strong>no</strong> al remitente del informe de fallo
ni a <code>debian-bugs-dist</code>;
</li>
<li>
<var>nnn</var><code>-quiet@bugs.debian.org</code> â?? estos mensajes sólo se archivan en el
sistema de seguimiento de fallos (como todos los anteriores),
<strong>no</strong> se envÃan a nadie más.
</li>
</ul>
<p>Para más información sobre los encabezados para suprimir los mensajes ACK
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 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 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:
<dl>
<dt><code>critical</code></dt>
<dd>hace que software no relacionado entre sà en el sistema (o el sistema
entero) falle, o cause serias pérdidas de datos, o introduzca un agujero
de seguridad en el sistema donde se instale el paquete.</dd>
<dt><code>grave</code></dt>
<dd>hace que el paquete en cuestión no se pueda utilizar o no se pueda casi nunca,
o cause pérdida de datos, o introduce un agujero de seguridad que permita el acceso a
las cuentas de los usuarios que usen el paquete.</dd>
<dt><code>serious</code></dt>
<dd>es una <a href="$(DOC)/debian-policy/">violación
severa de la polÃtica de Debian</a> (en pocas palabras, viola una directiva
<q>debe</q> (must) o <q>requerida</q> (required)) o, en opinión del responsable
del paquete o del responsable de la publicación de una versión de debian, hace
que el paquete no se pueda publicar.</dd>
<dt><code>important</code></dt>
<dd>un fallo que tiene un efecto importante en la usabilidad de un paquete,
sin hacerle completamente inútil para todo el mundo.</dd>
<dt><code>normal</code></dt>
<dd>el valor por omisión, aplicable a la mayorÃa de los fallos.</dd>
<dt><code>minor</code></dt>
<dd>un problema que no afecta a la utilidad del paquete, y presumiblemente es
trivial de arreglar.</dd>
<dt><code>wishlist</code></dt>
<dd>para la petición de cualquier caracterÃstica, y también para cualquier
fallo que sea muy difÃcil de arreglar debido a consideraciones de diseño
mayores.</dd></dl>
<p>Ciertas severidades se consideran
<em><a href="https://bugs.debian.org/release-critical/";><q>release-critical</q></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="https://release.debian.org/testing/rc_policy.txt";>asuntos de
publicación-crÃticos para la próxima versión</a>.</p>
<h2><a name="tags">Etiquetas para informes de fallos</a></h2>
<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>
<p>Las etiquetas se pueden establecer poniendo una lÃnea <code>Tags</code>
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>
<p>Las actuales etiquetas para fallos son: <bts_tags>. Aquà tiene información
detallada sobre las etiquetas:</p>
<dl>
<dt><code>patch</code></dt>
<dd>Un parche o cualquier otro procedimiento fácil para arreglarlo se
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.</dd>
<dt><code>wontfix</code></dt>
<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.</dd>
<dt><code>moreinfo</code></dt>
<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
fallos como <q>No funciona</q>. ¿Qué no funciona?</dd>
<dt><code>unreproducible</code></dt>
<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.</dd>
<dt><code>help</code></dt>
<dd>El responsable está pidiendo ayuda para tratar este fallo.
O bien el responsable no tiene los conocimientos necesarios para arreglar este fallo
y desea colaboración, o está sobrecargado y quiere delegar esta tarea. Este fallo puede
no ser adecuado para nuevos contribuidores, a no ser que también esté etiquetado
con la etiqueta<code>newcomer</code>.</dd>
<dt><code>newcomer</code></dt>
<dd>Este fallo tiene una solución conocida, pero el responsable pide que alguien
la implemente. Es una tarea ideal para nuevos contribuidores que desean implicarse
en Debian, o que quieren mejorar sus habilidades.</dd>
<dt><code>pending</code></dt>
<dd>Se ha encontrado una solución a este fallo y se enviará pronto.</dd>
<dt><code>fixed</code></dt>
<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 <q>fixed</q>.</dd>
<dt><code>security</code></dt>
<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 <q>buffer</q> 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 fallos de seguridad también se deberÃan establecer en
severidad <q>critical</q> o <q>grave</q>.</dd>
<dt><code>upstream</code></dt>
<dd>Este error se aplica a la parte del paquete proporcionada por el desarrollador del programa.</dd>
<dt><code>confirmed</code></dt>
<dd>El responsable ha mirado, entiende, y básicamente está de acuerdo con
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 fallos abiertos.)</dd>
<dt><code>fixed-upstream</code></dt>
<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).</dd>
<dt><code>fixed-in-experimental</code></dt>
<dd>El fallo ha sido arreglado en el paquete de la distribución experimental,
pero todavÃa no en la distribución inestable.</dd>
<dt><code>d-i</code></dt>
<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.</dd>
<dt><code>ipv6</code></dt>
<dd>Este fallo afecta al soporte de la versión 6 del Protocolo de Internet.</dd>
<dt><code>lfs</code></dt>
<dd>Este fallo afecta al soporte para archivos grandes (más de 2 gigabytes).</dd>
<dt><code>l10n</code></dt>
<dd>Este fallo es relevante para la localización del paquete.</dd>
<dt><code>a11y</code></dt>
<dd>Este fallo es relevante para la accesibilidad del paquete.</dd>
<dt><code>ftbfs</code></dt>
<dd>El paquete falla en su compilación desde fuentes. Si el fallo se asigna a
un paquete de fuentes, ese paquete falla al compilar. Si el fallo se asigna a
un paquete binario, los paquetes fuentes afectados fallan al compilar. La
etiqueta se aplica a entornos de compilación no estándares (por ej. usando
«Build-Depends» de experimental), pero la severidad deberÃa estar por debajo
de <q>serious</q> (<q>release critical</q>) en tales casos.</dd>
<dt><bts_release_tags></dt>
<dd>Estas son etiquetas de distribución, que tienen dos efectos. Cuando se
establece en un fallo, el fallo sólo puede afectar a esa distribución en particular
(aunque también
puede afectar a otras distribuciones si se establecen otras etiquetas) pero,
por lo demás, se aplican las reglas normales de error/arreglado/ausente. Este
fallo no se deberÃa archivar hasta que esté arreglado en esa distribución.</dd>
<dt><bts_release_ignore_tags></dt>
<dd>Este fallo <q>release-critical</q> se va a ignorar para los propósitos de
publicación de esa distribución. <strong>Esta etiqueta solo la deberÃan usar los
gestores de publicación; no la ponga usted mismo sin su autorización
explÃcita.</strong></dd>
</dl>
<p>
Información sobre las etiquetas especÃficas de distribución:
las etiquetas <q>-ignore</q>
ignoran el fallo para el propósito de una propagación a <q>testing</q>. Las
etiquetas <q>release</q> indican que el fallo sólo deberÃa considerarse
válido para un conjunto de publicaciones especÃfica. En otras palabras: el
fallo <strong>no está presente</strong> en ninguna de las publicaciones
para las que la etiqueta <q>release</q> <strong>no</strong> está fijada;
sino las reglas normales de fallos arreglados y encontrados aplican.
</p>
<p>
Las etiquetas de <q>release</q> <strong>no</strong> deberÃan
utilizarse si un versionado corercto del fallo consigue el mismo efecto.
Es preferible utilizar versionados dado que las etiquetas han de
añadirse y eliminarse manualmente. Contacte los administradores del
BTS de Debian (<email "owner@bugs.debian.org">) o el grupo de publicación
si necesita ayuda en caso de que no esté seguro si necesita o no
una etiqueta de <q>release</q>.
</p>
<h2><a name="forward">Registrar que ha aprobado un informe de fallo</a></h2>
<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 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> 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 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 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 fallo no se ha marcado ya como reenviado.</p>
<p>También puede manipular la información <q>reenviado a</q> enviando mensajes a
<a href="server-control"><code>control@bugs.debian.org</code></a>.</p>
<h2><a name="owner">Cambiar la propiedad de un fallo</a></h2>
<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 fallos. Para ayudar a esto, cada fallo puede opcionalmente
tener un propietario.</p>
<p>Se puede establecer el propietario incluyendo una lÃnea <code>Owner</code>
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>.</p>
<h2><a name="maintincorrect">Responsables de paquetes mal mostrados</a></h2>
<p>Si no es correcto el responsable de un paquete que se muestra,
normalmente es porque ha cambiado hace poco, y el nuevo responsable no ha
enviado una nueva versión todavÃa con el campo <code>Maintainer</code> de
control del archivo cambiado. Se arreglará cuando se envÃe el paquete;
alternativamente, los responsables del repositorio pueden reescribir el registro
responsable de un paquete manualmente, por ejemplo si no se espera que se
haga pronto una reconstrucción y reenvÃo del paquete.
Contacte con <code>override-change@debian.org</code> para cambios de
reescritura en el archivo.</p>
<h2><a name="requestserv">Reabrir, reasignar y manipular fallos</a></h2>
<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 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
en otro documento disponible en Internet o en el archivo
<code>bug-maint-mailcontrol.txt</code>. Se puede obtener una versión en
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 fallos</a></h2>
<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 fallo, sin tener que suscribirse a un paquete a través del
<a href="https://tracker.debian.org";>
sistema de seguimiento de paquetes de Debian («Debian Package Tracker»)</a>.
Todos los mensajes recibidos en <var>nnn</var><code>@bugs.debian.org</code>,
se enviarán a los suscriptores.</p>
<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 fallo.</p>
<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 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 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 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>.
En ambos casos, el asunto y cuerpo del correo se reenviará a la dirección de
correo con la petición de confirmación.</p>
<h2><a name="subjectscan">CaracterÃstica de escaneo de asunto más
o menos obsoleta</a></h2>
<p>Los mensajes que lleguen a <code>submit</code> o <code>bugs</code> cuyo
<code>Asunto</code> comience con <code>Bug#</code><var>nnn</var> se tratarán como si se
hubiesen enviado a <var>nnn</var><code>@bugs.debian.org</code>. Esto es
tanto por compatibilidad con correo reenviado desde las direcciones antiguas
como para recoger los correos enviados a <code>submit</code> por error
(por ejemplo, usando <q>Responder a todos</q>).</p>
<p>Funcionan de forma similar <code>maintonly</code>,
<code>done</code>, <code>quiet</code> y <code>forwarded</code>,
que tratan el correo que llegue con una etiqueta Asunto como si se
hubiese enviado a la correspondiente dirección
<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 fallo en la dirección, y sin un
número de fallo en el Asunto se almacenarán en el buzón de <q>basura</q> 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 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>
<p>Ahora se ignora esta lÃnea. En su lugar, envÃe su mensaje a
<code>quiet</code> o <var>nnn</var><code>-quiet</code> (o
<code>maintonly</code> o <var>nnn</var><code>-maintonly</code>).</p>
<hr />
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
diff --git a/spanish/Bugs/Developer.wml b/spanish/Bugs/Developer.wml
index fa4397d25e1..2fcb6306e8b 100644
--- a/spanish/Bugs/Developer.wml
+++ b/spanish/Bugs/Developer.wml
@@ -1,6 +1,6 @@
#use wml::debian::template title="Debian BTS — información para desarrolladores" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
-#use wml::debian::translation-check translation="33ca549a7a4f5f50ef26749a5882613fb0715a03" maintainer="Laura Arjona Reina"
+#use wml::debian::translation-check translation="859f960fa633147bac5504a51b2e29800627217a" maintainer="Laura Arjona Reina"
<h1>Información sobre el sistema de seguimiento de fallos para desarrolladores
y personas que tratan fallos</h1>
@@ -276,6 +276,14 @@ en Debian, o que quieren mejorar sus habilidades.</dd>
<dt><code>a11y</code></dt>
<dd>Este fallo es relevante para la accesibilidad del paquete.</dd>
+<dt><code>ftbfs</code></dt>
+ <dd>El paquete falla en su compilación desde fuentes. Si el fallo se asigna a
+ un paquete de fuentes, ese paquete falla al compilar. Si el fallo se asigna a
+ un paquete binario, los paquetes fuentes afectados fallan al compilar. La
+ etiqueta se aplica a entornos de compilación no estándares (por ej. usando
+ «Build-Depends» de experimental), pero la severidad deberÃa estar por debajo
+ de <q>serious</q> (<q>release critical</q>) en tales casos.</dd>
+
<dt><bts_release_tags></dt>
<dd>Estas son etiquetas de distribución, que tienen dos efectos. Cuando se
@@ -391,8 +399,9 @@ servidor de más arriba.</p>
<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 fallo, sin tener que suscribirse a un paquete a través del <a href="https://packages.qa.debian.org";>PTS
-(Package Tracking System, Sistema de seguimiento de paquetes)</a>.
+ojo en un fallo, sin tener que suscribirse a un paquete a través del
+<a href="https://tracker.debian.org";>
+sistema de seguimiento de paquetes de Debian («Debian Package Tracker»)</a>.
Todos los mensajes recibidos en <var>nnn</var><code>@bugs.debian.org</code>,
se enviarán a los suscriptores.</p>
Reply to: