#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="40a57e26c62893be7c80d82f1772999f68d51179" maintainer="Laura Arjona Reina"
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
.
X-Debian-PR: quiet
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
.
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:
@bugs.debian.org
— estos mensajes también se envían al
mantenedor del paquete y se reenvían a debian-bugs-dist
,
pero no al remitente del informe de fallo;
-submitter@bugs.debian.org
— estos mensajes también se
envían al remitente del informe de fallo y se reenvían a debian-bugs-dist
,
pero no al mantenedor del paquete;
-maintonly@bugs.debian.org
— estos mensajes se envían sólo
al mantenedor del paquete, no al remitente del informe de fallo
ni a debian-bugs-dist
;
-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.
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
grave
serious
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
normal
minor
wishlist
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.
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
No funciona. ¿Qué no funciona?
unreproducible
help
newcomer
.newcomer
pending
fixed
fixed.
security
bufferpermitiendo 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
criticalo
grave.
upstream
confirmed
fixed-upstream
fixed-in-experimental
d-i
ipv6
lfs
l10n
a11y
ftbfs
serious(
release critical) en tales casos.
release-criticalse 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 (release
.
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
.
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.
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.
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.
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.
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.
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
).