Escribiendo informes de problemas de FreeBSD

Dag-Erling Smørgrav

Contributed by  

Mark Linimon

Revisión: 53375

Aviso Legal

2019-09-05 19:36:06 por carlavilla.

Resumen

Este artículo describe cómo realizar y enviar informes de problemas para el proyecto FreeBSD de la mejor forma posible.

[ Split HTML / Single HTML ]

1. Introducción

Una de las experiencias más frustrantes que uno puede tener como usuario de software es enviar un informe de problemas solo para que se cierre sumariamente con una explicación breve e inútil como “no es un error” o “PR erróneo”. De manera similar, una de las experiencias más 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 información sobre cúal es el problema y cómo reproducirlo.

Este documento intenta describir cómo escribir buenos informes de problemas. ¿Qué, se preguntará, es un buen informe de problemas? Bien, para ir directos al grano, un buen informe de problemas es aquél que se puede analizar y tratar rápidamente, para mutua satisfacción del usuario y del desarrollador.

Aunque el objetivo principal de este artículo se centra en los informes de problemas de FreeBSD, la mayoría de los conceptos se pueden aplicar bastante bien en otros proyectos de software.

Tenga en cuenta que este artículo está organizado temáticamente, no cronológicamente. Lea todo el documento antes de enviar un informe de problemas, en lugar de tratarlo como un tutorial paso a paso.

2. Cuándo enviar informes de problemas

Hay muchos tipos de problemas y no todos ellos merecen la creación de un informe de problemas. Por supuesto, nadie es perfecto, y habrá 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 tipográfico en un archivo de configuración (aunque en este último caso podría tratarse de un indicador de documentación escasa o que la aplicación peca de una gestión de errores defectuosa). Incluso teniendo estos aspectos en cuenta existen varios casos en los cuales el envío de un informe de problemas resulta claramente no ser la mejor forma de proceder, y solo servirá para frustrar tanto al remitente como a los desarrolladores. Por el contrario, hay casos en los que podría ser apropiado enviar un informe de problemas sobre algo más que un error: una mejora o una nueva característica, por ejemplo.

Entonces, ¿cómo se determina qué es un error y qué no? Como regla general, el problema no es un error si puede expresarse como una pregunta (normalmente del estilo de “¿Cómo hago X?” o “¿Dónde puedo encontrar Y?”). Las cosas no son siempre blancas o negras, pero la regla de la pregunta cubre la gran mayoría 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 envíe informes de problemas que simplemente indiquen la disponibilidad de una nueva versión de una aplicación. Los maintainers de ports son notificados automáticamente por portscout cuando una nueva versión de una aplicación esta disponible. Los parches para actualizar un port a la última versión son bien recibidos.

Para los ports que no están 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, envíe un PR con la petición (sería ideal si viene con un parche adjunto, pero no es necesario).

En cualquier caso, seguir el proceso descrito en el Manual del Porter dará los mejores resultados. (Es posible que también desee leer Cómo contribuir a la colección de ports de FreeBSD).

Un error que no se puede reproducir rara vez se podrá arreglar. Si el error solo ocurrió una vez y no puede reproducirlo, y no parece que le ocurra a nadie más, es probable que ninguno de los desarrolladores pueda reproducirlo o descubrir qué es lo que está mal. Eso no significa que no haya ocurrido, significa que las posibilidades de que su informe de problemas lleve a la corrección 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 continuación, para decidir a quién debe presentar su informe de problemas, debe comprender que el software que compone FreeBSD está compuesto de varios elementos diferentes:

El código 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 páginas del manual y documentación (docs); y las páginas web (www). Todos los errores en estas áreas deben informarse a los desarrolladores de FreeBSD.

El código en el sistema base escrito y mantenido por otros, e importado y adaptado a FreeBSD. Los ejemplos incluyen clang(1) y sendmail(8). La mayoría de los errores en estas áreas 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 específicos de FreeBSD.

Las aplicaciones individuales que no están en el sistema base, sino que forman parte de la colección de ports de FreeBSD (categoría ports). La mayoría de estas aplicaciones no están escritas por los desarrolladores de FreeBSD; lo que proporciona FreeBSD es simplemente un framework para instalar la aplicación. Por lo tanto, solo informe de un problema a los desarrolladores de FreeBSD cuando crea que el problema es específico de FreeBSD; de lo contrario, repórtelo a los autores del software.

Después, averigüe si es un problema puntual. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un error que ya ha solucionado.

Si el problema está en el sistema base, primero lea la sección de preguntas frecuentes sobre las versiones de FreeBSD, si aún no está familiarizado con el tema. FreeBSD no puede solucionar problemas en otras ramas que no sean las más recientes del sistema base, por lo que presentar un informe de error sobre una versión anterior probablemente hará que un desarrollador le aconseje que se actualice a una versión soportada para comprobar si el problema todavía sucede. El equipo Security Officer mantiene la lista de versiones soportadas.

Si el problema está 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 búsqueda antes de enviar un informe de problemas. Quizá nuestro problema ya ha sido reportado; quizá se está discutiendo en las listas de correo o fue discutido hace poco; incluso puede que ya esté arreglado en una versión más nueva que la que está ejecutando. Por lo tanto, se deben consultar los sitios y fuentes más obvias antes de proceder con el envío del informe de errores. En FreeBSD, esto significa:

La lista de preguntas más 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 configuración del kernel.

Las listas de correo, si no está suscrito, utilice la búsqueda en los archivos del sitio web de FreeBSD. Si el problema no se ha discutido con anterioridad en las listas, se puede intentar enviar un mensaje y esperar unos pocos días para ver si alguien puede aconsejarle adecuadamente sobre algún punto que quizá haya pasado por alto en relación con el problema.

Opcionalmente, toda la web: utilice su motor de búsqueda favorito para localizar cualquier referencia al problema. Incluso puede obtener listas de correo archivadas o grupos de noticias que no conocía o en los que no había pensado buscar.

A continuación, la búsqueda a través de la base de datos de PR de FreeBSD (Bugzilla). A menos que el problema sea muy reciente o rebuscado, existe un gran número de posibilidades de que ya haya sido informado o reportado.

Lo más importante, se debería intentar comprobar si la documentación existente en el código fuente del programa puede resolver el problema.

Para el código base de FreeBSD, debe estudiar cuidadosamente el contenido del fichero /usr/src/UPDATING del sistema o la versión más reciente en https://svnweb.freebsd.org/base/head/UPDATING?view=log. (Esta información se considera de vital importancia si se está actualizando de una versión a otra, especialmente si está actualizando a la rama de FreeBSD-CURRENT).

No obstante, si el problema se encuentra en algo que se instaló como parte de la colección de ports de FreeBSD, se debe consultar el archivo /usr/ports/UPDATING (para ports individuales) o el archivo /usr/ports/CHANGES (para cambios que afectan a la colección de ports completa). https://svnweb.freebsd.org/port/head/UPDATING?view=log y https://svnweb.freebsd.org/ports/head/CHANGES?view=log también están disponibles a través 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, aquí hay algunos consejos y trucos para ayudarle a asegurarse de que su PR sea más efectivo.

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

No deje el campo “Summary” vacío. Los PRs se envían a una lista de correo global (donde se utiliza el campo “Summary” para la línea Subject:), y se almacenan en una base de datos. Cualquiera que haga una búsqueda por el campo synopsis (sinopsis) en la base de datos y encuentre un PR con la línea 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 esté debidamente cumplimentado pasará desapercibido.

Rellene el campo “Summary” correctamente, no use descripciones vagas. No asuma que aquella persona que lea su PR entienda el contexto que motivó su envío, por lo tanto, cuanta más información proporcione, mejor. Por ejemplo, ¿en qué parte del sistema se produce el problema? ¿El problema sucede solo durante la instalación o durante la ejecución del sistema? Por ejemplo, en lugar de, Summary: portupgrade is broken, podría utilizar este otro, el cual, tiene mucha más información: Summary: port ports-mgmt/portupgrade coredumps on -current. (En el caso de los ports, es especialmente útil tener el nombre de la categoría y el nombre del port en el campo “Summary”).

Si tiene un parche, dígalo. Es más probable que se analice un PR con un parche incluido que uno sin él. Incluya la palabra clave patch en Bugzilla.

Si es un maintainer, dígalo. Si mantiene una parte del código 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 tendrá que verificarlo.

Sea concreto. Cuanta más información se proporcione sobre el problema que tiene, más posibilidades de obtener una respuesta.

Incluya la versión de FreeBSD que está ejecutando (existe un lugar donde escribir esta información, vea a continuación) y en qué arquitectura. Debe incluir si se está ejecutando desde una release (por ejemplo, desde un CD-ROM o descarga), o si es desde un sistema mantenido por Subversion (y, si es así, en qué número de revisión se encuentra). Si está usando la rama FreeBSD-CURRENT, esa es la primera pregunta que le harán, porque las correcciones (especialmente para problemas de alto nivel) tienden a aplicarse muy rápidamente, y se espera que los usuarios de FreeBSD-CURRENT se mantengan al día.

Incluya qué opciones globales ha especificado en sus ficheros make.conf, src.conf y src-env.conf. Dado el número infinito de opciones, no todas las combinaciones pueden ser totalmente compatibles.

Si el problema se puede reproducir fácilmente, incluya información que ayude al desarrollador a reproducirlo por sí mismo. Si se puede hacer una demostración con una entrada específica, incluya un ejemplo con esa entrada, si es posible, e incluya la salida real y la esperada. Si la información es grande o no se puede hacer pública, intente crear un archivo con lo mínimo que muestre el mismo problema y que pueda incluirse en el PR.

Si se trata de un problema del kernel, prepárese para proporcionar la siguiente información. (No es necesario incluir esta información por defecto, puesto que lo único que produce es un crecimiento desmesurado de la base de datos, pero sí puede merecer la pena incluir extractos que usted considere importantes):

la configuración del kernel (incluidos los dispositivos de hardware que ha instalado)

si tiene o no opciones de depuración activadas (como WITNESS), y si es así, 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 generó alguna

la salida de pciconf -l y partes relevantes de su salida dmesg si su problema se relaciona con una pieza específica de hardware

el hecho de que haya leído src/UPDATING y que su problema no esté listado (seguro que alguien le preguntará 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 fácilmente con problemas del kernel)

Si se trata de un problema relacionado con los ports, prepárese para poder proporcionar la información que se muestra a continuación. (No es necesario incluir esta información 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):

Qué 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 leído el archivo ports/UPDATING y que su problema no se encuentra en la lista (puede preguntar a alguien)

Evitar peticiones de características vagas. Los PRs del estilo “alguien debería implementar algo que haga esto, aquello y lo de más allá” son informes con pocas probabilidades de obtener resultados positivos. Recuerde, el código fuente se encuentra disponible para todo el mundo, por lo tanto, si desea una característica, ¡la mejor manera de asegurarse de que se incluya es ponerse a trabajar en ella! También tenga en cuenta que para discutir este tipo de problemas resulta más adecuado utilizar la lista freebsd-questions, que una entrada en la base de datos de PR, como ya se ha comentado anteriormente.

Asegúrese que nadie más ha enviado un PR similar. Aunque esto ya se ha mencionado anteriormente, vale la pena repetirlo aquí. Solamente lleva uno o dos minutos utilizar el motor de búsqueda 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 más problemas dentro del mismo informe, a menos que estén relacionados. Al enviar parches, evite agregar múltiples funciones o corregir varios errores en el mismo PR, a menos que estén estrechamente relacionados — ya que los PR suelen tardar más en resolverse.

Evite peticiones controvertidas. Si su PR se dirige a un área que ha sido controvertida en el pasado, probablemente debería estar preparado para no solo ofrecer parches, sino también una justificación de por qué los parches son la “forma correcta de hacerlo”. Como se avisó anteriormente, una búsqueda meticulosa en las listas de correo utilizando los archivos históricos en https://www.FreeBSD.org/search/search.html#mailinglists es siempre una buena opción.

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 están haciendo por alguna otra motivación que no sea la económica. Es bueno tenerlo en cuenta en todo momento en los proyectos de código abierto.

4.2. Antes de comenzar

Se aplican consideraciones similares al uso del formulario de envío de PR por la aplicación 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 envío es largo, prepare el trabajo sin conexión, de forma que no se pierda nada si hay un problema al enviarlo.

4.3. Adjuntar parches o archivos

Al adjuntar un parche, asegúrese de usar svn diff o diff(1) con el argumento -u para crear un diff unificado, y asegúrese de especificar el número de revisión SVN del repositorio contra el que modificó los archivos, para que los desarrolladores que lean su informe puedan aplicarlos fácilmente. 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 código nuevo debe aplicarse y probarse allí primero. Después de que se hayan realizado las pruebas adecuadas o importantes, se hará el merge/migración 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 más comunes es la tendencia de algunos programas de correo electrónico de mostrar las tabulaciones como espacios, lo cual estropeará por completo todo lo que pretenda que forme parte de un Makefile.

No envíe parches como archivos adjuntos usando Content-Transfer-Encoding: quoted-printable. Esto escapará el carácter (character escaping) y todo el parche será inútil.

También tenga en cuenta que, incluir pequeños parches en un PR, en general, está bien, especialmente cuando soluciona el problema descrito en el PR, los parches grandes y especialmente el nuevo código que pueda requerir una revisión 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 electrónico tienden a ser destrozados, y cuanto más grande sea el parche, más difícil será para las partes interesadas desenmarañarlo. Además, la publicación 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 tamaño de la base de datos, ya que los PR cerrados no se eliminan, sino que se guardan y simplemente se marcan como completos.

También debe tener en cuenta que, a menos que se especifique explícitamente lo contrario en su PR o en el propio parche, se asumirá que los parches que envíe se licenciarán en los mismos términos que el archivo original que modificó.

4.4. Rellenar el formulario

Nota:

La dirección de correo electrónico que utilice pasará a ser pública y podrá estar disponible para los spammers. Debe tener implementados procedimientos de manejo de spam o usar una cuenta de correo electrónico temporal. Sin embargo, tenga en cuenta que si no utiliza una cuenta de correo electrónico válida, no podremos hacerle preguntas sobre su PR.

Cuando presente un error, encontrará los siguientes campos:

Synopsis: Rellene este campo con una descripción corta y precisa del problema. El campo debe ser rellenado en inglés, pues es el idioma de comunicación en el proyecto FreeBSD. La sinopsis se utiliza como subject del correo electrónico del informe de problemas, y también se utiliza en los listados y resúmenes 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; absténgase de etiquetar su problema Affects many people (Afecta a muchas personas) a menos que realmente lo haga. Los desarrolladores de FreeBSD no trabajarán en su problema más rápido si infla su importancia, ya que muchas otras personas han hecho exactamente lo mismo.

Category: Elija una categoría apropiada.

Lo primero que debe hacer es decidir en qué parte del sistema se encuentra su problema. Recuerde, FreeBSD es un sistema operativo completo, instala un kernel, la biblioteca estándar, muchos controladores de periféricos y un gran número de utilidades (el “sistema base”). Sin embargo, hay miles de aplicaciones adicionales en la colección de ports. Primero deberá decidir si el problema está en el sistema base o en algo instalado a través de la colección de ports.

Aquí una descripción de las principales categorías:

Si hay un problema con el kernel, las bibliotecas (como la biblioteca estándar de C libc) o en un controlador de un periférico en el sistema base, en general, utilizará la categoría kern. (Hay algunas excepciones; vea más abajo). En general, estas son las cosas que se describen en la sección 2, 3 ó 4 de las páginas del manual.

Si el problema es con un binario como sh(1) o mount(8), primero deberá determinar si estos programas se encuentran en el sistema base o se añadieron a través de la colección de ports. Si no está seguro, puede hacer whereis programname. La convención de FreeBSD para la colección de ports es instalar todo por debajo de /usr/local, aunque un administrador del sistema puede sobreescribirlo. Para estos, utilizará la categoría de ports (sí, incluso si la categoría del port es www; vea más abajo). Si la ubicación es /bin, /usr/bin, /sbin, o /usr/sbin, es parte del sistema base, y debe usar la categoría bin. Estas son todas las cosas que se describen en las secciones 1 u 8 de las páginas del manual.

Si cree que el error está en los scripts de inicio (rc), o en algún otro tipo de archivo de configuración no ejecutable, entonces la categoría correcta es conf (configuración). Estas son las cosas que se describen en la sección 5 de las páginas del manual.

Si ha encontrado un problema en el conjunto de la documentación (artículos, libros, man pages) o en el sitio web, la elección correcta es docs.

Nota:

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

Hay algunas categorías más especializadas.

Si el problema se catalogará en kern pero estuviera relacionado con el subsistema USB, la elección correcta es usb.

Si el problema se catalogará en kern pero estuviera relacionado con las bibliotecas de threading, la elección correcta es threads.

Si el problema se catalogará en el sistema base, pero estuviera relacionado con nuestra interpretación de estándares, como POSIX®, la elección correcta es standards.

Si está convencido de que el problema solo ocurrirá con la arquitectura del procesador que está utilizando, seleccione una de las categories específicas de la arquitectura: normalmente, i386 para ordenadores compatibles con Intel en modo 32 bits; amd64 para máquinas AMD que se ejecutan en modo 64 bits (esto también incluye ordenadores compatibles con Intel que se ejecutan en modo EMT64); y las menos comunes, arm o powerpc.

Nota:

Estas categorías se utilizan con frecuencia para los problemas “No lo sé”. En lugar de suponer, utilice misc.

Ejemplo 1. Uso correcto de la categoría de arquitectura específica

Tiene un ordenador común (PC-based machine), y cree que ha encontrado un problema específico para un conjunto de chips o una placa base en particular: i386 es la categoría correcta.

Ejemplo 2. Uso incorrecto de la categoría de arquitectura específica

Está teniendo un problema con una tarjeta periférica adicional en un bus común, o un problema con un tipo particular de unidad de disco duro: en este caso, probablemente afecte a más de una arquitectura, y kern es la categoría correcta.

Si realmente no sabe dónde está el problema (o la explicación no parece encajar en los anteriores), use la categoría 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 categorías ya existentes es mejor opción.

Environment: Esto debe describir, con la mayor precisión posible, el entorno en el que se ha observado el problema. Esto incluye la versión del sistema operativo, la versión del programa o archivo específico que contiene el problema y cualquier otro elemento relevante como la configuración 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 descripción completa y precisa del problema que está 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 solución, inclúyala. No solo ayuda a otras personas con el mismo problema a solucionarlo, sino que también puede ayudar a un desarrollador a entender la causa del problema.

5. Follow-up

Una vez que se haya enviado el informe de problemas, recibirá una confirmación por correo electrónico que incluirá el número de seguimiento que se asignó a su informe de problemas y una URL que puede usar para verificar su estado. Con un poco de suerte, alguien se interesará en su problema e intentará solucionarlo o, según sea el caso, explicará por qué no es un problema. Se le notificará automáticamente de cualquier cambio de estado y recibirá copias de los comentarios o parches que alguien pueda adjuntar al registro de auditoría de su informe de problemas.

Si alguien le solicita información adicional, o si recuerda o descubre algo que no mencionó en el informe inicial, por favor, envíe un follow-up. La razón número uno para que un error no se arregle es la falta de comunicación con el usario que creó el error. La forma más fácil es usar la opción de comentarios en la página web de cada PR, a la que puede acceder desde la página de búsqueda 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 cómo o cuándo se solucionó el problema.

A veces hay un retraso de una o dos semanas en las cuales el informe del problema está sin cambios, sin asignar, ni comentado por nadie. Esto puede suceder cuando hay una acumulación de informes de problemas o durante la temporada de vacaciones. Cuando un informe de problemas no ha recibido atención después de varias semanas, vale la pena encontrar a un committer que esté interesado en trabajar en él.

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

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

Únase a los canales de IRC relevantes. Aquí 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 después de la publicación, para que las personas de diferentes zonas horarias de todo el mundo tengan la oportunidad de ponerse al día.

Encuentre a committers interesados en el problema que reportó. Si el problema estaba en una herramienta, binario, port, documento o un fichero de código fuente en particular, verifique el repositorio SVN. Localice a los últimos committers que realizaron cambios sustanciales en el archivo e intente acceder a ellos a través de IRC o correo electrónico. Puede encontrar una lista de los committers y sus correos electrónicos en el artículo Colaboradores de FreeBSD.

Recuerde que estas personas son voluntarios, al igual que los maintainers y usuarios, por lo que es posible que no estén 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 cuestión de tiempo.

6. Si hay problemas

Si ha encontrado un problema con el sistema de errores, ¡presente un error! Hay una categoría exacta para este propósito. Si no puede hacerlo, póngase en contacto con los encargados de los errores en <bugmeister@FreeBSD.org>.

7. Lecturas adicionales

A continuación 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 enumeración.

Cómo informar errores de forma efectiva—un excelente ensayo por Simon G. Tatham sobre la redacción de informes de problemas (el texto no es específico sobre FreeBSD).

Guía para el manejo de informes de problemas—contiene una información valiosa sobre cómo los informes de problemas son manejados por los desarrolladores de FreeBSD.

Índice

P

problem reports, Escribiendo informes de problemas de FreeBSD