Guía para encargados de mantenimiento de Bazel

Compilación nocturna · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

Si quieres contribuir a Bazel, consulta Cómo contribuir a Bazel.

Los objetivos de esta página son los siguientes:

  1. Servir como fuente de información para los mantenedores sobre el proceso de contribución del proyecto
  2. Establece expectativas entre los colaboradores de la comunidad y los mantenedores del proyecto.

El grupo principal de colaboradores de Bazel tiene subequipos dedicados a administrar aspectos del proyecto de código abierto. Debes realizar las siguientes acciones:

  • Proceso de lanzamiento: Administra el proceso de lanzamiento de Bazel.
  • Equipo verde: Supervisa el estado de la CI de Bazel y genera informes sobre las fallas.
  • Jardineros de la experiencia del desarrollador: Fomentan las contribuciones externas, revisan los problemas y las solicitudes de extracción, y hacen que nuestro flujo de trabajo de desarrollo sea más abierto.

Versiones

Integración continua

Lee la guía del equipo verde 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 eligiendo una de las plantillas de problemas, y este se agrega 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 o una solicitud de función, el miembro de DevEx suele cerrar el problema y redireccionar al usuario a StackOverflow y bazel-discuss para que la pregunta tenga mayor visibilidad.
    2. Si el problema pertenece a uno de los repositorios de reglas que posee la comunidad, como rules_apple, el miembro de DevEx transferirá el problema al repositorio correcto.
    3. Si el problema es vago o le falta información, el miembro del equipo de DevEx se lo reasignará al usuario para solicitarle más información antes de continuar. Esto suele ocurrir cuando el usuario no elige la plantilla de problema {: .external} correcta o proporciona información incompleta.
  3. Después de revisar el problema, el miembro de DevEx decide si requiere atención inmediata. Si es así, le asignarán la etiqueta de P0 y un propietario de la lista de líderes de equipo.
  4. El miembro de DevEx asigna la etiqueta untriaged y exactamente una etiqueta de equipo para el enrutamiento.
  5. El miembro del equipo de DevEx también asigna exactamente una etiqueta type:, como type: bug o type: feature request, según el tipo de problema.
  6. En el caso de los problemas específicos de la plataforma, el miembro de DevEx asigna una etiqueta platform:, como platform:apple para los problemas específicos de Mac.
  7. Si el problema tiene baja prioridad y un nuevo colaborador de la comunidad puede trabajar en él, el miembro de DevEx asigna la etiqueta good first issue. En esta etapa, el problema ingresa al grupo de problemas abiertos sin clasificación.

Cada subequipo de Bazel clasificará todos los problemas que se encuentren bajo las etiquetas que le pertenecen, preferentemente de forma semanal. El subequipo revisará y evaluará el problema, y proporcionará una resolución, si es posible. Si eres propietario de un sello discográfico 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 una PR en tu propia área, eres responsable de asignar la etiqueta de tu equipo y encontrar al mejor revisor.
  3. De lo contrario, durante la clasificación diaria, un miembro de DevEx asigna una etiqueta de equipo y el líder técnico (TL) del equipo para el enrutamiento.
    1. Opcionalmente, el TL puede asignar a otra persona para que revise la PR.
  4. El revisor asignado revisa la solicitud de extracción y trabaja con el autor hasta que se aprueba o se descarta.
  5. Si se aprueba, el revisor importa las confirmaciones de la PR en el sistema interno de control de versiones 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 la PR con el conjunto de pruebas interno. Este es el motivo por el que no combinamos las PR directamente.
  6. Si la confirmación importada pasa todas las pruebas internas, se comprimirá y se volverá a exportar a GitHub.
  7. Cuando la confirmación se combina en la rama principal, GitHub cierra automáticamente la solicitud de extracción.

Mi equipo es propietario de un sello discográfico. ¿Qué debo hacer?

Los subequipos deben priorizar todos los problemas en las etiquetas que poseen, preferentemente de forma semanal.

Problemas

  1. Filtra la lista de problemas por la etiqueta de tu equipo y la etiqueta untriaged.
  2. Revisa el problema.
  3. Identifica un nivel de prioridad y asigna la etiqueta.
    1. Es posible que el subequipo de DevEx ya haya priorizado el problema si se trata de un P0. Reasigna prioridades si es necesario.
    2. Cada problema debe tener exactamente una etiqueta de prioridad. Si un problema es de prioridad P0 o P1, suponemos que se está trabajando en él de forma activa.
  4. Quita la etiqueta untriaged.

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

Solicitudes de extracción

Las solicitudes de extracción (PR) son la principal forma en que los colaboradores externos agregan valor a Bazel. Como proyecto de código abierto, es importante garantizar que las PR se revisen y se gestionen de manera oportuna y eficiente.

  • Evaluación

    Revisa periódicamente las solicitudes de extracción entrantes con la etiqueta awaiting-review y la etiqueta de tu equipo. Esto se puede hacer con una rotación o una reunión de triage periódica. Esperamos que cada solicitud de relaciones públicas reciba una respuesta inicial en un plazo de 7 días hábiles.

  • Respuesta

    • Si la PR se ve bien, aprueba y aplica la etiqueta awaiting-PR-merge. El equipo de gTech importará la PR como una CL.
    • De lo contrario, deja tus comentarios y reemplaza la etiqueta awaiting-review por la etiqueta awaiting-user-response. El subequipo de DevEx actualizará la etiqueta con regularidad si el autor de la PR responde.
    • En el caso de las PR con cambios importantes, considera solicitar un documento de diseño o una conversación previa en un problema.

  • Cierre

    Debido a los recursos limitados, es importante cerrar las PR que no cumplen con los estándares de Bazel o que no tenemos la capacidad de revisar o mantener.

    • Si la solicitud de extracción no se alinea con los objetivos de Bazel, ciérrala con una explicación.
    • Si la PR es demasiado grande y compleja, ciérrala y solicita que se divida en partes más pequeñas.
    • Si la calidad del código de la PR no cumple con nuestros estándares, ciérrala con una explicación.
    • Si el costo de mantenimiento futuro del código es demasiado alto, ciérralo con una explicación.
    • Si la PR ha estado esperando la respuesta del usuario durante mucho tiempo y el colaborador no respondió, se marcará automáticamente como obsoleta después de 30 días y se cerrará después de otros 30 días.

    Cuando cierres una PR, sé cortés y explica el motivo del cierre.

Prioridad

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

  • P0: Es una funcionalidad principal dañada que hace que una versión de Bazel (excepto las versiones candidatas) sea inutilizable o un servicio inactivo que afecta gravemente el desarrollo del proyecto de Bazel. Esto incluye las regresiones introducidas en una versión nueva que bloquean a una cantidad significativa de usuarios o un cambio rotundo incompatible que no cumplía con la política de Cambios Rotundos. No existe una solución alternativa práctica.
  • P1: Es un defecto o una función críticos que se deben abordar en la próxima versión, o bien un problema grave que afecta a muchos usuarios (incluido el desarrollo del proyecto de Bazel), pero existe una solución alternativa práctica. Por lo general, no requiere una acción inmediata. Tiene una alta demanda y está planificada en la hoja de ruta del trimestre actual.
  • P2: Es un defecto o una función que se debe abordar, pero en la que no estamos trabajando actualmente. Problema moderado en vivo en una versión de Bazel lanzada que es inconveniente para un usuario y que debe abordarse en una versión futura o existe una solución alternativa sencilla.
  • P3: Corrección de errores o mejora menor deseable con un impacto pequeño. No se prioriza en las hojas de ruta de Bazel ni en ninguna versión inminente, pero se recomiendan las contribuciones de la comunidad.
  • P4: Defecto de prioridad baja o solicitud de función que es poco probable que se cierre. También se puede mantener abierto para una posible reasignación de prioridad si se ven afectados más usuarios.

Etiquetas del equipo

En el caso de los problemas nuevos, dimos de baja las etiquetas category: * y las reemplazamos por las etiquetas de equipo.

Consulta la lista completa de etiquetas aquí.