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 submit@bugs.debian.org
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 fallo
- Mensajes de respuesta
- Niveles de severidad
- Etiquetas para informes de fallos
- Registrar que ha aprobado un informe de fallo
- Cambiar la propiedad del fallo
- Responsables de paquetes mal mostrados
- Reabrir, reasignar y manipular fallos
- Suscribirse a fallos
- Característica de escaneo de asunto más o menos obsoleto
- Característica obsoleta
X-Debian-PR: quiet
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-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.
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
submit@bugs.debian.org
.
Para comunicarse con el sistema de seguimiento de fallos, se pueden enviar mensajes a las siguientes direcciones:
-
nnn
@bugs.debian.org
— estos mensajes también se envían al mantenedor del paquete y se reenvían adebian-bugs-dist
, pero no al remitente del informe de fallo; -
nnn
-submitter@bugs.debian.org
— estos mensajes también se envían al remitente del informe de fallo y se reenvían adebian-bugs-dist
, pero no al mantenedor del paquete; -
nnn
-maintonly@bugs.debian.org
— estos mensajes se envían sólo al mantenedor del paquete, no al remitente del informe de fallo ni adebian-bugs-dist
; -
nnn
-quiet@bugs.debian.org
— estos mensajes sólo se archivan en el sistema de seguimiento de fallos (como todos los anteriores), no se envían a nadie más.
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) orequerida
(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 etiqueta
newcomer
. 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 severidadcritical
ograve
. 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 (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 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-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
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-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):
- Página principal del sistema de seguimiento de fallos de Debian.
- Instrucciones sobre cómo informar de un fallo.
- Acceso a los registros del sistema de seguimiento de fallos.
- Información para desarrolladores sobre el sistema de seguimiento de fallos.
- Información para desarrolladores sobre cómo manipular fallos utilizando la interfaz de correo electrónico.
- Tarjeta de referencia de los servidores de correo.
- Cómo pedir informes de fallos por correo electrónico.
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.