Guía para el Manejo de Informes de Problemas

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.

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.

Un Informe de Problema puede estar en uno de los siguientes estados:

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:

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.

Aquí hay un listado de ejemplo de dichas entidades; probablemente no esté completo.

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.

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:

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:

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.