Cómo enviar un informe sobre un problema

Informes de problemas en versiones estables.

1. Comprobar y verificar si existen parches y avisos correspondientes a la versión.
2. A continuación comprobar si hay una versión más nueva disponible.
3. Finalmente, comprobar los cambios entre las versiones de OpenBSD.

Si nada de lo que ve soluciona el problema, por favor lea detenidamente la página de manual de sendbug(1) antes de enviar un informe de error.

Busque más abajo los tipos de informes de errores que existen.

Informe de problemas en la versión de desarrollo (-current).

1. Verifique el problema dos veces como mínimo, con los fuentes actualizados con una diferencia de un par de días.
2. No envíe informes sobre problemas de compilación del árbol de fuentes, a menos que éstos sean persistentes. La mayoría de las veces se deben a fallos del usuario, o están siendo solucionados en ese momento. Las personas que trabajan en el proyecto ejecutan un make build un mínimo de una vez al día, y por lo general varias veces al día con diferentes arquitecturas.
3. Recuerde que los servidores de anoncvs se actualizan con una demora significante sobre el árbol de fuentes principal sobre el que se aplican los cambios.
4. Compruebe los cambios realizados entre versiones de OpenBSD para ver si el problema ha sido solucionado.
5. Se pone mucho cuidado al crear las versiones preliminares (snapshots). Algunas veces se cometen errores, y por ello pedimos disculpas. Leer y enviar mensajes a las listas de correo es mejor que enviar un informe de error.

Cómo crear un informe sobre un problema

Envíe siempre tanta información como le sea posible. Trate de puntualizar sobre el problema exacto. No divague ni dé detalles sobre problemas nimios como «se cuelga» o «me da interrupciones raras en esta máquina que he montado...». Hable con otros usuarios en los canales de IRC o en algún otro foro para verificar que sea un problema nuevo, repetido, etc... y asegúrese de que no es un problema de su sistema.

Por favor, no empiece a solucionar problemas que requieren de un trabajo laborioso hasta que no esté seguro de que lo haya entendido bien, especialmente durante nuestros periodos previos al lanzamiento en los que no debemos cambiar ninguna parte importante del código. Si va a escribir una cantidad considerable de código, entérese en varios foros si alguien más está trabajando en ese problema (evitando un doble esfuerzo).

Los siguientes elementos de información se deberían incluir en todos los informes de errores:

1. Los pasos exactos que se han seguido desde el principio para poder reproducir el problema. No es suficiente con enviar una simple orden sin los argumentos ni otros datos que se hayan usado. Si un error requiere una secuencia concreta de sucesos, por favor envíe una lista de éstos. Al mismo tiempo también debería minimizar el tamaño de su ejemplo, pero esto no es absolutamente necesario. Si se puede reproducir el error, lo encontraremos de cualquier modo.

2. La salida en pantalla que obtuvo. Por favor, no se limite a decir que «no ha funcionado» o que «ha fallado». Si hay algún mensaje de error, envíelo, aunque no entienda lo que dice. Si se provoca un «pánico» en el sistema por un error en concreto, diga cuál. Si nada de esto ocurre, dígalo. Aun cuando el resultado obvio de su comprobación sea la caída de un programa, es posible que no ocurra en su caso. La forma más fácil es copiar la salida en pantalla del error siempre que sea posible.

   Nota: En caso de errores fatales, el mensaje de error que vea es probable que no contenga toda la información disponible. En ese caso también debe mirar en la salida que aparece en los ficheros de mensaje del sistema (ficheros log), como los que encontrará en /var/log. Si la aplicación tiene sus propios ficheros de mensaje, como en el caso de httpd, compruebe los errores en el lugar en donde guarde estos ficheros (en el caso concreto de httpd este sitio es /var/www/logs).

3. La salida del núcleo de OpenBSD. Ésta se obtiene con la orden 'dmesg', pero es posible que la salida que ofrezca 'dmesg' no contenga toda la información que haya sido capturada en /var/run/dmesg.boot. Compárelo, y en caso de existir diferencias envíe la información de ambos. Por favor, incluya esto en todos los informes sobre errores.

4. Si se está ejecutando software de terceros que tenga algo que ver con el error, dígalo e incluya cualquier sub-versión que pueda tener dicho software. Si se trata de alguna versión preliminar (snapshot) obtenida por CVS o FTP, dígalo e incluya su fecha y hora.

5. Un informe de ´traceback´ con el pánico del núcleo. Si fue un pánico en el núcleo y se encuentra en el punto de inserción de ddb>, por favor envíe el mensaje de pánico, así como la salida de las órdenes trace y ps junto con el informe sobre el error.
   Si, por algún motivo, el mensaje de pánico no fuera visible, puede volverlo a obtener con la orden x/s *panicstr.
   Esto es esencial siempre que sea posible. Los informes sobre pánicos sin un mensaje del pánico, y sin una salida de traceback y ps, son inútiles.
   La salida de la orden show registers también puede ser de interés. Después de esto puede reiniciar con la orden boot dump, y de este modo savecore(8) guardará una imagen del núcleo para un depurado post-mortem.

Si se envía un informe sobre un problema relacionado con el sistema gráfico X window system en una arquitectura que utilice el servidor XFree86, hay que incluir el fichero completo /var/log/XFree86.0.log en el informe además de la información de dmesg.boot.

No se preocupe si el informe es demasiado largo. Son cosas de la vida. Es mejor informar sobre todo la primera vez a que le tengamos que ir sonsacando los datos. Por otra parte, si los ficheros que adjunte son enormes, lo justo sería que preguntara antes si hay alguien interesado en investigarlo.

Para terminar, cuando escriba un informe, asegúrese de escoger una terminología que no se preste a confusiones.

Envío de informes sobre errores

Si es posible, use la orden sendbug(1) para incluir el error a nuestro sistema de seguimiento de errores. Puede seguir el desarrollo del sistema de seguimiento desde esta página. Sendbug requiere que su sistema sea capaz de enviar correctamente correo por Internet. Si no puede usar sendbug en una máquina funcional de OpenBSD, por favor envíe su informe a bugs@openbsd.org. Es posible que lo que envíe sea la petición de una funcionalidad, y no necesariamente un error.

Aceptamos las sugerencias para añadir nuevas funcionalidades, especialmente si van acompañadas de código que implementen sus sugerencias. Si alguien más programa el código para su sugerencia, es posible que sea confuso y que no lo pueda reconocer.

Para depurar algunos problemas debemos tener el hardware que tiene el problema. Por favor, recuerde que los recursos del proyecto OpenBSD son limitados. Puede hacer donativos de hardware.

Tipos de informes de errores según su importancia:

1. Los mejores son problemas repetidos acompañados de soluciones para el código fuente.
2. Problemas repetidos que no sean específicos de la configuración de su hardware o software.
3. Problemas repetidos específicos de la configuración de su software.
4. Problemas repetidos específicos de la configuración de su hardware.
5. Problemas no repetidos.

---

www@openbsd.org
Originally [OpenBSD: report.html,v 1.24 2003/06/10 22:32:47 tedu Exp ]
$Translation: report.html,v 1.27 2009/05/26 22:53:52 ajacoutot Exp $
$OpenBSD: report.html,v 1.21 2009/05/26 21:30:39 ajacoutot Exp $