Guía para encargados de mantenimiento de Bazel

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

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 confianza para los mantenedores en relación con el proceso de contribución del proyecto
  2. Establecer expectativas entre los colaboradores de la comunidad y los mantenedores del proyecto

El grupo principal de colaboradores de Bazel tiene subequipos dedicados para 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: Desarrolla un ecosistema saludable de reglas y herramientas.
  • Jardineros de la experiencia del desarrollador: 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.

Lanzamientos

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 ingresa al grupo de problemas abiertos sin revisar.
  2. Un miembro de la rotación del subequipo de Experiencia del desarrollador (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 obtener una mayor visibilidad de la pregunta.
    2. Si el problema pertenece a uno de los repositorios de reglas que posee la comunidad, como rules_apple, el miembro de DevEx transferirá este problema al repositorio correcto.
    3. Si el problema es vago o le falta información, el miembro de DevEx volverá a asignárselo al usuario para solicitar más información antes de continuar. Esto suele ocurrir cuando el usuario no elige la plantilla de problemas 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í, asignará la etiqueta de prioridad 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 de DevEx también asigna exactamente una etiqueta type:, como type: bug o type: feature request, según el tipo de problema.
  6. Para 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 clasificar.

Cada subequipo de Bazel clasificará todos los problemas en las etiquetas que posee, 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 una solicitud de extracción 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. De manera opcional, el TL puede asignar a otra persona para que revise la solicitud de extracción.
  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 solicitud de extracción al sistema de control de versiones 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 la solicitud de extracción en el conjunto de pruebas interno. Este es el motivo por el que no combinamos las solicitudes de extracción directamente.
  6. Si la confirmación importada pasa todas las pruebas internas, se combinará 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 posee una etiqueta. ¿Qué debo hacer?

Los subequipos deben clasificar 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 es un P0. Vuelve a priorizarlo si es necesario.
    2. Cada problema debe tener exactamente una etiqueta de prioridad. Si un problema es P0 o P1, suponemos que se está trabajando activamente en él.
  4. Quita la etiqueta untriaged.

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

Solicitudes de extracción

  1. Filtra la lista de solicitudes de extracción por la etiqueta de tu equipo.
  2. Revisa las solicitudes de extracción abiertas.
    1. Opcional: Si se te asigna la revisión, pero no es la adecuada para ello, vuelve a asignar al revisor correspondiente para que realice una revisión del código.
  3. Trabaja con el creador de la solicitud de extracción para completar una revisión del código.
  4. Aprueba la solicitud de extracción.
  5. Asegúrate de que todas las pruebas se aprueben.
  6. Importa el parche al sistema de control de versiones interno y ejecuta las confirmaciones previas internas.
  7. Envía el parche interno. Si el parche se envía y se exporta correctamente, GitHub cerrará automáticamente la solicitud de extracción.

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 regresiones introducidas en una versión nueva que bloquea 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 fundamental que se debe abordar en la próxima versión, o 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 gran demanda y está planificado 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. Es un problema moderado en una versión de Bazel lanzada que es inconveniente para un usuario y que se debe abordar en una versión futura o existe una solución alternativa sencilla.
  • P3 : Es una corrección de errores o una mejora menor deseable con un impacto pequeño. No se prioriza en las hojas de ruta de Bazel ni en ningún lanzamiento inminente. Sin embargo, se recomiendan las contribuciones de la comunidad.
  • P4 : Es un defecto de baja prioridad o una solicitud de función que es poco probable que se cierre. También se puede mantener abierto para una posible nueva priorización si se ven afectados más usuarios.

Etiquetas de equipo

Para los problemas nuevos, dejamos de usar las etiquetas category: * en favor de las etiquetas de equipo.

Consulta la lista completa de etiquetas aquí.