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 supuesto, 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 simplemente 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 desarrolladores 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.