Guía para encargados de mantenimiento de Bazel

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.
Informar un problema Ver código fuente

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

Si deseas contribuir a Bazel, lee Contribuir a Bazel.

Los objetivos de esta página son:

  1. Sirven como fuente de información confiable para el proceso de contribución 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 para administrar aspectos del proyecto de código abierto. que son los siguientes:

  • Proceso de lanzamiento: Administra el proceso de actualización de Bazel.
  • Equipo ecológico: Desarrolla un ecosistema saludable de reglas y herramientas.
  • Jardineros de experiencia para desarrolladores: Fomentan las contribuciones externas, la revisión de problemas y las solicitudes de extracción, y hacen que nuestro flujo de trabajo de desarrollo sea más abierto.

Versiones

Integración continua

Lee la guía del equipo de Green 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 con la Plantilla de problemas y entra en el grupo de problemas abiertos sin revisar.
  2. Un miembro de la rotación del subequipo de experiencia del desarrollador (DevEx) revisa el problema.
    1. Si el problema no es un error ni una solicitud de función, por lo general, el miembro de DevEx cerrará el problema y redireccionará al usuario a StackOverflow y bazel-discuss para obtener una mayor visibilidad de la pregunta.
    2. Si el problema pertenece a uno de los repositorios de reglas que le pertenecen a la comunidad, como rules_apple, el miembro de DevEx transferirá este problema al repositorio correcto.
    3. Si el problema es impreciso o falta información, el miembro de DevEx volverá a 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 problema.
  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 P0 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. 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 prioridad baja y un miembro de la comunidad nuevo puede trabajar en él, el miembro de DevEx asigna la etiqueta good first issue. En esta etapa, el problema entra en el grupo de problemas abiertos sin clasificar.

Cada subequipo de Bazel clasificará todos los problemas con etiquetas propias, preferentemente, semanalmente. El subequipo revisará y evaluará el problema y te brindará una solución, si es posible. Si eres 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 solicitud de RR.PP. a tu propia área, tienes la responsabilidad de asignar la etiqueta de tu equipo y encontrar al mejor revisor.
  3. De lo contrario, durante la evaluación diaria, un miembro de DevEx asigna una etiqueta de equipo y el líder técnico del equipo (TL) para el enrutamiento.
    1. El TL tiene la opción de asignar a otra persona para que revise el PR.
  4. El revisor asignado revisa la solicitud de extracción y trabaja con el autor hasta que se aprueba o descarta.
  5. Si se aprueba, el revisor importa las confirmaciones del 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 internamente en Google, necesitamos probar todas las confirmaciones de RR.PP. con el conjunto de pruebas internas. Este es el motivo por el que no fusionamos los PR directamente.
  6. Si la confirmación importada pasa todas las pruebas internas, se confirmará y 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 una etiqueta. ¿Qué debo hacer?

Los subequipos deben clasificar todos los problemas en las etiquetas que les pertenecen, preferentemente, de forma semanal.

Issues

  1. Filtre la lista de problemas por etiqueta de equipo y por 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 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 por etiqueta de equipo
  2. Revisa las solicitudes de extracción abiertas.
    1. Opcional: Si te asignaron para la revisión, pero no es la adecuada, reasigna el 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 la solicitud de extracción
  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 internos internos.
  7. Envía el parche interno. Si el parche se envía y exporta de forma correcta, GitHub cerrará el PR de forma automática.

Prioridad

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

  • P0: Es una funcionalidad importante que no funciona que hace que una versión de Bazel (menos las versiones candidatas) sea inutilizable, o un servicio caído que afecte gravemente el desarrollo del proyecto de Bazel. Esto incluye las regresiones introducidas 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 característica que debe abordarse 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 planificada en la hoja de ruta del trimestre actual.
  • P2: Es un defecto o una función que debe solucionarse, pero en la que no estamos trabajando actualmente. Un problema en vivo moderado en una versión de Bazel que se lanzó es poco conveniente para un usuario que necesita abordarlo en una versión futura o existe una solución alternativa sencilla.
  • P3: corrección o corrección de errores menores deseables con pequeño impacto. No se priorizan las hojas de ruta de Bazel ni cualquier lanzamiento inminente, pero se recomienda la contribución 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 priorización si se ven afectados más usuarios.
  • caja de hielo
    • Problemas con los que no tenemos tiempo por el momento 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 afectados suficientes usuarios y si tenemos recursos para tratar con ellos. Como siempre, no dudes en comentar ni agregar reacciones a estos problemas, incluso cuando 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í.