Guía para encargados de mantenimiento de Bazel

Informar un problema Ver fuente Noche}

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.

Los objetivos de esta página son los siguientes:

  1. Servir como fuente de confianza de los encargados de mantener el proceso de contribución del proyecto
  2. Establecer las expectativas entre los colaboradores de la comunidad y los encargados de mantener el proyecto.

El grupo principal de colaboradores de Bazel cuenta con 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 ecológico: cultiva un ecosistema saludable de reglas y herramientas.
  • Developer Experience Gardeners: Incentiva 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 Green sobre la infraestructura de CI de Bazel en el repositorio de bazelbuild/continuous- integration.

Ciclo de vida de un problema

  1. Para crear un problema, un usuario elige una de las plantillas de problemas y, luego, ingresa al grupo de problemas abiertos sin revisar.
  2. Un miembro del subequipo de rotación de la experiencia del desarrollador (DevEx) revisa el problema.
    1. Si el problema no es un error o una solicitud de función, por lo general, el miembro de DevEx lo cerrará y redireccionará al usuario a StackOverflow y bazel-debate para mayor visibilidad sobre la pregunta.
    2. Si el problema pertenece a uno de los repositorios de reglas que son propiedad de 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 asignará el problema al usuario para solicitar más información antes de continuar. Esto suele ocurrir cuando el usuario no elige la plantilla de problemas {: .external} o proporciona información incompleta.
  3. Después de revisar el problema, el miembro de DevEx decide si el problema requiere atención inmediata. Si es así, se 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 platform:apple para problemas específicos de Mac.
  7. Si el problema es de 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 bajo sus etiquetas de propiedad, preferiblemente 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 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 un PR en tu propia área, debes asignar una etiqueta a 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 las RR.PP. y trabaja con el autor hasta que se aprueba o se descarta.
  5. Si se aprueba, el revisor importa las confirmaciones de las PR al sistema de control de versión 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 PR con el conjunto de pruebas internas. Por este motivo, no fusionamos las relaciones públicas directamente.
  6. Si la confirmación importada pasa todas las pruebas internas, la confirmación se aplasará y se exportará de nuevo a GitHub.
  7. Cuando la confirmación se combina con la instancia 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, en lo posible, de forma semanal.

Con 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 asigna la etiqueta.
    1. Es posible que el subequipo de DevEx ya haya priorizado el problema si se trata de 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 está trabajando activamente en él.
  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 etiqueta de tu equipo.
  2. Revisar las solicitudes de extracción abiertas
    1. Opcional: Si se te asigna la revisión, pero no es la opción adecuada para ella, reasigna al revisor adecuado 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 del código.
  4. Aprueba el comunicado de prensa.
  5. Asegúrate de que todas las pruebas sean exitosas.
  6. Importa el parche al sistema de control de versión interno y ejecuta los envíos previos internos.
  7. Envía el parche interno. Si el parche se envía y exporta correctamente, GitHub cerrará automáticamente la solicitud de extracción.

Prioridad

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

  • P0: Funcionalidad dañada importante que hace que una versión de Bazel (menos las versiones candidatas) no se pueda usar o un servicio inactivo que afecta de forma grave el desarrollo del proyecto de Bazel. Esto incluye las regresiones que se agregaron en una versión nueva que bloquea una cantidad significativa de usuarios o un cambio rotundo incompatible que no cumplía con la política de Cambio rotundo. No existe una solución alternativa práctica.
  • P1: Defecto crítico o función que debe solucionarse 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 práctica. Por lo general, no requiere ninguna acción inmediata. Tiene una demanda alta y está previsto en la hoja de ruta del trimestre actual.
  • P2: Defecto o función que debería solucionarse, pero no trabajamos en ello en este momento. Problema activo moderado en una versión de Bazel lanzada que no es conveniente para un usuario que necesita abordarse en una versión futura o que existe una solución alternativa sencilla.
  • P3: Corrección o mejora deseada de errores menores con pequeño impacto. No se priorizan en las hojas de ruta de Bazel ni en cualquier lanzamiento inminente. Sin embargo, recomendamos las contribuciones de la comunidad.
  • P4: Defecto de baja prioridad o solicitud de función que tiene pocas probabilidades de cerrarse. También se puede mantener abierta para una posible nueva prioridad si se ven afectados más usuarios.
  • heladería
    • Problemas de los que actualmente no tenemos tiempo de abordar ni aceptar contribuciones. Cerraremos estos problemas para indicar que nadie está trabajando en ellos, pero seguiremos supervisando su validez a lo largo del tiempo y los recuperaremos si hay suficientes personas afectadas y si tenemos recursos para lidiar con ellas. Como siempre, puedes comentar o agregar reacciones a estos problemas, incluso cuando se cierren.

Etiquetas de equipo

Por problemas nuevos, dimos de baja las etiquetas category: * para dar lugar a las etiquetas del equipo.

Consulta la lista completa de etiquetas aquí.