Nota: La página original es más nueva que esta traducción.

Información sobre el sistema de seguimiento de fallos para desarrolladores y personas que tratan fallos

Inicialmente, un usuario remite un informe de fallo como un mensaje de correo a [email protected] que debe incluir una línea Package (vea cómo informar de un fallo para más detalles). Entonces se le asigna un número, se confirma al usuario, y se reenvía a debian-bugs-dist. Si el remitente incluyó una línea Package listando un paquete con responsable conocido, al responsable también le llegará una copia.

La línea Asunto contendrá añadido Bug#nnn:, y el Reply-To estará hecho para incluir al remitente del informe y nnn@bugs.debian.org.

Cerrar informes de fallos

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.

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. Un fallo también puede ser cerrado por cualquier colaborador si el fallo es para un paquete huerfano o si el responsable de un paquete ha olvidado cerrarlo. Es muy importante mencionar la versión en la que el fallo ha sido solucionado. Cuando dude, no cierre fallos, primero pregunte en la lista de correo debian-devel.

Los informes de fallo se deberían cerrar enviando un correo a nnn[email protected]. El cuerpo del mensaje tiene que contener una explicación de cómo se arregló el fallo.

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 Para: o A: para que diga nnn[email protected] en lugar de nnn@bugs.debian.org (nnn-close se utiliza como un alias para nnn-done).

Cuando sea posible, por favor, agregue una línea Version en la pseudocabecera de su mensaje, al cerrar un fallo, para que el sistema de seguimiento de fallos sepa qué versión del paquete contiene el arreglo.

La persona que cierre el fallo, la que lo remitió y la lista de correo debian-bugs-closed 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 nnn-done.

Mensajes de respuesta

El sistema de seguimiento de fallos incluirá la dirección del remitente y la dirección del fallo (nnn@bugs.debian.org) en el encabezado Reply-To tras reenviar el informe de fallo. Por favor, dése cuenta de que son dos direcciones distintas.

Cualquier desarrollador que desee contestar a un informe de fallo simplemente debería contestar al mensaje, respetando el encabezado Reply-To. Esto no cerrará el fallo.

No use las capacidades responder a todos los buzones o responder de su gestor de correo a menos que pretenda editar los buzones sustancialmente. En concreto, mire que no envía mensajes de respuesta a [email protected].

Para comunicarse con el sistema de seguimiento de fallos, se pueden enviar mensajes a las siguientes direcciones:

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 instrucciones para informar de fallos.

Niveles de severidad

El sistema de seguimiento de fallos registra un nivel de severidad con cada informe de fallo. Este se establece como normal por omisión, pero se puede corregir incluyendo una línea Severity en el pseudo-encabezado cuando se remite el fallo (mire las instrucciones para informar de fallos), o usando la orden severity en el servidor de peticiones de control.

Los niveles de severidad son:

critical
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.
grave
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.
serious
es una violación severa de la política de Debian (en pocas palabras, viola una directiva debe (must) o requerida (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.
important
un fallo que tiene un efecto importante en la usabilidad de un paquete, sin hacerle completamente inútil para todo el mundo.
normal
el valor por omisión, aplicable a la mayoría de los fallos.
minor
un problema que no afecta a la utilidad del paquete, y presumiblemente es trivial de arreglar.
wishlist
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.

Ciertas severidades se consideran release-critical, que significa que el fallo tendrá un impacto en la publicación del paquete con la versión estable de Debian. Actualmente, estos son critical, grave y serious. Para obtener unas reglas completas y canónicas sobre qué asuntos merecen estas severidades, mire la lista de asuntos de publicación-críticos para la próxima versión.

Etiquetas para informes de fallos

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.

Las etiquetas se pueden establecer poniendo una línea Tags en el pseudoencabezado cuando se remite el fallo (mire las instrucciones para informar de fallos), o usando el comando tags en el servidor de peticiones de control. Separe varias etiquetas con comas, espacios, o ambos.

Las actuales etiquetas para fallos son: patch, wontfix, moreinfo, unreproducible, help, security, upstream, pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs, fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore . Aquí tiene información detallada sobre las etiquetas:

patch
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.
wontfix
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.
moreinfo
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 No funciona. ¿Qué no funciona?
unreproducible
Este fallo no puede ser reproducido en el sistema del responsable. Se necesita la asistencia de terceras partes para diagnosticar las causa del problema.
help
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 etiquetanewcomer.
newcomer
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.
pending
Se ha encontrado una solución a este fallo y se enviará pronto.
fixed
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.
security
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 fallos de seguridad también se deberían establecer en severidad critical o grave.
upstream
Este error se aplica a la parte del paquete proporcionada por el desarrollador del programa.
confirmed
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.)
fixed-upstream
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).
fixed-in-experimental
El fallo ha sido arreglado en el paquete de la distribución experimental, pero todavía no en la distribución inestable.
d-i
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.
ipv6
Este fallo afecta al soporte de la versión 6 del Protocolo de Internet.
lfs
Este fallo afecta al soporte para archivos grandes (más de 2 gigabytes).
l10n
Este fallo es relevante para la localización del paquete.
a11y
Este fallo afecta a la accesibilidad de personas con discapacidad. Tiene impacto particular en la usabilidad para personas que se apoyan en tecnologías de asistencia y otras adaptaciones para usar el sistema o el paquete.
ftbfs
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 serious (release critical) en tales casos.
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
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.
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore
Este fallo release-critical se va a ignorar para los propósitos de publicación de esa distribución. Esta etiqueta solo la deberían usar los gestores de publicación; no la ponga usted mismo sin su autorización explícita.

Información sobre las etiquetas específicas de distribución: las etiquetas -ignore ignoran el fallo para el propósito de una propagación a testing. Las etiquetas release indican que el fallo sólo debería considerarse válido para un conjunto de publicaciones específica. En otras palabras: el fallo no está presente en ninguna de las publicaciones para las que la etiqueta release no está fijada; sino las reglas normales de fallos arreglados y encontrados aplican.

Las etiquetas de release no 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 protected]) o el grupo de publicación si necesita ayuda en caso de que no esté seguro si necesita o no una etiqueta de release.

Registrar que ha aprobado un informe de fallo

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:

Asegúrese de que el campo To de su mensaje al autor tiene solo la/s dirección/es de el/los autor/es; ponga en el campo CC la persona que informó del fallo, nnn[email protected] y nnn@bugs.debian.org.

Pregunte al autor si conservar el CC a nnn[email protected] 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 nnn@bugs.debian.org.

Cuando el sistema de seguimiento de fallos reciba un mensaje en nnn-forwarded marcará el fallo como que ha sido reenviado a la(s) dirección(es) en el campo To del mensaje recibido, si el fallo no se ha marcado ya como reenviado.

También puede manipular la información reenviado a enviando mensajes a [email protected].

Cambiar la propiedad de un fallo

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.

Se puede establecer el propietario incluyendo una línea Owner en el pseudo-encabezado cuando se remita el fallo (mire las instrucciones para informar de fallos), o usando los comandos owner y noowner en el servidor de peticiones de control.

Responsables de paquetes mal mostrados

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 Maintainer 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 [email protected] para cambios de reescritura en el archivo.

Reabrir, reasignar y manipular fallos

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 [email protected].

El formato de estos mensajes se describe en otro documento disponible en Internet o en el archivo bug-maint-mailcontrol.txt. Se puede obtener una versión en texto sin formato enviando la palabra help a la dirección del servidor de más arriba.

Suscribirse a fallos

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 sistema de seguimiento de paquetes de Debian («Debian Package Tracker»). Todos los mensajes recibidos en nnn@bugs.debian.org, se enviarán a los suscriptores.

Se puede suscribir a un fallo enviando un correo a nnn[email protected]. 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.

También es posible darse de baja de un fallo. Se puede dar de baja enviando un correo a nnn[email protected]. 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.

Por omisión, la dirección que se da baja es la que se encuentre en el encabezado From. 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: nnn-subscribe-correoespecial=ejemplo.com@bugs.debian.org. Este ejemplo enviaría a [email protected] un mensaje de suscripción para el fallo nnn. El signo @ se debe codificar cambiándolo por un signo =. De forma similar, darse de baja toma la forma nnn-unsubscribe-correoespecial=ejemplo.com@bugs.debian.org. En ambos casos, el asunto y cuerpo del correo se reenviará a la dirección de correo con la petición de confirmación.

Característica de escaneo de asunto más o menos obsoleta

Los mensajes que lleguen a submit o bugs cuyo Asunto comience con Bug#nnn se tratarán como si se hubiesen enviado a nnn@bugs.debian.org. Esto es tanto por compatibilidad con correo reenviado desde las direcciones antiguas como para recoger los correos enviados a submit por error (por ejemplo, usando Responder a todos).

Funcionan de forma similar maintonly, done, quiet y forwarded, que tratan el correo que llegue con una etiqueta Asunto como si se hubiese enviado a la correspondiente dirección nnn-loquesea@bugs.debian.org.

Los mensajes que lleguen sin mayores indicaciones a forwarded y done, 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.

Característica obsoleta X-Debian-PR: quiet

Solía poderse evitar que el sistema de seguimiento de fallos reenviase a debian-bugs los mensajes que recibía, poniendo una línea X-Debian-PR: quiet en la cabecera real del correo.

Ahora se ignora esta línea. En su lugar, envíe su mensaje a quiet o nnn-quiet (o maintonly o nnn-maintonly).

Otras páginas del sistema de seguimiento de fallos (BTS en inglés):

Debian BTS administrators <[email protected]>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.