Guía para encargados de mantenimiento de Bazel

Esta es una guía para los encargados de mantenimiento del proyecto de código abierto de Bazel.

Si deseas contribuir con Bazel, consulta Cómo contribuir a Bazel.

Los objetivos de esta página son los siguientes:

  1. Sirven como fuente de información de los encargados del mantenimiento para el proceso de contribución del proyecto.
  2. Establece expectativas entre los colaboradores de la comunidad y los encargados del mantenimiento del proyecto.

El grupo principal de colaboradores de Bazel tiene subequipos dedicados para administrar aspectos del proyecto de código abierto. que son los siguientes:

  • Proceso de lanzamiento: Administra el proceso de lanzamiento de Bazel.
  • Equipo ecológico: Desarrolla un ecosistema saludable de reglas y herramientas.
  • Jardineros de la experiencia para desarrolladores: Fomenta las contribuciones externas, revisa los problemas y las solicitudes de extracción, y haz que nuestro flujo de trabajo de desarrollo sea más abierto.

Versiones

Integración continua

Lee la guía del equipo de Green sobre la infraestructura de CI de Bazel en el repositorio bazelbuild/continuous- integration.

Ciclo de vida de un problema

  1. Un usuario crea un problema con la Plantilla del problema y, luego, ingresa al grupo de problemas abiertos sin revisar.
  2. Un miembro de la rotación del subequipo de Experiencia para desarrolladores (DevEx) revisa el problema.
    1. Si el problema no es un error ni una solicitud de función, por lo general, el miembro de DevEx cerrará el problema y redireccionará al usuario a StackOverflow y bazel-discuss para obtener mayor visibilidad de la pregunta.
    2. Si el problema pertenece a uno de los repositorios de reglas que pertenecen a la comunidad, como rules_apple, el miembro de DevEx transferirá este problema al repositorio correcto.
    3. Si el problema es impreciso o le falta información, el miembro de DevEx volverá a asignar el problema al usuario para solicitar más información antes de continuar. Esto suele ocurrir cuando el usuario no sigue la Plantilla del problema.
  3. Después de revisar el problema, el miembro de DevEx decide si el problema requiere atención inmediata. Si lo hace, asignará la etiqueta de prioridad P0 y un propietario de la lista de líderes del equipo.
  4. El miembro de DevEx asigna la etiqueta untriaged y exactamente una etiqueta de equipo para el enrutamiento.
  5. El miembro de DevEx también asigna exactamente una etiqueta type:, como type: bug o type: feature request, según el tipo de problema.
  6. Para problemas específicos de la plataforma, el miembro de DevEx asigna una etiqueta platform:, como platform:apple para problemas específicos de Mac. En esta etapa, el problema entra en el conjunto de problemas abiertos no clasificados.

Cada subequipo de Bazel clasificará todos los problemas con sus etiquetas, preferentemente de forma semanal. El subequipo revisará y evaluará el problema, y proporcionará una resolución, si es posible. Si eres propietario de una etiqueta de equipo, consulta esta sección para obtener más información.

Cuando se resuelve un problema, se puede cerrar.

Ciclo de vida de una solicitud de extracción

  1. Un usuario crea una solicitud de extracción.
  2. Si eres miembro de un equipo de Bazel y envías un PR contra tu propia área, eres responsable de asignar la etiqueta de tu equipo y encontrar al mejor revisor.
  3. De lo contrario, durante la evaluación diaria, un miembro de DevEx asigna una etiqueta de equipo y el líder técnico (TL) del equipo para el enrutamiento.
    1. De manera opcional, el TL puede asignar a otra persona para que revise el documento de relaciones públicas.
  4. El revisor asignado revisa el contenido y trabaja con el autor hasta que se aprueba o descarta.
  5. Si se aprueba, el revisor importa las confirmaciones de la solicitud de extracción al sistema de control de versión interno de Google para realizar más pruebas. Como Bazel es el mismo sistema de compilación que se usa internamente en Google, debemos probar todas las confirmaciones de relaciones públicas con el paquete de pruebas internas. Este es el motivo por el que no fusionamos directamente las solicitudes de respuestas.
  6. Si la confirmación importada pasa todas las pruebas internas, la confirmación se comprimirá y se volverá a exportar a GitHub.
  7. Cuando la confirmación se combina con la instancia principal, GitHub cierra automáticamente la solicitud de extracción.

Mi equipo es propietario de una etiqueta. ¿Qué debo hacer?

Los subequipos deben clasificar todos los problemas en sus etiquetas, preferentemente de forma semanal.

Issues

  1. Filtra la lista de problemas por las etiquetas de equipo y untriaged.
  2. Revisa el problema.
  3. Identifica un nivel de prioridad y asígnale una etiqueta.
    1. Es posible que el subequipo de DevEx ya haya priorizado el problema si es P0. Vuelve a priorizar si es necesario.
    2. Cada problema debe tener exactamente una etiqueta de prioridad. Si un problema es P0 o P1, suponemos que se soluciona de forma activa.
  4. Quita la etiqueta untriaged.

Ten en cuenta que debes estar en la organización de bazelbuild para poder agregar o quitar etiquetas.

Solicitudes de extracción

  1. Filtra la lista de solicitudes de extracción por etiqueta de equipo.
  2. Revisa las solicitudes de extracción abiertas.
    1. Opcional: Si se te asignó para la revisión, pero no es la opción adecuada para ella, reasigna al revisor adecuado para que realice la revisión de código.
  3. Trabaja con el creador de la solicitud de extracción para completar una revisión de código.
  4. Aprobar el comunicado de prensa
  5. Asegúrate de que todas las pruebas sean exitosas.
  6. Importa el parche al sistema de control de versión interno y ejecuta los envíos previos internos.
  7. Envía el parche interno. Si el parche se envía y exporta de forma correcta, GitHub cerrará automáticamente la PR.

Prioridad

Los encargados de mantenimiento usarán las siguientes definiciones de prioridad para clasificar los problemas.

  • P0: Funcionalidad dañada importante que provoca que una versión de Bazel (menos las versiones candidatas) quede inutilizable o un servicio inactivo que afecta gravemente el desarrollo del proyecto de Bazel. Esto incluye regresiones introducidas en una versión nueva que bloquea una cantidad significativa de usuarios o un cambio rotundo incompatible que no cumplía con la política de Cambio rotundo. No existe una solución alternativa práctica.
  • P1: Defecto crítico o función que debería abordarse en la próxima versión, o problema grave que afecta a muchos usuarios (incluido el desarrollo del proyecto de Bazel), pero existe una solución práctica alternativa. Por lo general, no requiere ninguna acción inmediata. Están en alta demanda y están planificados en la hoja de ruta del trimestre actual.
  • P2: Defecto o función que debe solucionarse, pero que no trabajamos en este momento. Problema activo moderado en una versión de Bazel lanzada, que es incómodo para un usuario que debe abordarse en una versión futura o que existe una solución alternativa sencilla.
  • P3: Se desea una corrección o mejora de errores menores con un pequeño impacto. No se prioriza en las hojas de ruta de Bazel ni en ningún lanzamiento inminente, pero se recomiendan las contribuciones de la comunidad.
  • P4: Defecto de baja prioridad o solicitud de función que es poco probable que se cierre. También se puede mantener abierto para una posible repriorización si más usuarios se ven afectados.
  • ice-box
    • Problemas que actualmente no tenemos tiempo para tratar ni tiempo para aceptar contribuciones. Cerraremos estos problemas para indicar que nadie está trabajando en ellos, pero seguiremos supervisando su validez con el tiempo y recupéndolos si afecta a una cantidad suficiente de personas y si contamos con recursos para lidiar con ellos. Como siempre, puedes comentar o agregar reacciones a estos problemas, incluso cuando se cierren.

Etiquetas de equipo

Para los problemas nuevos, las etiquetas category: * dejaron de estar disponibles y se reemplazaron por las etiquetas de equipo.

Consulta la lista completa de sellos discográficos aquí.