4. Escribir el informe de problemas

Ahora que hemos determinado que el problema que estamos experimentando se merece la redacción de un informe de problemas y que se trata de un problema de FreeBSD, es la hora de comenzar a escribir dicho informe. Antes de pasar a describir los mecanismos utilizados por el programa encargado de generar los informes PR, vamos a describir una serie de trucos y consejos que nos asegurarán la mayor efectividad posible de nuestro informe.

4.1. Consejos y trucos para escribir un buen informe de problemas

4.2. Antes de comenzar.

Antes de ejecutar el programa send-pr(1), asegúrese de que la variable de entorno VISUAL (o EDITOR si la variable VISUAL no se encuentra definida) se encuentra apuntando a algo con sentido.

Es importante comprobar que la entrega de correo funciona correctamente. send-pr(1) utiliza mensajes de correo para enviar y realizar un seguimiento de los informes de problemas. Si no se puede generar correo electrónico desde la máquina en la que se ejecuta send-pr(1), el informe jamás llegará a la base de datos GNATS. Si quiere saber más sobre la configuración del correo en FreeBSD consulte el capítulo de “Correo Electrónico” del manual de FreeBSD en .

4.3. Adjuntar parches o archivos

El programa send-pr(1) posee la capacidad de adjuntar archivos al informe de problemas. Se pueden adjuntar tantos archivos como se quiera siempre y cuando se utilice un nombre distinto para cada archivo (e.g. el nombre del archivo después de eliminar el path). Simplemente basta con utilizar la opción -a de línea de comandos para especificar los nombres de todos los archivos que se desean adjuntar:

% send-pr -a /var/run/dmesg -a /tmp/errors

No se preocupe por los archivos binarios, dichos archivos se codifican automáticamente para no interferir con el agente de correo.

Si se adjunta un parche, asegúrese que se utiliza la opción -c o la opción -u de diff(1) para crear un contexto unificado (el contexto suele ser el preferido por quienes lo han de recibir) y además asegúrese de especificar los números de revisión de CVS de los archivos que se modifican para que los desarrolladores que lean el informe puedan aplicar dichos parches fácilmente. Para problemas relacionados con el kernel o con las utilidades del sistema base, se prefiere un parche contra FreeBSD-CURRENT (la rama HEAD del árbol CVS) ya que cualquier código nuevo debe probar se primeramente en dicha rama. Después de comprobar su correcto funcionamiento de una forma sustancial y extensa, eventualmente dicho código pasará a formar parte de FreeBSD-STABLE, mediante unión o migración.

Si se envía un parte en línea, en vez de como adjunto, tenga en cuenta que el principal problema de esta forma de enviar los parches es que, dependiendo del lector de correo utilizado, algunos lectores muestran los tabuladores como espacios, lo cual arruina completamente el formato y la indentación del parche, e invalida totalmente un parche que forme parte de un Makefile.

También tenga en cuenta que mientras que la inclusión de parches en un PR se considera como algo positivo--particularmente cuando se soluciona el problema que describe el informe--partes grandes y especialmente código nuevo que puede requerir una sustancial revisión antes de ser aplicado debería hacerse accesible a través de otros medios, como páginas web o servidores de ftp, y en vez de incluir el parche en el informe se puede incluir la URL. Los parches de gran tamaño en los correos electrónicos tienden a mezclarse o partirse, especialmente cuando GNATS los trata, y cuanto más grande es el parche más difícil resulta recuperar el original. También existe una ventaja añadida a la inclusión del parche a través de una URL, ya que de este modo se puede modificar el parche sin tener que reenviar el informe como una respuesta al informe inicial.

Se debe prestar atención también al hecho de que, a menos que se especifique explícitamente lo contrario en el PR o en el propio parche, cualquier parche enviado se supone licenciado bajo los mismos términos y condiciones que el archivo original que modifica.

4.4. Rellenar la plantilla

Cuando se ejecuta send-pr(1) se nos presenta en pantalla una plantilla. Esta plantilla consiste en una lista de campos, algunos de los cuales se encuentran ya rellenados, mientras que otros poseen comentarios donde se explica su propósito o se comentan los valores aceptables. No se preocupe por los comentarios, puesto que se borran automáticamente antes de generar el informe.

Al comienzo de la plantilla, justo debajo de las líneas de SEND-PR:, se encuentran las cabeceras de correo electrónico. Dichas cabeceras normalmente no se tienen que modificar, a menos que se esté rellenando el informe desde una máquina que puede enviar correo pero no puede recibirlo directamente, en cuyo caso usted tendrá que editar los campos From: y Reply-To: para escribir la dirección de correo válida. También puede enviarse una copia a usted mismo o a cualquier otra persona rellenando el campo Cc:.

A continuación aparecen una serie de campos de una sola línea:

Por último, existen una serie de campos multilínea:

4.5. Envío del informe de problemas

Una vez que hemos terminado de rellenar la plantilla, hemos salvado y hemos salido del editor, send-pr(1) nos dará a conocer las siguientes opciones: s)end, e)dit or a)bort?. Es en estos momentos cuando podemos teclear s para continuar y enviar el informe de problemas, e para relanzar el editor y realizar más modificaciones a la plantilla o a para abortar el programa. Si se selecciona esta última alternativa, el informe de problemas no será destruido, sino que permanecerá en disco (send-pr(1) nos indicará el nombre del fichero antes de finalizar), de tal forma que se puede editar de forma individual (sin send-pr(1)) en cualquier momento, o también se puede transferir a otro sistema con mejor conectividad para finalmente enviarlo utilizando la opción f de línea de comandos de send-pr(1):

% send-pr -f ~/my-problem-report

Esto leerá el archivo especificado, validando sus contenidos, y eliminará los comentarios para finalmente enviarlo.

Éste y otros documentos pueden obtenerse en ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Para preguntas acerca de FreeBSD, leer la documentación antes de contactar con la lista <questions@FreeBSD.org>.
Para preguntas acerca de esta documentación, e-mail a <doc@FreeBSD.org>.

Hosting by: hurra.com
Generated: 2007-01-26 18:00:30