This translation may be out of date. To help with the translations please access the FreeBSD translations instance .
FreeBSD es una marca registrada de la Fundación FreeBSD
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 “®”.
Resumen
Esta guía describe las prácticas recomendadas para manejar los Informes de Problemas (PRs) de FreeBSD. Aunque se desarrolló para el FreeBSD PR Database Maintenance Team freebsd-bugbusters@FreeBSD.org , cualquiera que trabaje con PRs de FreeBSD debe seguir estas pautas.
Bugzilla es un sistema de gestión de errores utilizado por el proyecto FreeBSD. Un seguimiento preciso de los defectos de software pendientes es importante para la calidad de FreeBSD, el uso correcto del software es esencial para el progreso del Proyecto.
El acceso a Bugzilla está disponible para toda la comunidad de FreeBSD. Con el fin de mantener la coherencia dentro de la base de datos y proporcionar una experiencia de usuario consistente, se han establecido pautas que cubren aspectos comunes de la gestión de errores, como la presentación del seguimiento, el manejo de las solicitudes de cierre, etc.
El Usuario (Reporter) envía un informe de error a través del sitio web. El bug se encuentra en el estado
Needs Triage
.
Jane Random BugBuster confirma que el error reportado tiene la suficiente información para ser reproducido. Si no, se interactuará repetidamente con el usuario para obtener la información necesaria. En este punto, el error se establece en el estado
Open
.
Joe Random Committer se interesa por el PR y se lo asigna a sí mismo, o Jane Random BugBuster decide que Joe es la persona más adecuada para resolver el problema y se lo asigna. El error se debe poner en el estado
In Discussion
.
Joe tiene una breve conversación con el usuario que ha enviado el informe del problema (asegurándose de que todo queda registrado) y determina la causa.
Joe trabaja toda la noche y confecciona un parche que cree que soluciona el problema, y lo envía de nuevo, pidiendo al usuario que lo pruebe. Luego establece el estado del PR a
Patch Ready
.
Un par de iteraciones más tarde, tanto Joe como el usuario que lo ha creado están satisfechos con el parche, y Joe realiza el commit a
-CURRENT
(o directamente a
-STABLE
si el problema no existe en
-CURRENT
), asegurándose de hacer referencia al informe de problemas en su mensaje de commit (y dando el crédito al usuario si envió todo o parte del parche) y, si corresponde, iniciará una cuenta atrás de MFC. El error cambia al estado
Needs MFC
.
Si no se necesita integrar el parche desde current (MFC), Joe cierra el PR y lo marca con
Issue Resolved
.
|
Muchos PRs son enviados con muy poca información sobre el problema, y algunos son muy complejos de resolver, o simplemente arañan la superficie de un problema mayor; en estos casos, es muy importante obtener toda la información necesaria para resolver el problema. Si el problema no se puede resolver, o si ha ocurrido nuevamente, es necesario volver a abrir el PR. |
Es importante actualizar el estado de un PR cuando se realizan ciertas acciones. El estado debe reflejar con precisión la situación actual del trabajo en el PR.
Cuando un PR ha sido tratado y el desarrollador/es se sienta cómodo con la solución, enviará un follow-up al PR y cambiará su estado a "feedback". En este punto, el usuario que lo ha creado debe evaluar la solución en su contexto y responder indicando si el defecto ha sido solucionado.
Un Informe de Problema puede estar en uno de los siguientes estados:
Estado inicial; el problema ha sido indicado y necesita ser revisado.
El problema ha sido revisado y se está buscando una solución.
Hay que realizar trabajo adicional que requiere información adicional del usuario o de la comunidad; posiblemente información sobre la solución propuesta.
Se ha realizado un commit con el parche, pero aún hay algo pendiente (MFC, o tal vez confirmación del usuario que lo creó).
No se está trabajando en el problema debido a la falta de información o recursos. Este es un candidato excelente para alguien que está buscando un proyecto. Si el problema no se puede resolver, se cerrará, en lugar de suspenderse. El proyecto de documentación utiliza suspendido para los elementos de la lista de deseos que implican una cantidad significativa de trabajo para el cual nadie tiene tiempo actualmente.
Un informe de problemas se cierra cuando se han integrado, documentado y probado los cambios, o cuando se abandona la solución del problema.
|
El estado "patched" está directamente relacionado con el feedback, por lo que puede ir directamente al estado "closed" si el usuario que lo creó no puede probar el parche y funciona en sus propias pruebas. |
Al tratar con informes de problemas, ya sea como desarrollador que tiene acceso directo a la Base de Datos de Informes de Problemas o como colaborador que navega por la base de datos y envía follow-ups con parches, comentarios, sugerencias o solicitudes de cambio, encontrará varios tipos diferentes de PRs.
Las siguientes secciones describen para qué se usa cada tipo de PRs, cuándo un PR pertenece a uno de estos tipos y qué tratamiento recibe cada tipo.
Cuando los PRs llegan, inicialmente se asignan a un responsable genérico (placeholder). Estos siempre tienen el prefijo
freebsd-
. El valor exacto para este patrón depende de la categoría; en la mayoría de los casos, corresponde a una lista de correo específica de FreeBSD. Aquí está la lista actual, con las más comunes primero:
| Tipo | Categorías | Asignaciones Predeterminadas |
|---|---|---|
|
sistema base |
bin, conf, gnu, kern, misc |
freebsd-bugs |
|
específico de una arquitectura |
alpha, amd64, arm, i386, ia64, powerpc, sparc64 |
freebsd- arch |
|
colección de ports |
ports |
freebsd-ports-bugs |
|
documentación entregada con el sistema |
docs |
freebsd-doc |
|
Páginas web de FreeBSD (sin incluir docs) |
Website |
freebsd-www |
| Tipo | Categorías | Asignaciones Predeterminadas |
|---|---|---|
|
esfuerzos de apoyo y promoción |
advocacy |
freebsd-advocacy |
|
Problemas de la Máquina Virtual de Java (Java Virtual Machine™) |
java |
freebsd-java |
|
cumplimiento de estándares |
standards |
freebsd-standards |
|
librerías de hilos |
threads |
freebsd-threads |
|
subsistema usb(4) |
usb |
freebsd-usb |
No te sorprendas al descubrir que el usuario responsable del PR lo ha asignado a la categoría incorrecta. Si corriges la categoría, no te olvides de corregir también la asignación. (En particular, nuestros usuarios parecen tener dificultades para entender que aunque su problema ocurra en un sistema i386, podría ser genérico de todo FreeBSD y, por lo tanto, ser más adecuado para
kern
. Lo contrario también es cierto, por supuesto.)
Algunos PRs pueden ser reasignados lejos de estos responsables genéricos por cualquier persona. Hay varios tipos de responsables: listas de correo especializadas; alias de correo (utilizados para ciertos casos de interés limitado); y los individuos particulares.
Para los responsables que son listas de correo, utiliza la designación larga al realizar la asignación (por ejemplo,
freebsd-foo
en lugar de
foo
); esto evitará los mensajes de correo electrónico duplicados enviados a la lista de correo.
|
Como la lista de individuos que se han prestado voluntarios a ser los responsables por defecto de varios tipos de PR cambia tan frecuentemente, es mucho más útil para la wiki de FreeBSD . |
Aquí hay un listado de ejemplo de dichas entidades; probablemente no esté completo.
| Tipo | Categoría Sugerida | Responsable Sugerido | Tipo de Responsable |
|---|---|---|---|
|
problema específico de la arquitectura ARM® |
arm |
freebsd-arm |
lista de correo |
|
problema específico de la arquitectura MIPS® |
kern |
freebsd-mips |
lista de correo |
|
problema específico de la arquitectura PowerPC® |
kern |
freebsd-ppc |
lista de correo |
|
problema con la Configuración Avanzada y Gestión de Energía ( acpi(4) ) |
kern |
freebsd-acpi |
lista de correo |
|
problemas con los controladores del Modo de Transferencia Asíncrono (ATM) |
kern |
freebsd-atm |
lista de correo |
|
problema con sistemas FreeBSD embebidos o de pocos recursos (por ejemplo, NanoBSD/PicoBSD/FreeBSD-arm) |
kern |
freebsd-embedded |
lista de correo |
|
problema con controladores de FireWire® |
kern |
freebsd-firewire |
lista de correo |
|
problema con el código del sistema de ficheros |
kern |
freebsd-fs |
lista de correo |
|
problema con el subsistema geom(4) |
kern |
freebsd-geom |
lista de correo |
|
problema con el subsistema ipfw(4) |
kern |
freebsd-ipfw |
lista de correo |
|
problema con los drivers de Redes Digitales de Servicios Integrados (ISDN) |
kern |
freebsd-isdn |
lista de correo |
|
subsistema jail(8) |
kern |
freebsd-jail |
lista de correo |
|
problema con la emulación Linux® o SVR4 |
kern |
freebsd-emulation |
lista de correo |
|
problema con la pila de red |
kern |
freebsd-net |
lista de correo |
|
problema con el subsistema pf(4) |
kern |
freebsd-pf |
lista de correo |
|
problema con el subsistema scsi(4) |
kern |
freebsd-scsi |
lista de correo |
|
problema con el subsistema sound(4) |
kern |
freebsd-multimedia |
lista de correo |
|
problema con el subsistema wlan(4) y controladores wireless |
kern |
freebsd-wireless |
lista de correo |
|
problema con sysinstall(8) o bsdinstall(8) |
bin |
freebsd-sysinstall |
lista de correo |
|
problema con los scripts de arranque del sistema ( rc(8) ) |
kern |
freebsd-rc |
lista de correo |
|
problema relacionado con el código y la funcionalidad de VIMAGE o VNET |
kern |
freebsd-virtualization |
lista de correo |
|
problema con la emulación Xen |
kern |
freebsd-xen |
lista de correo |
| Tipo | Categoría Sugerida | Responsable Sugerido | Tipo de Responsable |
|---|---|---|---|
|
problema con la infraestructura de ports ( no con un port individual) |
ports |
portmgr |
alias |
|
port que está mantenido por apache@FreeBSD.org |
ports |
apache |
lista de correo |
|
port que es mantenido por autotools@FreeBSD.org |
ports |
autotools |
alias |
|
port que es mantenido por doceng@FreeBSD.org |
ports |
doceng |
alias |
|
port que es mantenido por eclipse@FreeBSD.org |
ports |
freebsd-eclipse |
lista de correo |
|
port que es mantenido por gecko@FreeBSD.org |
ports |
gecko |
lista de correo |
|
port que es mantenido por gnome@FreeBSD.org |
ports |
gnome |
lista de correo |
|
port que es mantenido por hamradio@FreeBSD.org |
ports |
hamradio |
alias |
|
port que es mantenido por haskell@FreeBSD.org |
ports |
haskell |
alias |
|
port que es mantenido por java@FreeBSD.org |
ports |
freebsd-java |
lista de correo |
|
port que es mantenido por kde@FreeBSD.org |
ports |
kde |
lista de correo |
|
port que es mantenido por mono@FreeBSD.org |
ports |
mono |
lista de correo |
|
port que es mantenido por office@FreeBSD.org |
ports |
freebsd-office |
lista de correo |
|
port que es mantenido por perl@FreeBSD.org |
ports |
perl |
lista de correo |
|
port que es mantenido por python@FreeBSD.org |
ports |
freebsd-python |
lista de correo |
|
port que es mantenido por ruby@FreeBSD.org |
ports |
freebsd-ruby |
lista de correo |
|
port que es mantenido por secteam@FreeBSD.org |
ports |
secteam |
alias |
|
port que es mantenido por vbox@FreeBSD.org |
ports |
vbox |
alias |
|
port que es mantenido por x11@FreeBSD.org |
ports |
freebsd-x11 |
lista de correo |
Los PRs relacionados con los ports que tienen un mantenedor que es a la vez un committer de ports pueden ser reasignados por cualquiera (pero ten en cuenta que no todo committer de FreeBSD es necesariamente un committer de ports, por lo que no puedes guiarte únicamente por la dirección de correo electrónico.)
Para otros PRs, por favor, no los reasignes a otros individuos (otros que no seas tú mismo), a menos que estés seguro de que el responsable realmente quiere mantenerse al tanto del PR. Esto ayudará a evitar situaciones en las que nadie se dedica a solucionar un problema en particular porque todos asumen que el responsable ya está trabajando en ello.
| Tipo | Categoría Sugerida | Responsable Sugerido | Tipo de Responsable |
|---|---|---|---|
|
problema con la base de datos de PRs |
bin |
bugmeister |
alias |
|
problema con el formulario web de Bugzilla. |
doc |
bugmeister |
alias |
Si un PR tiene el campo
responsible
establecido al nombre de usuario de un desarrollador de FreeBSD, significa que el PR ha sido traspasado a dicho individuo para realizar más trabajo.
Los PRs asignados no deben ser tocados por nadie más que el responsable o el bugmeister. Si tienes comentarios, envía un follow-up. Si, por algún motivo, crees que el PR debe cambiar de estado o ser reasignado, envía un mensaje al responsable. Si el responsable no responde en dos semanas, anula la asignación del PR y haz lo que quieras.
Si encuentras más de un PR que describe el mismo problema, elige el que contiene la mayor cantidad de información útil y cierre los demás, indicando claramente el número de PR sustituidos. Si varios PRs contienen información útil que no está repetida, envía toda la información restante en un follow-up, incluidas las referencias a los demás; luego cierra los otros PRs (que ahora han sido completamente reemplazados).
Un PR se considera obsoleto si no ha sido modificado en más de seis meses. Aplica el siguiente procedimiento para tratar los PRs obsoletos:
Si el PR contiene suficientes detalles, intenta reproducir el problema en
-CURRENT
y
-STABLE
. Si lo consigues, envía un followup detallando tus hallazgos e intenta encontrar a alguien a quien asignárselo. Cambia el estado a "analyzed" si procede.
Si el PR describe un problema que sabes que es el resultado de un error de uso (configuración incorrecta o de otro tipo), envía un follow-up que explique qué hizo mal el usuario, luego cierra el PR con el motivo "User error" o "Configuration error".
Si el PR describe un error que sabes que ha sido corregido tanto en
-CURRENT
como en
-STABLE
, ciérralo con un mensaje que indique que ha sido arreglado en cada rama.
Si el PR describe un error que sabes que ha sido corregido en
-CURRENT
, pero no en
-STABLE
, intenta averiguar cuándo piensa hacer el MFC la persona que lo corrigió, o intenta encontrar a alguien (¿quizás tú mismo?) para hacerlo. Cambia el estado a "patched" y asígnalo a quien vaya a hacer el MFC.
En otros casos, solicita al usuario que confirme si el problema persiste en las versiones más nuevas. Si el usuario no responde en un mes, cierra el PR con la anotación "Feedback timeout".
Los desarrolladores que se encuentran con PRs que parece que deberían haber sido enviados a la Lista de 'problem reports' de FreeBSD o alguna otra lista deberían cerrar el PR, informando al creador en un comentario que esto no es en realidad un PR y dónde se debería enviar el mensaje.
Las direcciones de correo electrónico que utiliza Bugzilla para recibir los PR se han publicado como parte de la documentación de FreeBSD, se han anunciado y se enumeran en el sitio web. Esto significa que los spammers las han encontrado.
Cuando cierres uno de estos PRs, haz lo siguiente:
Establece el componente a
junk
(bajo
Supporting Services
).
Establece Responsible a
nobody@FreeBSD.org
.
Cambia el estado a
Issue Resolved
.
Establecer la categoría a
junk
hace evidente que no hay contenido útil en el PR y ayuda a reducir la basura en las categorías principales.
Esta es una lista de recursos relacionados con la escritura y procesamiento adecuados de informes de error. No pretende ser una lista completa.
Cómo Escribir Informes de Error de FreeBSD -guía para los creadores de PR.
Last modified on : 6 de octubre de 2022 by Fernando Apesteguía