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 de mantener el 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 los encargados de mantenimiento fuente fiable para la contribución del proyecto el proceso de administración de recursos.
  2. Establecer las expectativas entre los colaboradores de la comunidad y el proyecto mantenedores.

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 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 entra al grupo de registros no revisados problemas.
  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 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 pertenecen al 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 elige la plantilla de problema correcta {: .external} 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 problemas específicos de la plataforma, el miembro de DevEx asigna una etiqueta platform:, como problemas específicos de platform:apple para Mac.
  7. Si el problema es de baja prioridad y se puede resolver con otra comunidad colaborador, el miembro de DevEx asigna la etiqueta good first issue. En esta etapa, el problema ingresa al grupo de problemas abiertos sin asignar.

Cada subequipo de Bazel clasificará todos los problemas bajo sus etiquetas, preferentemente en una 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 un problema se resuelve, 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 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. Esta es la razón por la que no combinamos las PR directamente.
  6. Si la confirmación importada pasa todas las pruebas internas, la confirmación se aplasará. y exportarlos de nuevo 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 asigna la etiqueta.
    1. Es posible que el subequipo de DevEx ya haya priorizado el problema si se trata de 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 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 la PR.
  5. Asegúrate de que todas las pruebas sean exitosas.
  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 las RR.PP.

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 regresiones introducidas en una nueva versión que bloquea una una cantidad significativa de usuarios o un cambio rotundo cumple con el Informe de Cambiar . No existe una solución alternativa 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. En alta demanda y según lo previsto en la hoja de ruta 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: Error menor deseado corregir o mejorar con un impacto pequeño. No se priorizan en las hojas de ruta de Bazel o cualquier lanzamiento inminente. Sin embargo, 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 repriorización si se ven afectados más usuarios.
  • heladería
      .
    • Problemas de los que actualmente no tenemos tiempo 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

Por problemas nuevos, dimos de baja las etiquetas category: * para dar lugar al equipo. con etiquetas de recursos.

Consulta la lista completa de etiquetas aquí.