PDF de programación - Cómo enviar informes de problemas de FreeBSD

Cómo enviar informes de
problemas de FreeBSD

Dag-Erling Smørgrav

Revisión: 43184

FreeBSD is a registered trademark of the FreeBSD Foundation.
CVSup is a registered trademark of John D. Polstra.
IBM, AIX, OS/2, PowerPC, PS/2, S/390, and ThinkPad are trademarks of International Business
Machines Corporation in the United States, other countries, or both.
Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or regis-
tered trademarks of Intel Corporation or its subsidiaries in the United States and other coun-
tries.
Sparc, Sparc64, and UltraSPARC are trademarks of SPARC International, Inc in the United Sta-
tes and other countries. Products bearing SPARC trademarks are based upon architecture de-
veloped by Sun Microsystems, Inc.
Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, Solaris, StarOffi-
ce and SunOS are trademarks or registered trademarks of Sun Microsystems, Inc. in the Uni-
ted States and other countries.
Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in this document, and the FreeBSD
Project was aware of the trademark claim, the designations have been followed by the “™” or
the “®” symbol.

2013-11-13 07:52:45 por hrs.

Resumen
Este artículo describe cómo realizar y enviar informes de errores para el proyecto FreeBSD de
la mejor forma posible.
Traducción de Juan F. Rodriguez <[email protected] >.

Tabla de contenidos
1. Introducción ........................................................................................................................... 1
2. Cuándo enviar informes de problemas .......................................................................................... 2
3. Preparativos ........................................................................................................................... 3
4. Escribir el informe de problemas ................................................................................................. 3
5. Follow-up ............................................................................................................................... 9
6. Lecturas recomendadas ............................................................................................................. 9
Índice ...................................................................................................................................... 10

1. Introducción
Una de las experiencias más fustrantes que se pueden experimentar como usuario de software es aquella en la cual
el usuario se toma la molestia de rellenar un informe de problemas detallado para observar tras un determinado
espacio de tiempo que dicho informe se cierra con una explicación corta y abrupta como “no es un error” o “PR

Cuándo enviar informes de problemas

erroneo”. De forma semejante, una de las experiencias más fustrantes que puede experimentar un desarrollador de
aplicaciones consiste en verse inundado por una cantidad ingente de informes de errores que en realidad vienen a
ser solicitudes de soporte o ayuda, o que contienen poca o ninguna información sobre cúal es el problema y como
se puede reproducir.
Este documento intenta describir cómo escribir informes de problemas de calidad. Usted se preguntará cómo se
pueden escribir informes de problemas de calidad. Bien, para ir directos al grano, un informe de problemas de
calidad es aquél que se puede analizar y tratar rápidamente, para mútua satisfacción del usuario y del desarrollador.
Aunque el objetivo principal de este artículo se centra en los informes de problemas de FreeBSD la mayoría de los
conceptos se pueden aplicar bastante bien en otros proyectos de software.
Dése cuenta de que este artículo se organiza de forma temática, no cronológicamente, de tal forma que se debe
leer el documento íntegro antes de enviar informes de problemas. No debe tratarse como un tutorial del estilo
paso a paso.

2. Cuándo enviar informes de problemas
Existen varios tipos de problemas y no todos ellos se merecen la creación de un informe de problemas. Por supues-
to, nadie es perfecto, y existirán ocasiones en las que estaremos convencidos de haber encontrado un “bug” en un
programa cuando realmente hemos malinterpretado la sintaxis o el funcionamiento de dicho programa, o simple-
mente hemos cometido un error tipográfico en un fichero de configuración (aunque en este último caso podría
tratarse de un indicador de documentación escasa o que la aplicación peca de una gestión de errores defectuosa.
Incluso teniendo estos aspectos en cuenta existen varios casos en los cuales el envío de un informe de problemas
resulta claramente no ser la mejor forma de proceder, ya que dicho envío puede servir para frustrar tanto a quien
envía el informe como a quien desarrolló la aplicación. Por el contrario, también existen casos en los que puede
resultar apropiado enviar un informe de problemas sobre algo más aparte de “bugs”: una mejora o una solucitud
nuevas características, por citar un par de ejemplos.
Así que ?cómo podemos determinar qué constituye un “bug” y qué no? Como regla para principiantes podemos
decir que su problema no es un “bug” si se puede expresar como una pregunta (normalmente del estilo de “?cómo
hago X?” o “?donde puedo encontrar Y?”). No siempre las cosas son blancas o negras, pero la regla de las preguntas
suele cubrir una gran mayoría de casos. Si lo que se quiere es una respuesta a una consulta, se pueden enviar dichas
preguntas a la lista de correo para preguntas generales sobre FreeBSD.
A continuación se muestran algunos casos en los que resulta apropiado enviar un informe de problemas sobre algo
que no se considera un “bug”:
• Solucitudes para mejora de características. Normalmente es una buena idea airear estas propuestas en las listas

de distribución antes de enviar un informe de problemas.

• Notificación de actualizaciones de software que se mantiene externamente (principalmente ports, pero también
componentes del sistema base al cargo de proyectos independientes de FreeBSD, como BIND o diversas utilidades
GNU)

Otro tema es que si el sistema donde se experimentó el “bug” no está medianamente actualizado se debe considerar
muy seriamente su actualización e intentar reproducir el problema en un sistema actualizado antes de emitir el
informe. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un
problema que ya ha resuelto.
Por último, un “bug” que no se puede reproducir difícilmente puede arreglarse. Si el “bug” sólo ocurrió una vez y
no somos capaces de reproducirlo, y parece que no le ocurre a nadie más, es muy probable que ni siquiera los desa-
rrolladores puedan reproducirlo y por lo tanto ni siquiera puedan imaginarse qué es lo que falla. Esto no significa
que el “bug” no haya ocurrido, sino que las probabilidades de que nuestro informe de errores sirva para corregir
un defecto son muy pequeñas. Para complicar más las cosas, a menudo estas clases de errores se producen debido
a fallos en los discos duros o al sobrecalentamiento del procesador: debe intentar siempre descubrir estos fallos,
siempre que sea posible, antes de enviar un PR.

2

Cómo enviar informes de problemas de FreeBSD

3. Preparativos
Una buena regla que se puede seguir consiste en realizar siempre una búsqueda antes de enviar un informe de
problemas. Quizá nuestro problema ya ha sido reportado; quizá se está discutiendo en las listas de distribución o
fue discutido hace poco; incluso es posible que se haya arreglado en versiones más recientes del software. Por lo
tanto, se deben consultar los sitios y fuentes más obvias antes de proceder con el envío del informe de errores.
En FreeBSD esto significa:
• Las Preguntas Más Frecuentes (FAQ) de FreeBSD. Las FAQ intentan proporcionar respuestas para un amplio rango
de dudas, tales como aquellas relacionadas con las compatibilidades hardware, las aplicaciones de usuario y la
configuración del kernel.

• Las listas de correo. Si no está subscrito utilice la búsqueda en los archivos del sitio web de FreeBSD. Si el problema
no se ha discutido con anterioridad en las listas, se puede intentar enviar un mensaje y esperar unos pocos
días para ver si alguien puede aconsejarle adecuadamente sobre algún punto que quizá haya pasado por alto en
relación con el problema.

• Opcionalmente, la web entera—utilice su motor de búsqueda favorito para localizar cualquier referencia a su
problema. Incluso pueden aparecer listas de correo o grupos de noticias de los cuales ni siquiera tuviera cono-
cimiento de su existencia o quizá no consideró apropiado consultarlas al principio.

• A continuación, la búsqueda a través de la base de datos FreeBSD PR (GNATS). A menos que nuestro problema sea
muy reciente o rebuscado, existe un gran número de posibilidades de que ya haya sido informado o reportado.
• Lo más importante, se debería intentar comprobar si la documentación existente en el código fuente del pro-

grama puede resolver el problema.
En el caso de las fuentes del sistema FreeBSD debe estudiarse cuidadosamente el contenido del fichero /
usr/src/UPDATING del sistema o su última versión, que se encuentra en http://www.FreeBSD.org/cgi/cvs-
web.cgi/src/UPDATING. (Esta información se considera de vital importancia si se está actualizando de una ver-
sión a otra, especialmente si la actualización se realiza de la versión estable a la versión FreeBSD-CURRENT).
No obstante, si el problema se encuentra en algo que se instaló como parte de la collección de ports de Free-
BSD, se debe consultar el archivo /usr/ports/UPDATING (para ports individuales) o el archivo /usr/ports/
CHANGES (para cambios que afectan a la colección de ports completa). http://www.FreeBSD.org/cgi/cvs-
web.cgi/ports/UPDATING y http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES también se encuen-
tran disponibles a través de CVSweb.

A continuación deb