Guía para encargados de mantenimiento de Bazel

Informar un problema Ver código fuente Nocturno · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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 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: Desarrolla un ecosistema saludable de reglas y herramientas.
  • 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 con la plantilla de problemas y este 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 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 sigue la plantilla de problemas.
  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. 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 PR 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 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 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 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

  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 asignó la revisión, pero no eres la persona adecuada para realizarla, vuelve a asignar al revisor apropiado 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 de código.
  4. Aprobar la PR
  5. Asegúrate de que todas las pruebas se aprueben.
  6. Importa el parche al sistema de control de versiones interno y ejecuta las verificaciones previas internas.
  7. Envía el parche interno. Si el parche se envía y exporta correctamente, GitHub cerrará la PR automáticamente.

Prioridad

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

  • P0: Es una falla grave en la funcionalidad que hace que una versión de Bazel (sin incluir las versiones candidatas) sea inutilizable o un servicio inactivo que afecte 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 ningún lanzamiento 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.
  • ice-box
    • Problemas con los que no tenemos tiempo para lidiar ni para aceptar contribuciones. Cerraremos estos problemas para indicar que nadie está trabajando en ellos, pero seguiremos supervisando su validez con el tiempo y los reactivaremos si afectan a suficientes personas y si tenemos recursos para abordarlos. Como siempre, no dudes en comentar o agregar reacciones a estos problemas, incluso cuando estén cerrados.

Etiquetas de 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í.