Guía para encargados de mantenimiento de Bazel

Informar un problema Ver fuente Por la noche · 7.4 de Google Cloud. 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 deseas contribuir a Bazel, lee Contributing to Bazel en su lugar.

Los objetivos de esta página son los siguientes:

  1. Servir como fuente de confianza de los encargados del mantenimiento 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 se dedicó a 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 ecológico: cultiva un ecosistema saludable de reglas y herramientas.
  • Developer Experience Gardeners: Incentiva las contribuciones externas, revisa. solicitudes de extracción y problemas, y hacer que nuestro flujo de trabajo de desarrollo sea más abierto.

Versiones

Integración continua

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

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 del subequipo de rotación de la experiencia del desarrollador (DevEx) revisa las 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 StackOverflow y bazel-debate para mayor visibilidad sobre la pregunta.
    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 poco claro o le falta información, el miembro de DevEx debe asignar nuevamente el problema al usuario para que solicite más información antes de y continúa. Esto suele ocurrir cuando el usuario no sigue el Problema Plantilla.
  3. Después de revisar el problema, el miembro de DevEx decide si el problema requiere atención inmediata. Si es así, se asignará el valor P0. etiqueta de prioridad 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 problemas específicos de Mac. En esta etapa, el problema ingresa al grupo de abiertas sin clasificar problemas.

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 es propietario de una etiqueta de equipo, consulte 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 una etiqueta a tu equipo y encontrar la mejor en la revisión por pares.
  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 el comunicado de prensa.
  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 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. Por este motivo, no fusionamos las relaciones públicas 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 un sello discográfico. ¿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 etiqueta de 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 las prioridades si es necesario.
    2. Cada problema debe tener exactamente una etiqueta de prioridad. Si un problema es P0 o P1, suponemos que se trabaja activamente.
  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 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 el comunicado de prensa.
  5. Asegúrate de que todas las pruebas se aprueben.
  6. Importa el parche al sistema de control de versión interno y ejecuta el envíos previos.
  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: Rotura mayor que hace que una versión de Bazel (menos las versiones candidatas) sea inutilizable o un servicio inactivo que afecta gravemente el desarrollo de la implementación en un proyecto final. 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 alternativa práctica.
  • P1: Defecto crítico que debería abordarse en la próxima versión, o bien un problema grave que afecta a muchos usuarios (incluido el desarrollo del proyecto Bazel), pero existe una solución alternativa práctica. Por lo general, no requiere una acción inmediata. En alta demanda y según lo previsto en la hoja de ruta del trimestre actual.
  • P2: Defecto o función eso debería solucionarse, pero actualmente no trabajamos en ello. 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.
  • heladería
      .
    • 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á cerrado.

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