                  Escribiendo informes de problemas de FreeBSD

  Dag-Erling Smo/rgrav

   Contributed by  

  Mark Linimon

   Revision: 9e65c2492f

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   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, Centrino, Core, 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.

   Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM,
   Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox 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.

   2019-09-05 19:36:06 +0000 por Sergio Carlavilla Delgado.
   Resumen

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

   [ Split HTML / Single HTML ]

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

   Tabla de contenidos

   1. Introduccion

   2. Cuando enviar informes de problemas

   3. Preparativos

   4. Escribiendo el informe de problemas

   5. Follow-up

   6. Si hay problemas

   7. Lecturas adicionales

   Indice

1. Introduccion

   Una de las experiencias mas frustrantes que uno puede tener como usuario
   de software es enviar un informe de problemas solo para que se cierre
   sumariamente con una explicacion breve e inutil como "no es un error" o
   "PR erroneo". De manera similar, una de las experiencias mas frustrantes
   que puede experimentar un desarrollador de aplicaciones consiste en verse
   inundado por una cantidad ingente de informes de problemas 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 reproducirlo.

   Este documento intenta describir como escribir buenos informes de
   problemas. ?Que, se preguntara, es un buen informe de problemas? Bien,
   para ir directos al grano, un buen informe de problemas 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.

   Tenga en cuenta que este articulo esta organizado tematicamente, no
   cronologicamente. Lea todo el documento antes de enviar un informe de
   problemas, en lugar de tratarlo como un tutorial paso a paso.

2. Cuando enviar informes de problemas

   Hay muchos tipos de problemas y no todos ellos merecen la creacion de un
   informe de problemas. Por supuesto, nadie es perfecto, y habra ocasiones
   en que lo que parece ser un error en un programa es, de hecho, un
   malentendido de la sintaxis de un comando o un error tipografico en un
   archivo 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, y solo servira para frustrar
   tanto al remitente como a los desarrolladores. Por el contrario, hay casos
   en los que podria ser apropiado enviar un informe de problemas sobre algo
   mas que un error: una mejora o una nueva caracteristica, por ejemplo.

   Entonces, ?como se determina que es un error y que no? Como regla general,
   el problema no es un error si puede expresarse como una pregunta
   (normalmente del estilo de "?Como hago X?" o "?Donde puedo encontrar Y?").
   Las cosas no son siempre blancas o negras, pero la regla de la pregunta
   cubre la gran mayoria de los casos. Al buscar una respuesta, considere
   plantear la pregunta a la lista de correo de preguntas generales de
   FreeBSD.

   Tenga en cuenta estos factores al enviar PRs sobre ports u otro software
   que no sea parte de FreeBSD:

     * Por favor, no envie informes de problemas que simplemente indiquen la
       disponibilidad de una nueva version de una aplicacion. Los maintainers
       de ports son notificados automaticamente por portscout cuando una
       nueva version de una aplicacion esta disponible. Los parches para
       actualizar un port a la ultima version son bien recibidos.

     * Para los ports que no estan mantenidos (el MAINTAINER es
       ports@FreeBSD.org), es poco probable que un PR sin un parche adjunto
       sea cogido por un committer. Para convertirse en el maintainer de un
       port que no este mantenido, envie un PR con la peticion (seria ideal
       si viene con un parche adjunto, pero no es necesario).

     * En cualquier caso, seguir el proceso descrito en el Manual del Porter
       dara los mejores resultados. (Es posible que tambien desee leer Como
       contribuir a la coleccion de ports de FreeBSD).

   Un error que no se puede reproducir rara vez se podra arreglar. Si el
   error solo ocurrio una vez y no puede reproducirlo, y no parece que le
   ocurra a nadie mas, es probable que ninguno de los desarrolladores pueda
   reproducirlo o descubrir que es lo que esta mal. Eso no significa que no
   haya ocurrido, significa que las posibilidades de que su informe de
   problemas lleve a la correccion del error son muy escasas. Para empeorar
   las cosas, a menudo, este tipo de errores son en realidad causados por
   fallos en los discos duros o procesadores con sobrecalentamiento, siempre
   debe intentar descartar estas causas, siempre que sea posible, antes de
   enviar un PR.

   A continuacion, para decidir a quien debe presentar su informe de
   problemas, debe comprender que el software que compone FreeBSD esta
   compuesto de varios elementos diferentes:

     * El codigo en el sistema base que escriben y mantienen los
       colaboradores de FreeBSD, como el kernel, la biblioteca de C y los
       controladores de dispositivos (categorizados como kern); las
       utilidades binarias (bin); las paginas del manual y documentacion
       (docs); y las paginas web (www). Todos los errores en estas areas
       deben informarse a los desarrolladores de FreeBSD.

     * El codigo en el sistema base escrito y mantenido por otros, e
       importado y adaptado a FreeBSD. Los ejemplos incluyen clang(1) y
       sendmail(8). La mayoria de los errores en estas areas deben informarse
       a los desarrolladores de FreeBSD; pero en algunos casos es posible que
       deban informarse a los autores originales si los problemas no son
       especificos de FreeBSD.

     * Las aplicaciones individuales que no estan en el sistema base, sino
       que forman parte de la coleccion de ports de FreeBSD (categoria
       ports). La mayoria de estas aplicaciones no estan escritas por los
       desarrolladores de FreeBSD; lo que proporciona FreeBSD es simplemente
       un framework para instalar la aplicacion. Por lo tanto, solo informe
       de un problema a los desarrolladores de FreeBSD cuando crea que el
       problema es especifico de FreeBSD; de lo contrario, reportelo a los
       autores del software.

   Despues, averigu:e si es un problema puntual. Existen pocas cosas que
   molesten mas a un desarrollador que recibir un informe de problemas sobre
   un error que ya ha solucionado.

   Si el problema esta en el sistema base, primero lea la seccion de
   preguntas frecuentes sobre las versiones de FreeBSD, si aun no esta
   familiarizado con el tema. FreeBSD no puede solucionar problemas en otras
   ramas que no sean las mas recientes del sistema base, por lo que presentar
   un informe de error sobre una version anterior probablemente hara que un
   desarrollador le aconseje que se actualice a una version soportada para
   comprobar si el problema todavia sucede. El equipo Security Officer
   mantiene la lista de versiones soportadas.

   Si el problema esta en un port, considere enviar el error al upstream. El
   proyecto FreeBSD no puede corregir todos los errores en todo el software.

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 correo o
   fue discutido hace poco; incluso puede que ya este arreglado en una
   version mas nueva que la que esta ejecutando. 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:

     * La lista de preguntas mas frecuentes (FAQ) de FreeBSD. Las preguntas
       frecuentes intentan proporcionar respuestas a una amplia gama de
       preguntas, como las relacionadas con la compatibilidad del hardware,
       las aplicaciones de usuario y la configuracion del kernel.

     * Las listas de correo, si no esta suscrito, 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, toda la web: utilice su motor de busqueda favorito para
       localizar cualquier referencia al problema. Incluso puede obtener
       listas de correo archivadas o grupos de noticias que no conocia o en
       los que no habia pensado buscar.

     * A continuacion, la busqueda a traves de la base de datos de PR de
       FreeBSD (Bugzilla). A menos que el 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.

       Para el codigo base de FreeBSD, debe estudiar cuidadosamente el
       contenido del fichero /usr/src/UPDATING del sistema o la version mas
       reciente en https://svnweb.freebsd.org/base/head/UPDATING?view=log.
       (Esta informacion se considera de vital importancia si se esta
       actualizando de una version a otra, especialmente si esta actualizando
       a la rama de FreeBSD-CURRENT).

       No obstante, si el problema se encuentra en algo que se instalo como
       parte de la coleccion 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). https://svnweb.freebsd.org/port/head/UPDATING?view=log y
       https://svnweb.freebsd.org/ports/head/CHANGES?view=log tambien estan
       disponibles a traves de svnweb.

4. Escribiendo el informe de problemas

   Ahora que ha decidido que su problema merece un informe de problemas y que
   es un problema de FreeBSD, es el momento de escribir el informe de
   problemas propiamente dicho. Antes de pasar a describir los mecanismos
   utilizados por el programa encargado de generar y enviar los PRs, aqui hay
   algunos consejos y trucos para ayudarle a asegurarse de que su PR sea mas
   efectivo.

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

     * No deje el campo "Summary" vacio. Los PRs se envian a una lista de
       correo global (donde se utiliza el campo "Summary" para la linea
       Subject:), y se almacenan en una base de datos. Cualquiera que haga
       una busqueda por el campo synopsis (sinopsis) en la base de datos y
       encuentre un PR con la linea del subject (asunto) en blanco tiende a
       omitirlo. Recuerde que los PR permanecen en esta base de datos hasta
       que alguien los cierra; un PR que no este debidamente cumplimentado
       pasara desapercibido.

     * Rellene el campo "Summary" correctamente, no use descripciones vagas.
       No asuma que aquella persona que lea su PR entienda el contexto que
       motivo su envio, por lo tanto, cuanta mas informacion proporcione,
       mejor. Por ejemplo, ?en que parte del sistema se produce el problema?
       ?El problema sucede solo durante la instalacion o durante la ejecucion
       del sistema? Por ejemplo, en lugar de, Summary: portupgrade is broken,
       podria utilizar este otro, el cual, tiene mucha mas informacion:
       Summary: port ports-mgmt/portupgrade coredumps on -current. (En el
       caso de los ports, es especialmente util tener el nombre de la
       categoria y el nombre del port en el campo "Summary").

     * Si tiene un parche, digalo. Es mas probable que se analice un PR con
       un parche incluido que uno sin el. Incluya la palabra clave patch en
       Bugzilla.

     * Si es un maintainer, digalo. Si mantiene una parte del codigo fuente
       (por ejemplo, un port que ya exista), debe establecer el campo "Class"
       de su PR a maintainer-update. De esta forma, cualquier committer que
       se ocupe de su PR no tendra que verificarlo.

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

          * Incluya la version de FreeBSD que esta ejecutando (existe un
            lugar donde escribir esta informacion, vea a continuacion) y en
            que arquitectura. Debe incluir si se esta ejecutando desde una
            release (por ejemplo, desde un CD-ROM o descarga), o si es desde
            un sistema mantenido por Subversion (y, si es asi, en que numero
            de revision se encuentra). Si esta usando la rama
            FreeBSD-CURRENT, esa es la primera pregunta que le haran, porque
            las correcciones (especialmente para problemas de alto nivel)
            tienden a aplicarse muy rapidamente, y se espera que los usuarios
            de FreeBSD-CURRENT se mantengan al dia.

          * Incluya que opciones globales ha especificado en sus ficheros
            make.conf, src.conf y src-env.conf. Dado el numero infinito de
            opciones, no todas las combinaciones pueden ser totalmente
            compatibles.

          * Si el problema se puede reproducir facilmente, incluya
            informacion que ayude al desarrollador a reproducirlo por si
            mismo. Si se puede hacer una demostracion con una entrada
            especifica, incluya un ejemplo con esa entrada, si es posible, e
            incluya la salida real y la esperada. Si la informacion es grande
            o no se puede hacer publica, intente crear un archivo con lo
            minimo que muestre el mismo problema y que pueda incluirse en el
            PR.

          * 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, pero si puede
            merecer la pena incluir extractos que usted considere
            importantes):

               * la configuracion del kernel (incluidos los dispositivos de
                 hardware que ha instalado)

               * si tiene o no opciones de depuracion activadas (como
                 WITNESS), y si es asi, si el problema persiste cuando se
                 cambia el valor de dichas opciones

               * el texto completo de cualquier backtrace, panic u otra
                 salida por consola, o entradas en /var/log/messages, si se
                 genero alguna

               * la salida de pciconf -l y partes relevantes de su salida
                 dmesg si su problema se relaciona con una pieza especifica
                 de hardware

               * el hecho de que haya leido src/UPDATING y que su problema no
                 este listado (seguro que alguien le preguntara sobre este
                 punto)

               * si puede o no ejecutar otro kernel de respaldo sin problemas
                 (se trata de descartar problemas relacionados con el
                 hardware, como discos con errores o CPUs con
                 sobrecalentamiento, 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 esto solo produce un crecimiento indeseado de la
            base de datos, pero debe incluir extractos que considere que
            pueden ser relevantes):

               * Que ports ha instalado

               * Cualquier variable de entorno que sobrescriba los valores
                 por defecto del archivo bsd.port.mk, como PORTSDIR

               * El hecho de que ha leido el archivo ports/UPDATING y que su
                 problema no se encuentra en la lista (puede preguntar a
                 alguien)

     * Evitar peticiones de caracteristicas vagas. Los PRs del estilo
       "alguien deberia implementar algo que haga esto, aquello y lo de mas
       alla" son informes con pocas probabilidades de obtener resultados
       positivos. Recuerde, el codigo fuente se encuentra disponible para
       todo el mundo, por lo tanto, si desea una caracteristica, !la mejor
       manera de asegurarse de que se incluya es ponerse a trabajar en ella!
       Tambien tenga en cuenta que para discutir este tipo de problemas
       resulta mas adecuado utilizar la lista freebsd-questions, que una
       entrada en la base de datos de PR, como ya se ha comentado
       anteriormente.

     * Asegurese que nadie mas ha enviado un PR similar. Aunque esto ya se ha
       mencionado anteriormente, vale la pena repetirlo aqui. Solamente lleva
       uno o dos minutos utilizar el motor de busqueda web en
       https://bugs.freebsd.org/bugzilla/query.cgi. (Por supuesto, todo el
       mundo es culpable de olvidarse de hacerlo de vez en cuando).

     * Informe un solo problema por informe. Evite incluir dos o mas
       problemas dentro del mismo informe, a menos que esten relacionados. Al
       enviar parches, evite agregar multiples funciones o corregir varios
       errores en el mismo PR, a menos que esten estrechamente relacionados -
       ya que los PR suelen tardar mas en resolverse.

     * Evite peticiones controvertidas. Si su PR se dirige a un area que ha
       sido controvertida en el pasado, probablemente deberia estar preparado
       para no solo ofrecer parches, sino tambien una justificacion de por
       que los parches son la "forma correcta de hacerlo". Como se aviso
       anteriormente, una busqueda meticulosa en las listas de correo
       utilizando los archivos historicos en
       https://www.FreeBSD.org/search/search.html#mailinglists es siempre una
       buena opcion.

     * Sea educado. Practicamente cualquier persona que se encargue de tratar
       su PR es un voluntario. A nadie le gusta que le digan que tiene que
       hacer algo cuando ya lo estan haciendo por alguna otra motivacion que
       no sea la economica. Es bueno tenerlo en cuenta en todo momento en los
       proyectos de codigo abierto.

  4.2. Antes de comenzar

   Se aplican consideraciones similares al uso del formulario de envio de PR
   por la aplicacion web. Tenga cuidado con las operaciones de cortar y pegar
   que puedan cambiar los espacios en blanco u otro formato de texto.

   Finalmente, si el envio es largo, prepare el trabajo sin conexion, de
   forma que no se pierda nada si hay un problema al enviarlo.

  4.3. Adjuntar parches o archivos

   Al adjuntar un parche, asegurese de usar svn diff o diff(1) con el
   argumento -u para crear un diff unificado, y asegurese de especificar el
   numero de revision SVN del repositorio contra el que modifico los
   archivos, para que los desarrolladores que lean su informe puedan
   aplicarlos facilmente. Para problemas relacionados con el kernel o
   utilidades del sistema base, se prefiere un parche contra FreeBSD-CURRENT
   (la rama HEAD de Subversion), ya que todo el codigo nuevo debe aplicarse y
   probarse alli primero. Despues de que se hayan realizado las pruebas
   adecuadas o importantes, se hara el merge/migracion a la rama
   FreeBSD-STABLE.

   Si adjunta un parche como parte del mensaje, en lugar de como adjunto,
   tenga en cuenta que uno de los problemas mas comunes es la tendencia de
   algunos programas de correo electronico de mostrar las tabulaciones como
   espacios, lo cual estropeara por completo todo lo que pretenda que forme
   parte de un Makefile.

   No envie parches como archivos adjuntos usando Content-Transfer-Encoding:
   quoted-printable. Esto escapara el caracter (character escaping) y todo el
   parche sera inutil.

   Tambien tenga en cuenta que, incluir pequenos parches en un PR, en
   general, esta bien, especialmente cuando soluciona el problema descrito en
   el PR, los parches grandes y especialmente el nuevo codigo que pueda
   requerir una revision sustancial antes de realizar el commit deben
   colocarse en un servidor web o ftp, y la URL debe incluirse en el PR en
   lugar del parche. Los parches en el correo electronico tienden a ser
   destrozados, y cuanto mas grande sea el parche, mas dificil sera para las
   partes interesadas desenmaranarlo. Ademas, la publicacion de un parche en
   la web le permite modificarlo sin tener que volver a enviar el parche
   completo en un follow-up al PR original. Finalmente, los parches grandes
   simplemente aumentan el tamano de la base de datos, ya que los PR cerrados
   no se eliminan, sino que se guardan y simplemente se marcan como
   completos.

   Tambien debe tener en cuenta que, a menos que se especifique
   explicitamente lo contrario en su PR o en el propio parche, se asumira que
   los parches que envie se licenciaran en los mismos terminos que el archivo
   original que modifico.

  4.4. Rellenar el formulario

  Nota:

   La direccion de correo electronico que utilice pasara a ser publica y
   podra estar disponible para los spammers. Debe tener implementados
   procedimientos de manejo de spam o usar una cuenta de correo electronico
   temporal. Sin embargo, tenga en cuenta que si no utiliza una cuenta de
   correo electronico valida, no podremos hacerle preguntas sobre su PR.

   Cuando presente un error, encontrara los siguientes campos:

     * Synopsis: Rellene este campo con una descripcion corta y precisa del
       problema. El campo debe ser rellenado en ingles, pues es el idioma de
       comunicacion en el proyecto FreeBSD. 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 vagas sinopsis tienden a ser completamente
       ignorados.

     * Severity: Escoga una de las opciones, Affects only me (Solo me afecta
       a mi), Affects some people (Afecta a algunas personas) o Affects many
       people (Afecta a muchas personas). No sea exagerado; abstengase de
       etiquetar su problema Affects many people (Afecta a muchas personas) a
       menos que realmente lo haga. Los desarrolladores de FreeBSD no
       trabajaran en su problema mas rapido si infla su importancia, ya que
       muchas otras personas han hecho exactamente lo mismo.

     * Category: Elija una categoria apropiada.

       Lo primero que debe hacer es decidir en que parte del sistema se
       encuentra su problema. Recuerde, FreeBSD es un sistema operativo
       completo, instala un kernel, la biblioteca estandar, muchos
       controladores de perifericos y un gran numero de utilidades (el
       "sistema base"). Sin embargo, hay miles de aplicaciones adicionales en
       la coleccion de ports. Primero debera decidir si el problema esta en
       el sistema base o en algo instalado a traves de la coleccion de ports.

       Aqui una descripcion de las principales categorias:

          * Si hay un problema con el kernel, las bibliotecas (como la
            biblioteca estandar de C libc) o en un controlador de un
            periferico en el sistema base, en general, utilizara la categoria
            kern. (Hay algunas excepciones; vea mas abajo). En general, estas
            son las cosas que se describen en la seccion 2, 3 o 4 de las
            paginas del manual.

          * Si el problema es con un binario como sh(1) o mount(8), primero
            debera determinar si estos programas se encuentran en el sistema
            base o se anadieron a traves de la coleccion de ports. Si no esta
            seguro, puede hacer whereis programname. La convencion de FreeBSD
            para la coleccion de ports es instalar todo por debajo de
            /usr/local, aunque un administrador del sistema puede
            sobreescribirlo. Para estos, utilizara la categoria de ports (si,
            incluso si la categoria del port es www; vea mas abajo). Si la
            ubicacion es /bin, /usr/bin, /sbin, o /usr/sbin, es parte del
            sistema base, y debe usar la categoria bin. Estas son todas las
            cosas que se describen en las secciones 1 u 8 de las paginas del
            manual.

          * Si cree que el error esta en los scripts de inicio (rc), o en
            algun otro tipo de archivo de configuracion no ejecutable,
            entonces la categoria correcta es conf (configuracion). Estas son
            las cosas que se describen en la seccion 5 de las paginas del
            manual.

          * Si ha encontrado un problema en el conjunto de la documentacion
            (articulos, libros, man pages) o en el sitio web, la eleccion
            correcta es docs.

  Nota:

            Si tiene un problema con un port llamado www/algunnombredeport,
            esto entra en la categoria de ports.

       Hay algunas categorias mas especializadas.

          * Si el problema se catalogara en kern pero estuviera relacionado
            con el subsistema USB, la eleccion correcta es usb.

          * Si el problema se catalogara en kern pero estuviera relacionado
            con las bibliotecas de threading, la eleccion correcta es
            threads.

          * Si el problema se catalogara en el sistema base, pero estuviera
            relacionado con nuestra interpretacion de estandares, como
            POSIX(R), la eleccion correcta es standards.

          * Si esta convencido de que el problema solo ocurrira con la
            arquitectura del procesador que esta utilizando, seleccione una
            de las categories especificas de la arquitectura: normalmente,
            i386 para ordenadores compatibles con Intel en modo 32 bits;
            amd64 para maquinas AMD que se ejecutan en modo 64 bits (esto
            tambien incluye ordenadores compatibles con Intel que se ejecutan
            en modo EMT64); y las menos comunes, arm o powerpc.

  Nota:

            Estas categorias se utilizan con frecuencia para los problemas
            "No lo se". En lugar de suponer, utilice misc.

            Ejemplo 1. Uso correcto de la categoria de arquitectura
            especifica

            Tiene un ordenador comun (PC-based machine), y cree que ha
            encontrado un problema especifico para un conjunto de chips o una
            placa base en particular: i386 es la categoria correcta.

            Ejemplo 2. Uso incorrecto de la categoria de arquitectura
            especifica

            Esta teniendo un problema con una tarjeta periferica adicional en
            un bus comun, o un problema con un tipo particular de unidad de
            disco duro: en este caso, probablemente afecte a mas de una
            arquitectura, y kern es la categoria correcta.

          * Si realmente no sabe donde esta el problema (o la explicacion no
            parece encajar en los anteriores), use la categoria misc. Antes
            de hacerlo, es posible que primero desee solicitar ayuda en la
            lista de correo de preguntas generales de FreeBSD. Es posible que
            le indiquen que una de las categorias ya existentes es mejor
            opcion.

     * Environment: Esto debe describir, con la mayor precision posible, el
       entorno en el que se ha observado el problema. Esto incluye la version
       del sistema operativo, la version del programa o archivo especifico
       que contiene el problema y cualquier otro elemento relevante como la
       configuracion del sistema, otro software instalado que influya en el
       problema, etc. - simplemente todo lo que un desarrollador necesita
       saber para reconstruir el entorno en el que se produce el problema.

     * Description: Una descripcion completa y precisa del problema que esta
       experimentando. Intente evitar especular sobre las posibles causas del
       problema a menos que se tenga la seguridad de que el camino descrito
       es el correcto, ya que puede inducir a un desarrollador a hacer
       suposiciones incorrectas sobre el problema. Debe incluir las acciones
       que hay que realizar para reproducir el problema. Si conoce alguna
       solucion, incluyala. No solo ayuda a otras personas con el mismo
       problema a solucionarlo, sino que tambien puede ayudar a un
       desarrollador a entender la causa del problema.

5. Follow-up

   Una vez que se haya enviado el informe de problemas, recibira una
   confirmacion por correo electronico que incluira el numero de seguimiento
   que se asigno a su informe de problemas y una URL que puede usar para
   verificar su estado. Con un poco de suerte, alguien se interesara en su
   problema e intentara solucionarlo o, segun sea el caso, explicara por que
   no es un problema. Se le notificara automaticamente de cualquier cambio de
   estado y recibira copias de los comentarios o parches que alguien pueda
   adjuntar al registro de auditoria de su informe de problemas.

   Si alguien le solicita informacion adicional, o si recuerda o descubre
   algo que no menciono en el informe inicial, por favor, envie un follow-up.
   La razon numero uno para que un error no se arregle es la falta de
   comunicacion con el usario que creo el error. La forma mas facil es usar
   la opcion de comentarios en la pagina web de cada PR, a la que puede
   acceder desde la pagina de busqueda de PR.

   Si el informe de problemas permanece abierto una vez que dicho problema ha
   desaparecido, solo agregue un comentario que indique que el informe de
   problemas se puede cerrar y, a ser posible, explique como o cuando se
   soluciono el problema.

   A veces hay un retraso de una o dos semanas en las cuales el informe del
   problema esta sin cambios, sin asignar, ni comentado por nadie. Esto puede
   suceder cuando hay una acumulacion de informes de problemas o durante la
   temporada de vacaciones. Cuando un informe de problemas no ha recibido
   atencion despues de varias semanas, vale la pena encontrar a un committer
   que este interesado en trabajar en el.

   Hay varias formas de hacerlo, lo ideal es el orden siguiente, con algunos
   dias entre cada intento:

     * Encuentre la lista de correo de FreeBSD que sea relevante para el
       informe de problemas en la lista del manual y envie un mensaje a esa
       lista preguntando por asistencia o comentarios sobre el informe de
       problemas.

     * Unase a los canales de IRC relevantes. Aqui un listado parcial:
       https://wiki.freebsd.org/IrcChannels. Informe a las personas en ese
       canal sobre el informe del problema y solicite asistencia. Sea
       paciente y permanezca en el canal despues de la publicacion, para que
       las personas de diferentes zonas horarias de todo el mundo tengan la
       oportunidad de ponerse al dia.

     * Encuentre a committers interesados en el problema que reporto. Si el
       problema estaba en una herramienta, binario, port, documento o un
       fichero de codigo fuente en particular, verifique el repositorio SVN.
       Localice a los ultimos committers que realizaron cambios sustanciales
       en el archivo e intente acceder a ellos a traves de IRC o correo
       electronico. Puede encontrar una lista de los committers y sus correos
       electronicos en el articulo Colaboradores de FreeBSD.

   Recuerde que estas personas son voluntarios, al igual que los maintainers
   y usuarios, por lo que es posible que no esten disponibles de inmediato
   para ayudar con el informe del problema. La paciencia y la constancia en
   los seguimientos son altamente recomendadas y apreciadas. Con el
   suficiente cuidado y esfuerzo dedicado al proceso de seguimiento,
   encontrar un committer para encargarse del informe del problema es solo
   cuestion de tiempo.

6. Si hay problemas

   Si ha encontrado un problema con el sistema de errores, !presente un
   error! Hay una categoria exacta para este proposito. Si no puede hacerlo,
   pongase en contacto con los encargados de los errores en
   <bugmeister@FreeBSD.org>.

7. Lecturas adicionales

   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.

     * Como informar errores de forma efectiva-un excelente ensayo por Simon
       G. Tatham sobre la redaccion de informes de problemas (el texto no es
       especifico sobre FreeBSD).

     * Guia para el manejo de informes de problemas-contiene una informacion
       valiosa sobre como los informes de problemas son manejados por los
       desarrolladores de FreeBSD.

Indice

  P

   problem reports, Escribiendo informes de problemas de FreeBSD
