              Como enviar informes de problemas de FreeBSD

  Dag-Erling Smo/rgrav

   $FreeBSD:
   release/8.4.0/es_ES.ISO8859-1/articles/problem-reports/article.xml
   39632 2012-10-01 11:56:00Z gabor $

   $FreeBSD:
   release/8.4.0/es_ES.ISO8859-1/articles/problem-reports/article.xml
   39632 2012-10-01 11:56:00Z gabor $

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   CVSup is a registered trademark of John D. Polstra.

   IBM, AIX, EtherJet, Netfinity, 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, SPARCEngine, 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, JavaServer
   Pages, JDK, JRE, JSP, JVM, Netra, Solaris, StarOffice, Sun Blade,
   Sun Enterprise, Sun Fire, SunOS, and Ultra 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.

   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>.

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

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

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   .

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

  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.

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

          Puede descargar este y muchos otros documentos desde
                ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Si tiene dudas sobre FreeBSD consulte la documentacion antes de escribir
                  a la lista <questions@FreeBSD.org>.
    Envie sus preguntas sobre la documentacion a <doc@FreeBSD.org>.
