                  Como enviar informes de problemas de FreeBSD

  Dag-Erling Smo/rgrav

   Escrito por  
   Revision: 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 registered trademarks of Intel Corporation or its
   subsidiaries in the United States and other countries.

   Sparc, Sparc64, and UltraSPARC are trademarks of SPARC International, Inc
   in the United States and other countries. Products bearing SPARC
   trademarks are based upon architecture developed by Sun Microsystems, Inc.

   Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM,
   Netra, Solaris, StarOffice and SunOS are trademarks or registered
   trademarks of Sun Microsystems, Inc. in the United 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 "(TM)" or the "(R)"
   symbol.

   2013-11-13 por hrs.
   Resumen

   Este articulo describe como realizar y enviar informes de errores para el
   proyecto FreeBSD de la mejor forma posible.

   Traduccion de Juan F. Rodriguez <jrh@it.uc3m.es>.

   [ Split HTML / Single HTML ]

     ----------------------------------------------------------------------

   Tabla de contenidos

   1. Introduccion

   2. Cuando enviar informes de problemas

   3. Preparativos

   4. Escribir el informe de problemas

   5. Follow-up

   6. Lecturas recomendadas

   Indice

1. Introduccion

   Una de las experiencias mas 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
   explicacion corta y abrupta como "no es un error" o "PR erroneo". De forma
   semejante, una de las experiencias mas 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 informacion
   sobre cual es el problema y como se puede reproducir.

   Este documento intenta describir como escribir informes de problemas de
   calidad. Usted se preguntara como se pueden escribir informes de problemas
   de calidad. Bien, para ir directos al grano, un informe de problemas de
   calidad es aquel que se puede analizar y tratar rapidamente, para mutua
   satisfaccion del usuario y del desarrollador.

   Aunque el objetivo principal de este articulo se centra en los informes de
   problemas de FreeBSD la mayoria de los conceptos se pueden aplicar
   bastante bien en otros proyectos de software.

   Dese cuenta de que este articulo se organiza de forma tematica, no
   cronologicamente, de tal forma que se debe leer el documento integro antes
   de enviar informes de problemas. No debe tratarse como un tutorial del
   estilo paso a paso.

2. Cuando enviar informes de problemas

   Existen varios tipos de problemas y no todos ellos se merecen la creacion
   de un informe de problemas. Por supuesto, nadie es perfecto, y existiran
   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
   tipografico en un fichero de configuracion (aunque en este ultimo caso
   podria tratarse de un indicador de documentacion escasa o que la
   aplicacion peca de una gestion de errores defectuosa. Incluso teniendo
   estos aspectos en cuenta existen varios casos en los cuales el envio de un
   informe de problemas resulta claramente no ser la mejor forma de proceder,
   ya que dicho envio puede servir para frustrar tanto a quien envia el
   informe como a quien desarrollo la aplicacion. Por el contrario, tambien
   existen casos en los que puede resultar apropiado enviar un informe de
   problemas sobre algo mas aparte de "bugs": una mejora o una solucitud
   nuevas caracteristicas, por citar un par de ejemplos.

   Asi que ?como podemos determinar que constituye un "bug" y que 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 "?como 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 mayoria 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 continuacion 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 caracteristicas. Normalmente es una buena
       idea airear estas propuestas en las listas de distribucion antes de
       enviar un informe de problemas.

     * Notificacion de actualizaciones de software que se mantiene
       externamente (principalmente ports, pero tambien 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 experimento el "bug" no esta
   medianamente actualizado se debe considerar muy seriamente su
   actualizacion e intentar reproducir el problema en un sistema actualizado
   antes de emitir el informe. Existen pocas cosas que molesten mas a un
   desarrollador que recibir un informe de problemas sobre un problema que ya
   ha resuelto.

   Por ultimo, un "bug" que no se puede reproducir dificilmente puede
   arreglarse. Si el "bug" solo ocurrio una vez y no somos capaces de
   reproducirlo, y parece que no le ocurre a nadie mas, es muy probable que
   ni siquiera los desarrolladores puedan reproducirlo y por lo tanto ni
   siquiera puedan imaginarse que 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 pequenas. Para complicar
   mas 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.

3. Preparativos

   Una buena regla que se puede seguir consiste en realizar siempre una
   busqueda antes de enviar un informe de problemas. Quiza nuestro problema
   ya ha sido reportado; quiza se esta discutiendo en las listas de
   distribucion o fue discutido hace poco; incluso es posible que se haya
   arreglado en versiones mas recientes del software. Por lo tanto, se deben
   consultar los sitios y fuentes mas obvias antes de proceder con el envio
   del informe de errores. En FreeBSD esto significa:

     * Las Preguntas Mas 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 configuracion del kernel.

     * Las listas de correo. Si no esta subscrito utilice la busqueda 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 dias para ver si alguien puede aconsejarle
       adecuadamente sobre algun punto que quiza haya pasado por alto en
       relacion con el problema.

     * Opcionalmente, la web entera-utilice su motor de busqueda 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 quiza no considero
       apropiado consultarlas al principio.

     * A continuacion, la busqueda a traves de la base de datos FreeBSD PR
       (GNATS). A menos que nuestro problema sea muy reciente o rebuscado,
       existe un gran numero de posibilidades de que ya haya sido informado o
       reportado.

     * Lo mas importante, se deberia intentar comprobar si la documentacion
       existente en el codigo 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 ultima version, que se encuentra en
       http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING. (Esta informacion
       se considera de vital importancia si se esta actualizando de una
       version a otra, especialmente si la actualizacion se realiza de la
       version estable a la version FreeBSD-CURRENT).

       No obstante, si el problema se encuentra en algo que se instalo como
       parte de la colleccion 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 coleccion de ports
       completa). http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING y
       http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES tambien se
       encuentran disponibles a traves de CVSweb.

   A continuacion debemos asegurarnos de que el informe de errores llega a
   las personas adecuadas.

   La primera consideracion 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 como fue migrado el software a FreeBSD;
   la segunda excepcion ocurre cuando el autor original ya ha corregido el
   problema y distribuido un parche o una nueva version de su software, pero
   el port de FreeBSD todavia no se ha actualizado.

   La segunda consideracion es que el sistema de seguimiento de bugs de
   FreeBSD ordena los informes de problemas de acuerdo con la categoria que
   ha seleccionado el informador. De este modo, si se selecciona una
   categoria incorrecta cuando se envia el informe de problemas, existe una
   gran probabilidad de que nadie se de cuenta de su existencia durante un
   periodo de tiempo indefinido, hasta que alguien se encarge de
   re-categorizarlo.

4. Escribir el informe de problemas

   Ahora que hemos determinado que el problema que estamos experimentando se
   merece la redaccion 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 aseguraran la mayor efectividad posible de
   nuestro informe.

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

     * No deje la linea de "Synopsis" vacia. Los PRs se dirigen tanto a una
       lista de correo mundial (donde se utiliza el campo "Synopsis" para
       rellenar la linea Subject: del correo) como a una base de datos
       (GNATS). Cualquier persona que consulte la base de datos por el campo
       sinopsis y encuentre un PR con una linea de Asunto vacia tiende
       simplemente a pasar por alto el informe. Recuerde que un PR permanece
       en la base de datos hasta que alguien se encarga de cerrar el informe;
       un informe anonimo normalmente se perdera para siempre entre el ruido
       y tardara mucho en cerrarse.

     * Evite utilizar una linea de "Synopsis" debil.. No debe suponerse que
       quien lea el PR conoce el contexto adecuado en el que su mensaje tiene
       sentido, asi que cuanta mas informacion se proporcione, mejor que
       mejor. Por ejemplo, ?que parte del sistema se ve afectado por el
       informe?, ?el problema aparece cuando se esta instalando o cuando se
       esta ejecutando?. Para ejemplificar, en lugar de Synopsis: portupgrade
       is broken, se pueden ver las ventajas que proporciona una linea como
       la siguiente: Synopsis: port sysutils/portupgrade produce un coredump
       en -current. (En el caso concreto de los ports, resulta especialmente
       util poseer tanto la categoria como el nombre del port en la linea
       "Synopsis".)

     * Si se dispone de un parche, digalo. Un PR con un parche incluido tiene
       muchas mas posibilidades de ser tratado que uno que no lo tiene. Si se
       include dicho parche, escriba la cadena [patch] al comienzo de la
       linea "Synopsis". (Aunque no es obligatorio utilizar dicha cadena, se
       trata de un estandar de facto que se utiliza de forma mayoritaria.)

     * Si es mantenedor del port, digalo. Si se esta manteniendo el codigo
       fuente de una aplicacion (por ejemplo, de un port), se puede
       considerar la adicion de la cadena [maintainer update] al comienzo de
       la linea de sinopsis, y ademas se deberia asignar el campo "Class" del
       PR a la cadena maintainer-update. De esta forma cualquier committer
       que maneje el PR no tendra que realizar comprobaciones.

     * Sea concreto. Cuanta mas informacion se proporcione sobre el problema
       que se tiene, mas posiblidades de obtener una respuesta.

          * Incluya la version del FreeBSD que se esta ejecutando (existe un
            lugar donde escribir esta esta informacion, vea mas abajo) y en
            que arquitectura. Se debe incluir si se esta ejecutando desde una
            release (e.g. desde un CDROM o descarga), o si es desde un
            sistema mantenido mediante cvsup(1) (y, si esto ultimo se cumple,
            con que frecuencia se realiza la actualizacion). Si se esta
            siguiendo la rama FreeBSD-CURRENT, se trata de la primera
            pregunta que nos haran, debido a que los parches (sobre todo para
            problemas de alto nivel) tienden a aplicarse muy rapidamente, y
            se espera de los usuarios de FreeBSD-CURRENT un seguimiento
            cercano de las actualizaciones aplicadas.

          * Incluya que opciones globales se han especificado en el archivo
            make.conf. Aviso: Es bien conocido por todos que especificar -O2
            y valores superiores para gcc(1) produce fallos y resulta ser
            proclive a errores en muchas situaciones. Aunque los
            desarrolladores de FreeBSD normalmente dan por buenos y aceptan
            los parches proporcionados por el creador del informe de
            problemas, normalmente no desean investigar dichas condiciones
            extranas debido simplemente a la falta de tiempo y de
            voluntarios, y puede que respondan diciendo simplemente que dicha
            opcion de compilacion no se encuentra soportada.

          * Si se trata de un problema del kernel, preparese para
            proporcionar la siguiente informacion. (No es necesario incluir
            esta informacion por defecto, puesto que lo unico que produce es
            un crecimiento desmesurado de la base de datos GNATS, pero si
            puede merecer la pena incluir resumenes que usted considere
            importantes):

               * La configuracion del kernel (incluyendo los dispositivos
                 hardware que se tienen instalados)

               * Si se tienen opciones de depuracion activadas (tales como
                 WITNESS), y en tal caso, si el problema persiste cuando se
                 cambia el valor de dichas opciones

               * Una traza de depuracion, si se pudo generar.

               * El hecho de que se ha leido detenidamente el archivo
                 src/UPDATING para constatar que el problema no se ha
                 identificado alli (se garantiza que alguien le preguntara
                 sobre este punto)

               * Si se puede o no se puede ejecutar otro kernel sin problemas
                 (se trata de identificar problemas relacionados con el
                 hardware como discos con errores o CPUs sobrecalentadas, que
                 pueden confundirse facilmente con problemas del kernel)

          * Si se trata de un problema relacionado con los ports, preparese
            para poder proporcionar la informacion que se muestra a
            continuacion. (No es necesario incluir esta informacion por
            defecto, ya que solo produce un crecimiento indeseado de la base
            de datos, pero si se pueden incluir resumenes de aquellos datos
            que usted considere relevantes):

               * Los ports que se tiene instalados

               * Cualesquiera variables de entorno que sobreescriban los
                 valores por defecto del archivo bsd.port.mk, tales como
                 PORTSDIR

               * El hecho de que se ha leido ports/UPDATING y que nuestro
                 problema no se encuentra identificado en dicho archivo (se
                 garantiza que alguien puede preguntar este hecho).

     * Evitar peticiones de caracteristicas vagas. Los PRs del estilo de
       "alguien deberia implementar algo que haga esto y aquello y lo de mas
       alla" son informes con pocas probabilidades de obtener resultados
       positivos. Las caracteristicas deben ser muy concretas y especificas.
       Recuerde que el codigo fuente se encuentra disponible para todo el
       mundo, de tal forma que si usted necesita una caracteristica, la mejor
       forma de verla incluida en futuras versiones de la herramienta
       consiste en ponerse usted mismo a trabajar sobre ella, manos a la
       obra. Tambien tenga en cuenta que para discutir este tipo de problemas
       resulta mas adecuado utilizar la lista freebsd-questions, como ya se
       ha comentado anteriormente.

     * Asegurese que nadie mas ha enviado un PR similar. Aunque esto ya se ha
       mencionado anteriormente, merece la pena que se repita en este punto.
       Solamente lleva uno o dos minutos realizar una busqueda basada en un
       motor web en http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query.
       (Por supuesto, a todo el mundo se le puede olvidar realizar esto de
       vez en cuando, pero por esa misma razon merece la pena hacer incapie
       en ello)

     * Evite peticiones controvertidas. Si nuestro PR se dirige hacia un area
       o tema controvertido en el pasado, debemos prepararnos no solo a
       ofrecer parches, si no tambien a justificar por que motivo los parches
       proporcionados son la "Forma Correcta de Hacerlo". Como se aviso
       anteriormente, una busqueda meticulosa en las listas de correo en los
       archivos historicos sitos en
       http://www.FreeBSD.org/search/search.html#mailinglists resulta siempre
       una buena idea y sirve para preparar nuestro razonamiento y aprender
       de la experiencia y de las decisiones tomadas en el pasado.

     * Sea educado. Casi cualquier persona que se encarge de tratar nuestro
       informe de problemas trabajara en el como un voluntario. A nadie le
       gusta que le digan como hacer las cosas cuando ya se estan haciendo de
       una forma determinada, especialmente cuando la motivacion para
       realizarlas no es monetaria. Este hecho es bueno tenerlo en mente y
       aplicarlo para cualquier proyecto de Software Libre.

  4.2. Antes de comenzar.

   Antes de ejecutar el programa send-pr(1), asegurese 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
   electronico desde la maquina en la que se ejecuta send-pr(1), el informe
   jamas llegara a la base de datos GNATS. Si quiere saber mas sobre la
   configuracion del correo en FreeBSD consulte el capitulo de "Correo
   Electronico" del manual de FreeBSD en
   http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html.

  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 despues de eliminar el path). Simplemente basta con utilizar la
   opcion -a de linea 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
   automaticamente para no interferir con el agente de correo.

   Si se adjunta un parche, asegurese que se utiliza la opcion -c o la opcion
   -u de diff(1) para crear un contexto unificado (el contexto suele ser el
   preferido por quienes lo han de recibir) y ademas asegurese de especificar
   los numeros de revision de CVS de los archivos que se modifican para que
   los desarrolladores que lean el informe puedan aplicar dichos parches
   facilmente. Para problemas relacionados con el kernel o con las utilidades
   del sistema base, se prefiere un parche contra FreeBSD-CURRENT (la rama
   HEAD del arbol CVS) ya que cualquier codigo nuevo debe probar se
   primeramente en dicha rama. Despues de comprobar su correcto
   funcionamiento de una forma sustancial y extensa, eventualmente dicho
   codigo pasara a formar parte de FreeBSD-STABLE, mediante union o
   migracion.

   Si se envia un parte en linea, 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
   indentacion del parche, e invalida totalmente un parche que forme parte de
   un Makefile.

   Tambien tenga en cuenta que mientras que la inclusion de parches en un PR
   se considera como algo positivo-particularmente cuando se soluciona el
   problema que describe el informe-partes grandes y especialmente codigo
   nuevo que puede requerir una sustancial revision antes de ser aplicado
   deberia hacerse accesible a traves de otros medios, como paginas web o
   servidores de ftp, y en vez de incluir el parche en el informe se puede
   incluir la URL. Los parches de gran tamano en los correos electronicos
   tienden a mezclarse o partirse, especialmente cuando GNATS los trata, y
   cuanto mas grande es el parche mas dificil resulta recuperar el original.
   Tambien existe una ventaja anadida a la inclusion del parche a traves 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 atencion tambien al hecho de que, a menos que se
   especifique explicitamente lo contrario en el PR o en el propio parche,
   cualquier parche enviado se supone licenciado bajo los mismos terminos 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 proposito o se comentan los valores aceptables. No se preocupe
   por los comentarios, puesto que se borran automaticamente antes de generar
   el informe.

   Al comienzo de la plantilla, justo debajo de las lineas de SEND-PR:, se
   encuentran las cabeceras de correo electronico. Dichas cabeceras
   normalmente no se tienen que modificar, a menos que se este rellenando el
   informe desde una maquina que puede enviar correo pero no puede recibirlo
   directamente, en cuyo caso usted tendra que editar los campos From: y
   Reply-To: para escribir la direccion de correo valida. Tambien puede
   enviarse una copia a usted mismo o a cualquier otra persona rellenando el
   campo Cc:.

   A continuacion aparecen una serie de campos de una sola linea:

     * Submitter-Id: No cambie este campo. El valor por defecto current-users
       es correcto, incluso si se esta ejecutando FreeBSD-STABLE.

     * Originator: Se rellena automaticamente con el campo gecos del usuario
       que esta actualmente dentro del sistema. Por favor, especifique su
       nombre real, opcionalmente acompanado por su direccion de correo
       electronico entre < >.

     * Organization: Escriba lo que usted quiera. Este campo no se utiliza
       para nada significativo.

     * Confidential: Esto se rellena automaticamente con el literal no.
       Cambiar este valor carece de sentido ya que no existe ningun informe
       de problemas de FreeBSD confidencial-la base de datos de PR se
       distribuye a todo el mundo de forma publica mediante CVSup.

     * Synopsis: Rellene este campo con una descripcion corta y precisa del
       problema. La sinopsis se utiliza como subject del correo electronico
       del informe de problemas, y tambien se utiliza en los listados y
       resumenes de informes de la base de datos; informes de problemas con
       obscuras sinopsis tienden a ser completamente ignorados.

       Como se aviso anteriormente, si su informe de problemas incluye un
       parche, por favor incluya en la sinopsis la etiqueta [patch] al
       comienzo; si usted es un mantenedor de software, tambien puede anadir
       la cadena [maintainer update] y asignar el campo "Class" del informe
       al valor maintainer-update.

     * Severity: Los valores aceptados son non-critical, serious o critical.
       No sea exagerado; evite etiquetar el problema como critital a menos
       que sea realmente algo critico (e.g. escalada de permisos hacia root,
       kernel panic facilmente reproducible). Incluso debe pensarse
       detenidamente etiquetar algo como serious a menos que se trate de algo
       que afecte a muchos usuarios (problemas con drivers de dispositivos
       particulares o con utilidades del sistema). Los desarrolladores de
       FreeBSD no van a resolver el problema mas rapido por el hecho de
       variar esta etiqueta, debido a que existe mucha gente que infla este
       campo inadecuadamente. De hecho, los desarrolladores prestan muy poca
       atencion al valor de este campo y del siguiente precisamente por esto
       ultimo.

     * Priority: Los valores aceptados son low, medium o high. high debe
       reservarse para problemas que afecten a la mayoria de los usuarios de
       FreeBSD y medium para aquellos problemas que afecten a varios
       usuarios.

     * Category: Seleccione uno de los siguientes valores (extraidos de
       /usr/gnats/gnats-adm/categories):

          * advocacy: para problemas relacionados con la imagen publica de
            FreeBSD. Raras veces utilizado.

          * alpha: para problemas especificos de la plataforma Alpha.

          * amd64: para problemas especificos de la plataforma AMD64.

          * bin: para problemas con aplicaciones de la zona de usuario del
            sistema base.

          * conf: para problemas de archivos de configuracion, valores por
            defecto, etc.

          * docs: para problemas con las paginas de manual o la documentacion
            online.

          * gnu: para problemas realacionados con aplicaciones gnu de FreeBSD
            tales como gcc(1) o grep(1).

          * i386: para problemas especificos de la plataforma i386(TM).

          * ia64: para problemas especificos de la plataforma ia64.

          * java: para problemas relacionados con Java(TM).

          * kern: para problemas relacionados con el kernel o con (no
            especificos de ninguna plataforma) controladores de dispositivos.

          * misc: para cualquier cosa que no encaja en ninguna de las
            anteriores categorias. (Tenga en cuenta que es muy facil que los
            problemas bajo esta categoria se pierdan en el olvido).

          * ports: para problemas relacionados con el arbol de ports.

          * powerpc: para problemas especificos de la plataforma PowerPC(R).

          * sparc64: para problemas especificos de la plataforma Sparc64(R).

          * standards: para problemas relativos a la adecuacion con
            estandares.

          * threads: para problemas relacionados con la implementacion de
            threads de FreeBSD (especialmente en FreeBSD-CURRENT).

          * www: para cambios o mejoras del sitio web de FreeBSD.

     * Class: Se puede seleccionar uno entre los siguientes:

          * sw-bug: bugs de software.

          * doc-bug: errores en la documentacion.

          * change-request: peticiones de caracteristicas adicionales o de
            cambios en las caracteristicas existentes.

          * update: actualizaciones de ports o de software contribuido por
            terceros.

          * maintainer-update: actualizaciones de ports de los cuales usted
            es mantenedor.

     * Release: La version de FreeBSD que se esta ejecutando. El programa
       send-pr(1) rellena automaticamente este campo, por lo que solamente
       resulta necesaria su modificacion cuando estemos rellenando un informe
       de problemas desde un sistema distinto al sistema donde se ha
       producido dicho problema.

   Por ultimo, existen una serie de campos multilinea:

     * Environment: Este campo debe describir, tan preciso como sea posible,
       el entorno en el cual se ha observado el problema. Esto incluye la
       version del sistema operativo, la version del programa que contiene el
       problema y cualquier otro asunto relevante tales como la configuracion
       del sistema o cualquier otro software instalado que pueda influir en
       la ejecucion del primero, etc. Resumiendo todo lo anterior, se debe
       especificar todo lo que un desarrollador necesita conocer para poder
       reconstruir el entorno en el cual se ha producido el problema.

     * Description: Una descripcion completa y precisa del problema que se
       esta sufriendo. Intente evitar especular sobre las posibles causas del
       problema a menos que se tenga la seguridad de que el camino descrito
       es el correcto, puesto que puede inducir al desarrollador a realizar
       falsas presunciones.

     * How-To-Repeat: Un resumen de las acciones que deben llevarse a cabo
       para reproducir el problema.

     * Fix: Preferentemente un parche, o al menos una solucion temporal (la
       cual no solo ayuda a otras personas que experimenten el mismo
       problema, sino que puede ayudar tambien al desarrollador para que
       investigue sobre las verdaderas causas del problema). No obstante, si
       no se dispone de ninguna de estas opciones, lo mas sabio es dejar
       vacio este campo y sobre todo no hacer especulaciones.

  4.5. Envio del informe de problemas

   Una vez que hemos terminado de rellenar la plantilla, hemos salvado y
   hemos salido del editor, send-pr(1) nos dara 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 mas modificaciones a la plantilla o a para abortar el
   programa. Si se selecciona esta ultima alternativa, el informe de
   problemas no sera destruido, sino que permanecera en disco (send-pr(1) nos
   indicara 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
   tambien se puede transferir a otro sistema con mejor conectividad para
   finalmente enviarlo utilizando la opcion f de linea de comandos de
   send-pr(1):

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

   Esto leera el archivo especificado, validando sus contenidos, y eliminara
   los comentarios para finalmente enviarlo.

5. Follow-up

   Una vez enviado el informe de problemas, se recibe una confirmacion por
   correo electronico en la que se incluye el numero asignado al informe y la
   URL que puede utilizarse para consultar su estado. Con un poquito de
   suerte, alguien mostrara interes en el problema y tratara de solucionarlo,
   o de explicar por que razon no se considera un problema, como ha ocurrido
   en muchas ocasiones. Recibiremos automaticamente una notificacion relativa
   a cualquier cambio de estado, ademas de recibir copias de cualquier
   comentario o de los parches que se generen relacionados con nuestro
   informe.

   Si alguien solicita informacion adicional sobre el problema, o de repente
   descubre o recuerda algo que no tuvo ocasion de mencionar en el informe
   inicial, puede utilizar una de las siguientes opciones para enviar una
   continuacion ("followup") a dicho informe:

     * La forma mas sencilla consiste en utilizar el enlace followup que
       aparece en la pagina web asociada a nuestro informe de problemas, la
       cual se puede alcanzar a partir de la pagina de busquedas de PRs en
       http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query . Al pinchar en
       dicho enlace se mostrara una pantalla con las lineas de To: y Subject
       correctamente rellenadas (siempre y cuando el navegador soporte esta
       caracteristica de autorelleno).

     * Alternativamente, se puede enviar un correo eletronico directamente a
       <bug-followup@FreeBSD.org>, asegurando que el numero de seguimiento se
       incluye en el asunto para que el sistema de seguimiento de informes
       pueda adjuntar la respuesta al informe apropiado.

  Nota:

       Si no se incluye el numero de seguimiento, GNATS no reconocera el
       informe inicial y creara un PR totalmente nuevo, que quedara asignado
       al administrador de GNATS, de tal forma que el followup quedara en el
       vacio hasta que alguien resuelva el entuerto, lo cual puede tardar
       dias o semanas.

       Forma incorrecta:

 Subject: ese PR que
             envie en su dia

       Forma correcta:

 Subject: Re: ports/12345:
             problema de compilacion en foo/bar

   Si el informe de problemas permanece abierto una vez que dicho problema ha
   desaparecido, simplemente envie un followup (de la forma descrita
   anteriormente) diciendo que el informe de problemas se puede cerrar y, a
   ser posible, tambien conviene explicar la forma en que el problema se
   resolvio.

6. Lecturas recomendadas

   A continuacion se muestra una lista de recursos relacionados con la
   escritura adecuada de informes y con el procesamiento de dichos informes.
   No pretende ser una completa enumeracion.

     * How row to Report Bugs Effectively-un excelente ensayo por Simon G.
       Tatham sobre la redaccion de informes de problemas (el texto no es
       especifico sobre FreeBSD)

     * Problem Report Handling Guidelines-resumen de valor sobre como los
       desarrolladores de FreeBSD manejan y gestionan los informes de
       problemas.

Indice

  P

   problem reports, Como enviar informes de problemas de FreeBSD
