Guía para encargados de mantenimiento de Bazel

Esta es una guía para quienes mantengan el proyecto de código abierto Bazel.

Si deseas contribuir a Bazel, consulta Contribuye a Bazel.

Los objetivos de esta página son los siguientes:

  1. Actúa como la fuente de información para el mantenimiento de las contribuciones del proyecto.
  2. Establecer expectativas entre los colaboradores de la comunidad y los encargados de mantener el proyecto

El grupo principal de colaboradores de Bazel tiene subequipos dedicados a administrar los aspectos del proyecto de código abierto. que son los siguientes:

  • Proceso de lanzamiento: administra el proceso de lanzamiento de Bazel.
  • Equipo ecológico: Desarrolla un ecosistema saludable de reglas y herramientas.
  • Jardines de experiencia para desarrolladores: 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.

Versiones

Integración continua

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

Ciclo de vida de un problema

  1. Un usuario crea un problema mediante la plantilla de problemas y, luego, ingresa al grupo de problemas abiertos sin revisar.
  2. Un miembro de la rotación del subequipo de la experiencia del desarrollador (DevEx) revisa el problema.
    1. Si el problema no es un error o una solicitud de función, el miembro de DevEx, en general, cierra el problema y redirecciona al usuario a Stack Overflow y bazel-analyze para obtener una mayor visibilidad de la pregunta.
    2. Si el problema pertenece a uno de los repositorios de reglas que posee la comunidad, como rules_apple, el miembro de DevEx transferirá este problema al repositorio correcto.
    3. Si el problema es impreciso o no contiene más 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 el problema requiere atención inmediata. Si lo hace, se asignará la etiqueta 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 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 problemas abiertos sin clasificar.

Cada subequipo de Bazel clasificará todos los problemas de las etiquetas que posea, preferentemente, de forma semanal. El subequipo revisará y evaluará el problema y proporcionará una solución, si es posible. Si eres el 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 RR.PP. a tu propia área, tienes la responsabilidad de asignar la etiqueta de tu equipo y encontrar el mejor visualizador.
  3. De lo contrario, durante el triaje diario, un miembro de DevEx asigna una etiqueta de equipo y el líder técnico del equipo (TL) para el enrutamiento.
    1. Opcionalmente, el TL puede asignar a otra persona para que revise la PR.
  4. El revisor asignado revisa la RR.PP. y trabaja con el autor hasta que se apruebe o se descarte.
  5. Si se aprueba, el revisor importa las confirmaciones de RR.PP. en el sistema de control de versión interno de Google para realizar más pruebas. Dado que Bazel es el mismo sistema de compilación que se usa de forma interna en Google, debemos probar todas las confirmaciones de RR.PP. con el conjunto de pruebas internas. Por esta razón, no fusionamos las RR.PP. directamente.
  6. Si la confirmación importada pasa todas las pruebas internas, se confirmará y se exportará a GitHub.
  7. Cuando la confirmación se combina con la instancia principal, GitHub cierra la PR automáticamente.

Mi equipo es propietario de un sello discográfico. ¿Qué debo hacer?

Los subequipos deben clasificar todos los problemas en las etiquetas de su propiedad, preferentemente, de forma semanal.

Issues

  1. Filtre la lista de problemas por etiqueta de equipo y la etiqueta untriaged.
  2. Revisa el problema.
  3. Identifique un nivel de prioridad y asigne la etiqueta.
    1. Es posible que el subequipo de DevEx ya haya priorizado el problema si es un P0. Vuelve a priorizar si es necesario.
    2. Cada problema debe tener exactamente una etiqueta de prioridad. Si un problema es P0 o P1, suponemos que está trabajando 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. Filtrar la lista de solicitudes de extracción según la etiqueta de tu equipo
  2. Revisa las solicitudes de extracción abiertas.
    1. Opcional: Si se te asigna para la revisión, pero no es la opción adecuada, reasígnale 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. Aprobar el PR.
  5. Asegúrate de que todas las pruebas se aprueben.
  6. Importa el parche al sistema de control de versión interno y ejecuta los envíos previos internos.
  7. Envíe el parche interno. Si el parche se envía y se exporta correctamente, GitHub lo cerrará automáticamente.

Prioridad

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

  • P0: Funcionalidad grave dañada que causa que una versión de Bazel (menos las versiones candidatas) no se pueda usar o un servicio caído que afecta gravemente el desarrollo del proyecto de Bazel. Esto incluye las regresiones presentadas en una versión nueva que bloquea una cantidad significativa de usuarios o un cambio rotundo incompatible que no cumple con la política sobre cambios rotundos. No existe una solución alternativa práctica.
  • P1: Un defecto crítico o una función que se debe abordar en la próxima versión o un problema grave que afecte a muchos usuarios (incluido el desarrollo del proyecto de Bazel), pero existe una solución alternativa práctica. Por lo general, no se requiere ninguna acción inmediata. Con alta demanda y planificado 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 trabajamos actualmente. Problemas moderados en vivo en una versión de Bazel que no es conveniente para un usuario y debe abordarse en una versión futura o si existe una solución alternativa sencilla.
  • P3: corrección o corrección de errores menores deseados con impacto leve. No se priorizan los planes de desarrollo de Bazel ni cualquier lanzamiento inminente; sin embargo, se recomienda la contribución de la comunidad.
  • P4: Es un error de prioridad baja o una solicitud de función que es poco probable que se cierre. También se pueden mantener abiertos para una posible repriorización si se ven afectados más usuarios.
  • caja de hielo
    • Problemas que actualmente no tenemos tiempo de tratar ni el momento 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 lidiar con ellos. Como siempre, no dudes en comentar o agregar reacciones a estos problemas, incluso si están cerrados.

Etiquetas de equipo

En el caso de los problemas nuevos, las etiquetas category: * dejaron de estar disponibles y se reemplazaron por las del equipo.

Consulte la lista completa de etiquetas aquí.