Guía para encargados de mantenimiento de Bazel

Informar un problema Ver código fuente Nightly · 8.0 · 7.4 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Esta es una guía para los encargados del mantenimiento 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 de los mantenedores para el proceso de contribución del proyecto
  2. Establece expectativas entre los colaboradores de la comunidad y los manutendores 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 ni 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 pertenece a la comunidad, como rules_apple, el miembro de DevEx transferirá este problema al repositorio correcto.
    3. Si el problema es vago o falta información, el miembro de DevEx le asignará el problema 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í, asignarán 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. 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 asignar.

Cada subequipo de Bazel clasificará todos los problemas según las etiquetas que tengan, preferentemente semanalmente. El subequipo revisará y evaluará el problema y, si es posible, proporcionará una resolución. 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 cambios para tu propia área, es tu responsabilidad asignar la etiqueta de tu equipo y encontrar al mejor revisor.
  3. De lo contrario, durante el triaje diario, 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 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 imports las confirmaciones de la PR 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 de forma interna en Google, debemos probar todas las confirmaciones de PR en el conjunto de pruebas interno. Esta es la razón por la que no combinamos las PR directamente.
  6. Si la confirmación importada pasa todas las pruebas internas, se unificará 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 una etiqueta. ¿Qué debo hacer?

Los subequipos deben clasificar todos los problemas de 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 asígnale la etiqueta.
    1. Es posible que el subequipo de DevEx ya haya priorizado el problema si es un P0. Vuelve a establecer prioridades 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 en él 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 la etiqueta de tu equipo.
  2. Revisa las solicitudes de extracción abiertas.
    1. Opcional: Si te asignaron la revisión, pero no es adecuada para ti, vuelve a asignar a la persona adecuada para que realice una 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. Aprueba 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 al envío internas.
  7. Envía el parche interno. Si el parche se envía y exporta correctamente, GitHub cerrará automáticamente la PR.

Prioridad

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

  • P0: Una funcionalidad principal dañada que hace que una versión de Bazel (menos las versiones candidatas) sea inutilizable o un servicio inactivo que afecta gravemente el desarrollo del proyecto de Bazel. Esto incluye las regresiones que se introducen en una versión nueva que bloquea a una cantidad significativa de usuarios o un cambio rotundo incompatible que no cumple con la política de Cambio rotundo. No existe una solución práctica.
  • P1: Defecto o función críticos que se deben abordar en la próxima versión, o un problema grave que afecta a muchos usuarios (incluido el desarrollo del proyecto Bazel), pero existe una solución práctica. Por lo general, no requiere una acción inmediata. Si hay una gran demanda y se planifica en la planificación del trimestre actual.
  • P2: Defecto o función que se debe abordar, pero en la que no estamos trabajando actualmente. Problema activo moderado en una versión publicada de Bazel que es inconveniente para un usuario y que se debe abordar en una versión futura o existe una solución alternativa fácil.
  • P3: Corrección de errores menores o mejora con un impacto pequeño. No se priorizan en los planes de Bazel ni en ninguna versión inminente. Sin embargo, se fomentan 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 repriorización si se ven afectados más usuarios.
  • ice-box
    • Problemas que, en este momento, no tenemos tiempo para resolver 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 se ven afectadas 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 del equipo.

Consulta la lista completa de etiquetas aquí.