Guía para encargados de mantenimiento de Bazel

Informar un problema Ver fuente . Por la noche · 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 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 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 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 pertenecen al 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 elige la opción 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á 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 un equipo. etiqueta 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 abiertas sin clasificar problemas.

Cada subequipo de Bazel clasificará todos los problemas bajo sus etiquetas, preferentemente en una semanalmente. El subequipo revisará y evaluará el problema, y proporcionará resolución, si es posible. Si es propietario de una etiqueta de equipo, consulte 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 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 las RR.PP. y trabaja con el autor hasta que se cumpla aprobado o descartado.
  5. Si se aprueba, el revisor importa los compromisos de RR.PP. en la un sistema de control de versión interno para realizar más pruebas. Como Bazel es la misma compilación, de RR.PP. que se usa internamente en Google, debemos probar todos los compromisos de RR.PP. con el paquete 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 exportarlos 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 preferentemente cada semana.

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 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 bazelbuild organización 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 asignó la revisión, pero no es la opción adecuada. para ello, 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 el envíos previos.
  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 de mantenimiento usarán las siguientes definiciones de prioridad para clasificar 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 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 política de la empresa. 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 ninguna 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 de Bazel lanzada que no es conveniente para un usuario que debe que se abordará en una versión futura o que exista una solución alternativa sencilla.
  • 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 baja prioridad o una solicitud de función que es probable que no se cierre. También se puede mantener abierta la posibilidad de cambiar la prioridad si hay más usuarios afectados.
  • 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 seguirá supervisando su validez durante tiempo y revivirlos si hay suficientes personas se ven afectadas y si tenemos recursos para lidiar con ellas. Como siempre, no dudes en comentar o agregar reacciones. a estos problemas, incluso cuando está cerrado.

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