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 conocimiento 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 programa 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/cvsweb.cgi/src/UPDATING. (Esta información se considera de vital importancia si se está actualizando de una versió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 FreeBSD, 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/cvsweb.cgi/ports/UPDATING y http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES también se encuentran disponibles a través de CVSweb.

A continuación debemos asegurarnos de que el informe de errores llega a las personas adecuadas.

La primera consideración llegados a este punto consiste en: Si el problema resulta ser un bug en un software de terceras partes (un port o un paquete que se ha instalado) se debe informar sobre el bug al autor original del software, no al proyecto FreeBSD. Existen dos excepciones a esta regla: la primera ocurre cuando el bug no se produce en otras plataformas, en cuyo caso el problema puede residir en cómo fue migrado el software a FreeBSD; la segunda excepción ocurre cuando el autor original ya ha corregido el problema y distribuido un parche o una nueva versión de su software, pero el port de FreeBSD todavía no se ha actualizado.

La segunda consideración es que el sistema de seguimiento de bugs de FreeBSD ordena los informes de problemas de acuerdo con la categoría que ha seleccionado el informador. De este modo, si se selecciona una categoría incorrecta cuando se envía el informe de problemas, existe una gran probabilidad de que nadie se de cuenta de su existencia durante un período de tiempo indefinido, hasta que alguien se encarge de re-categorizarlo.