Escribiendo Informes de Problemas de FreeBSD

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

Marcas registradas

FreeBSD es una marca registrada de la Fundación FreeBSD

IBM, AIX, OS/2, PowerPC, PS/2, S/390, y ThinkPad son marcas registradas de International Business Machines Corporation en los Estados Unidos de América, otros países, o ambos.

Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, y Xeon son marcas registradas de ntel Corporation o sus subsidiarias en los Estados Unidos de América y otros países.

Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS y VirtualBox son marcas comerciales o marcas registradas de Sun Microsystems, Inc. en los Estados Unidos de América y otros países.

Muchos de los nombres usados por los fabricantes y vendedores para diferenciar sus productos son designados como marcas comerciales. Allí donde estos nombres aparezcan en este documento y el Proyecto FreeBSD fuera consciente de la alegación de marca comercial, los nombres tienen a continuación el símbolo “™” o “®”.

Tabla de contenidos

Resumen

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

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 cual es el problema y cómo reproducirlo.

Este documento intenta describir cómo escribir buenos informes de problemas. ¿Qué, te preguntarás, 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.

Ten en cuenta que este artículo está organizado temáticamente, no cronológicamente. Lee 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 determinar lo que es un bug y lo que no? Una regla sencilla es que el problema no es un bug si se puede expresar como una pregunta (normalmente de la forma "¿Cómo hago X?" o "¿Dónde puedo encontrar Y?"). No siempre todo es blanco o negro, pero la regla de la pregunta cubre una gran mayoría de los casos. Cuando estés buscando una respuesta, considera hacer la pregunta en la Lista de correo para preguntas generales sobre FreeBSD.

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

  • Por favor, no envíes 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 ports sin mantener (MAINTAINER es ports@FreeBSD.org), un PR sin un parche incluido tiene pocas posibilidades de ser cogido por un committer. Para convertirte en el maintainer de un port sin mantenedor, envía un PR con la petición (y con el parche preferentemente aunque no es obligatorio).

  • En cualquier caso, seguir el proceso descrito en el Porter’s Handbook ofrecerá los mejores resultados. (También podrías querer leer Contribuyendo 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 puedes 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 tu 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 debes 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, debes 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.

  • Código en el sistema base que es escrito y mantenido por otros, e importado y adaptado a FreeBSD. Ejemplos de esto son clang(1), y sendmail(8). La mayoría de los errores en estas áreas deberían ser reportados a los desarrolladores de FreeBSD; pero en algunos casos deberían ser reportados 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, informa de un problema a los desarrolladores de FreeBSD sólo cuando creas que el problema es específico de FreeBSD; de lo contrario, repórtalo a los autores del software.

Después, averigua 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 es en el sistema base, primero lee la sección FAQ de FreeBSD versions, si no estás familiarizado con el tema. Para FreeBSD no es posible arreglar problemas en otra cosa que no sean las ramas más recientes del sistema base, de forma que reportar un error acerca de una versión más antigua probablemente resulte en un desarrollador que te aconseja actualizarte a una versión soportada para ver si el problema sigue ocurriendo. El equipo del Security Officer mantiene la lista de versiones soportadas.

Si el problema está en un port, considera enviar el error al proyecto original (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ás 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 Frequently Asked Questions (FAQ) de FreeBSD. La FAQ intenta proporcionar respuestas para un gran rango de preguntas como las que tienen que ver con compatibilidad de hardware, aplicaciones de usuario, y configuración del kernel.

  • Las listas de correo- si todavía no estás suscrito, usa la búsqueda del histórico en el sitio web de FreeBSD. Si el problema no ha sido discutido en las listas, podrías probar a mandar un mensaje sobre ello y esperar unos días a ver si alguien se fija en algo que haya sido pasado por alto.

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

  • Después, la base de datos de PR de FreeBSD (Bugzilla) en la que se puede buscar. A menos que el problema sea reciente u oscuro, hay buenas posibilidades de que ya haya sido 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, deberías estudiar detenidamente el contenido de /usr/src/UPDATING de tu sistema o la última versión en https://cgit.freebsd.org/src/tree/UPDATING. (Es información vital si estás actualizando de una versión a otra - especialmente si estás actualizando la rama FreeBSD-CURRENT).

    Sin embargo, si el problema está en algo que ha sido instalado como parte de la Colección de Ports de FreeBSD, deberías mirar en /usr/ports/UPDATING (para ports individuales) o /usr/ports/CHANGES (para cambios que afectan a toda la Colección de Ports). https://cgit.freebsd.org/ports/tree/UPDATING y https://cgit.freebsd.org/ports/tree/CHANGES también están disponibles vía cgit.

4. Escribiendo el informe de problemas

Ahora que has decidido que tu 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 que te ayudarán a garantizar de que tu PR sea más efectivo.

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

  • No dejes la línea "Summary" vacía. Los PRs van tanto a una lista de correo que va a todo el mundo (donde "Summary" se utiliza para la línea Subject:), pero también a una base de datos. Cualquiera que tiempo después aparece y busca en la base de datos por sinopsis y encuentra un PR con la línea de tema en blanco, tiende a saltársela. Recuerda que los PR se mantienen en esta base de datos hasta que alguien los cierra; una anónima desaparecerá entre el ruido.

  • Evita el uso de líneas "Summary" débiles. No deberías asumir que alguien que lee tu PR tiene contexto acerca del mismo, así que cuando más proporciones, mejor. Por ejemplo, ¿a qué parte del sistema se refiere el problema?¿Sólo ves el problema al instalar o mientras ejecutas? Para ilustrar este punto, en lugar de Summary: portupgrade está roto, fíjate cómo esto es más informativo: Summary: el port ports-mgmt/portupgrade genera un core en -current. (En el caso de los ports, es especialmente útil tener tanto la categoría como el port en la línea "Summary".)

  • Si tienes un parche, dilo. Tener un parche hace más fácil que un informe progrese.

    • No utilices las palabras clave patch o patch-ready- están obsoletas.

  • Si eres un mantenedor, dilo. Si mantienes una parte del código fuente (por ejemplo, un port), entonces deberías establecer el "Class" de tu PR a maintainer-update. De este modo cualquier committer que se asigne tu PR no tendrá que comprobarlo.

  • Sé específico. Cuanta más información proporciones acerca del problema que tienes, mayores serán las posibilidades de obtener una respuesta.

    • Incluye la versión de FreeBSD que estás ejecutando (existe un lugar donde escribir esta información, lee a continuación) y en qué arquitectura. Debes incluir si se está ejecutando desde una release (por ejemplo, desde un CD-ROM o descarga), o si es desde un sistema mantenido por Git (y, si es así, en qué hash y rama te encuentras). Si estás usando la rama FreeBSD-CURRENT, esa es la primera pregunta que te harán, porque las correcciones (especialmente para problemas de alto nivel) tienden a solucionarse muy rápidamente, y se espera que los usuarios de FreeBSD-CURRENT se mantengan al día.

    • Incluye qué opciones globales has especificado en tus ficheros make.conf, src.conf, y src-env.conf. Dado el número infinito de opciones, no todas las combinaciones podrían ser totalmente compatibles.

    • Si el problema se puede reproducir fácilmente, incluye información que ayude al desarrollador a reproducirlo por sí mismo. Si se puede hacer una demostración con una entrada específica, incluye un ejemplo con esa entrada, si es posible, e incluye la salida real y la esperada. Si la información es grande o no se puede hacer pública, intenta 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árate 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 consideres importantes):

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

      • si tienes las opciones de depuración activadas (tales como WITNESS), y si es así, si el problema persiste cuando cambias esa opción

      • 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 las partes relevantes de tu salida de dmesg si tu problema está relacionado con un hardware específico

      • el hecho de que hayas leído src/UPDATING y que tu problema no esté listado (seguro que alguien te preguntará sobre esto)

      • 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árate 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 consideres que pueden ser relevantes):

      • qué ports has instalado

      • cualquier variable de entorno que sobrescribe los valores por defecto en bsd.port.mk, como PORTSDIR

      • El hecho de que has leído el archivo ports/UPDATING y que tu problema no se encuentra en la lista (seguro que alguien te lo pregunta)

  • Evita solicitudes vagas de nuevas funcionalidades. PRs con la forma "alguien debería implementar algo que haga esto y lo otro" tienen menos probabilidad de obtener resultados que las peticiones específicas. Recuerda, las fuentes están disponible para cualquiera, así que si quieres una funcionalidad, la mejor forma de asegurarte de que se incluye ¡es ponerte a trabajar! Además considera el hecho de que muchas cosas como esta tendrían mejor cabida en una discusión en freebsd-questions que en una entrada de la base de datos de PR, como se ha comentado arriba.

  • Asegúrate de que nadie haya enviado ya un PR similar. Aunque esto ya se ha mencionado arriba, se repite aquí. Sólo lleva un minuto o dos usar el motor de búsqueda basada en web en https://bugs.freebsd.org/bugzilla/query.cgi. (Por supuesto, todos somos culpables de olvidarnos de hacerlo de vez en cuando.)

  • Reporta un solo problema por informe. Evita incluir dos o más problemas dentro del mismo informe, a menos que estén relacionados. Al enviar parches, evita agregar múltiples funcionalidades o corregir varios errores en el mismo PR, a menos que estén estrechamente relacionados — esos PRs suelen tardar más en resolverse.

  • Evita solicitudes controvertidas. Si tu PR trata sobre un área que ha sido controvertida anteriormente, deberías estar preparado no sólo para ofrecer parches, sino también una justificación sobre por qué los parches son "Lo Que Se Debería Hacer". Como se ha comentado arriba, una búsqueda cuidadosa en las listas de correo utilizando los históricos en https://www.FreeBSD.org/search/#mailinglists es siempre una buena preparación.

  • Sé educado. Prácticamente cualquier persona que trabaje en tu 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 Open Source.

6. Antes de comenzar

Se pueden aplicar consideraciones similares al uso del formulario de envío de PR basado en web. Ten cuidado con las operaciones de copiar-y-pegar que podrían cambiar los espacios en blanco u otros formatos de texto.

Finalmente, si el envío es largo, prepara el trabajo sin conexión, de forma que no se pierda nada si hay un problema al enviarlo.

7. Adjuntar parches o archivos

En general, recomendamos utilizar git format-patch para generar uno o una serie de diffs unificados contra la rama base (por ejemplo origin/main). Los parches generados así incluirían los hashes de Git e incluirán tu nombre y dirección de correo, haciendo más fácil para los committers aplicar tu parche y reconocerte como el autor (usando git am). Para cambios menores donde prefieres no usar git, asegúrate de usar diff(1) con la opción -u para crear un diff unificado, ya que esto dará a los desarrolladores más contexto y hace que el diff sea más legible que otros formatos.

Para problemas con el kernel o utilidades base, es preferible un parche contra FreeBSD-CURRENT (la rama principal en Git) ya que todo el código nuevo se debería aplicar y probar primero ahí. Después de que se hayan hecho las pruebas apropiadas o sustanciales, el código se mergeará/migrará 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íes parches como archivos adjuntos usando Content-Transfer-Encoding: quoted-printable. Esto hará escapado de caracteres y todo el parche será inútil.

Ten en cuenta también 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 te 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 debes 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íes se licenciarán en los mismos términos que el archivo original que modificaste.

8. Rellenar el formulario

La dirección de correo electrónico que utilices pasará a ser pública y podrá estar disponible para los spammers. Debes tener implementados procedimientos de manejo de spam o usar una cuenta de correo electrónico temporal. Sin embargo, ten en cuenta que si no utilizas una cuenta de correo electrónico válida, no podremos hacerte preguntas sobre tu PR.

Cuando presentes un error, encontrarás los siguientes campos:

  • Summary: Rellena 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: Una de Affects only me, Affects some people o Affects many people. No exageres; contente de etiquetar tu problema como Affects many people a menos que realmente sea así. Los desarrolladores de FreeBSD no van a trabajar necesariamente más rápido si inflas su importancia puesto que hay mucha otra gente que ha hecho exactamente eso.

  • Category: Escoge la categoría apropiada.

    Lo primero que debes hacer es decidir en qué parte del sistema se encuentra tu problema. Recuerda, 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ás 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 tiene que ver con un programa binario como sh(1) o mount(8), primero necesitarás determinar si estos programas están en el sistema base o se añadieron mediante la Colección de Ports. Si no estás seguro puedes hacer whereis programa. La convención para la Colección de Ports de FreeBSD es instalar todo bajo /usr/local, aunque un administrador del sistema puede cambiar este comportamiento. Para estos, usarás la categoría ports(sí, incluso si la categoría del port es www; lee más abajo). Si se encuentra en /bin, /usr/bin, /sbin, o /usr/sbin, es parte del sistema base, y deberías usar la categoría bin. Estas son todas las cosas que se describen en las secciones 1 o 8 de las páginas de manual.

    • Si crees 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 has encontrado un problema en el conjunto de documentación (artículos, libros, páginas de manual) o sitio web la opción correcta es docs.

      si tienes un problema con un port llamado www/nombredelport, esto aún así también va en la categoría ports.

      Hay algunas categorías más especializadas.

    • si el problema podría ir en kern pero tiene que ver con el subsistema USB, la opción correcta es usb.

    • si el problema podría ir en kern pero tiene que ver con las librerías de hilos, la opción correcta es threads.

    • si el problema podría ser del sistema base, pero tiene que ver con la conformidad a los estándares como POSIX®, la opción correcta es standards.

    • Si estás convencido de que el problema solo ocurrirá con la arquitectura del procesador que estás utilizando, selecciona una de las categorías 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.

      Estas categorías a menudo son usadas erróneamente para problemas tipo "no lo sé". En lugar de especular, utiliza simplemente misc.

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

      Tienes una máquina normal tipo PC y piensas que has encontrado un problema específico de un chipset o una placa base particular: i386 es la categoría correcta.

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

      Estás 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 sabes dónde está el problema (o la explicación no parece adecuarse a ninguna de las de arriba), utiliza la categoría misc. Antes de hacerlo, podrías querer pedir ayuda primero en la Lista de correo para preguntas generales sobre FreeBSD. Te podrían aconsejar que una de las categorías existentes es realmente una mejor opción.

  • Environment: Esto debería 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ás experimentando. Intenta 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. Debería incluir las acciones que hay que realizar para reproducir el problema. Si conoces alguna solución, inclúyela. 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.

9. Follow-up

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

Si alguien te solicita información adicional, o si recuerdas o descubres algo que no mencionaste en el informe inicial, por favor, envía un follow-up. La razón número uno para que un error no se arregle es la falta de comunicación con el usuario 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 puedes acceder desde la página de búsqueda de PRs.

Si el informe de problemas permanece abierto una vez que dicho problema ha desaparecido, solo agrega un comentario que indique que el informe de problemas se puede cerrar y, a ser posible, explica 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:

  • Envía un e-mail a la lista apropiada buscando comentarios sobre el informe.

  • Únete a los canales de IRC relevantes. Se puede encontrar un listado parcial aquí: https://wiki.freebsd.org/IrcChannels. Informa a la gente en el canal acerca del informe del problema y pide ayuda. Sé paciente y mantente en el canal después de preguntar, de forma que la gente de diferentes zonas horarias alrededor del mundo tenga una oportunidad para ponerse al día.

  • Encuentra committers interesados en el problema que se ha reportado. Si era sobre una herramienta, binario, port, documento o fichero de fuentes particular, comprueba el Repositorio Git. Localiza los últimos committers que hicieron cambios sustanciales al fichero y trata de ponerte en contacto con ellos vía IRC o email. Una lista de committers junto con sus emails se puede encontrar en el artículo Colaboradores de FreeBSD.

Recuerda que estas personas son voluntarios, al igual que los mantenedores 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.

10. Si hay problemas

Si encontraste un problema en el sistema de bugs, ¡abre un informe de error! Hay una categoría exactamente para este propósito. Si no puedes hacerlo, contacta con los domadores de bugs en bugmeister@FreeBSD.org.

11. Otras Lecturas

Esta es una lista de recursos relacionados con la escritura y procesamiento adecuados de informes de error. No pretende ser una lista completa.

Last modified on: 6 de noviembre de 2022 by Fernando Apesteguía