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

Información para desarrolladores sobre el sistema de seguimiento de fallos

Inicialmente, un usuario remite un informe de fallo como un mensaje de correo a submit@bugs.debian.org. 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. 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-done@bugs.debian.org. 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-done@bugs.debian.org 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.

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

El sistema de seguimiento de fallos recibirá los mensajes en nnn@bugs.debian.org, lo pasará al responsable del paquete, almacenará la respuesta con el resto de registros para ese informe y lo reenviará a debian-bugs-dist.

Enviando un mensaje a nnn-submitter@bugs.debian.org 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.

Si desea enviar un mensaje de respuesta que no es apropiado para debian-bugs-dist puede hacerlo enviándolo a nnn-quiet@bugs.debian.org o nnn-maintonly@bugs.debian.org. EL correo enviado a nnn-quiet@bugs.debian.org se almacena en el sistema de seguimiento de fallos pero no se envía a particulares o listas de correo. El correo enviado a nnn-maintonly@bugs.debian.org se almacena en el sistema de seguimiento de fallos y se entrega sólo al responsable del paquete en cuestión.

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 submit@bugs.debian.org.

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 gestor de publicación, 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 Lenny.

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
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.
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.
potato
Este fallo afecta particularmente a la publicación potato de Debian.
woody
Este fallo afecta particularmente a la publicación woody de Debian.
sarge
Esta es una etiqueta de distribución, que tiene dos efectos. Cuando se establece en un fallo, el fallo sólo puede afectar a sarge (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 sarge.
sarge-ignore
Este fallo release-critical se va a ignorar para los propósitos de publicación de sarge. Esta etiqueta solo la deberían usar los gestores de publicación; no la ponga usted mismo sin autorización explícita de ellos.
etch
Esta es una etiqueta de distribución, que tiene dos efectos. Cuando se establece en un fallo, el fallo sólo puede afectar a sarge (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 etch.
etch-ignore
Este fallo release-critical se va a ignorar para los propósitos de publicación de etch. Esta etiqueta solo la deberían usar los gestores de publicación; no la ponga usted mismo sin autorización explícita de ellos.
lenny
Esta es una etiqueta de distribución, que tiene dos efectos. Cuando se establece en un fallo, el fallo sólo puede afectar a sarge (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 lenny.
lenny-ignore
Este fallo crítico para la publicación se va a ignorar para los propósitos de publicación de lenny. Esta etiqueta sólo la debería/n usar el/los gestor/es de publicación. No establezca esta etiqueta sin su autorización explícita.
squeeze
Esta es una etiqueta de distribución, que tiene dos efectos. Cuando se establece en un fallo, el fallo sólo puede afectar a sarge (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 squeeze.
lenny-ignore
Este fallo crítico para la publicación se va a ignorar para los propósitos de publicación de lenny. Esta etiqueta sólo la debería/n usar el/los gestor/es de publicación. No establezca esta etiqueta sin su autorización explícita.
sid
Esta es una etiqueta de distribución, que tiene dos efectos. Cuando se establece en un fallo, el fallo sólo puede afectar a sarge (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 sid.
experimental
Esta es una etiqueta de distribución, que tiene dos efectos. Cuando se establece en un fallo, el fallo sólo puede afectar a sarge (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 experimental.

El significado de las últimas ocho 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 sólo para indicar qué fallos afectaban a una publicación específica, ahora indican cuando se puede archivar un fallo y el conjunto de publicaciones para las que el fallo se puede considerar encontrado o arreglado.

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-forwarded@bugs.debian.org y nnn@bugs.debian.org.

Pregunte al autor si conservar el CC a nnn-forwarded@bugs.debian.org 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 control@bugs.debian.org.

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 override-change@debian.org 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 control@bugs.debian.org.

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 PTS (Package Tracking System, Sistema de seguimiento de paquetes). 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-subscribe@bugs.debian.org. 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-unsubscribe@bugs.debian.org. 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 correoespecial@ejemplo.com 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 <owner@bugs.debian.org>

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