Guía para encargados de mantenimiento de Bazel

Informar un problema Ver fuente

Esta es una guía para los encargados del mantenimiento del proyecto de código abierto de Bazel.

Si deseas colaborar con Bazel, consulta Cómo contribuir con Bazel.

Los objetivos de esta página son los siguientes:

  1. Servir como fuente de información de los mantenedores para el proceso de contribución del proyecto.
  2. Establece las expectativas entre los colaboradores de la comunidad y los encargados del mantenimiento del 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 lanzamiento de Bazel.
  • Equipo verde: Crea un ecosistema saludable de reglas y herramientas.
  • Jardineros de la experiencia del desarrollador: Fomenta 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 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 cuando elige una de las plantillas de problemas y este ingresa al 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 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 tiene información faltante, 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 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 lo hace, 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 solucionarlo, el miembro de DevEx asigna la etiqueta good first issue. En esta etapa, el problema entra en el conjunto de problemas abiertos sin clasificar.

Cada subequipo de Bazel clasificará todos los problemas según sus etiquetas, preferentemente de forma semanal. 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 RR.PP. en tu propia área, tienes la responsabilidad de 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 designar a otra persona para que revise el informe de relaciones públicas.
  4. El revisor asignado revisa el documento de relaciones públicas y trabaja con el autor hasta que se aprueba o se descarta.
  5. Si se aprueba, el revisor importa las confirmaciones de 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 RR.PP. con el conjunto de pruebas internas. Este es el motivo por el que no combinamos las relaciones públicas de forma directa.
  6. Si la confirmación importada pasa todas las pruebas internas, se comprimirá y se exportará a GitHub.
  7. Cuando la confirmación se combina en 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 sus etiquetas, preferentemente de forma semanal.

Issues

  1. Filtra la lista de problemas por las etiquetas de equipo y untriaged.
  2. Revisa el problema.
  3. Identifique un nivel de prioridad y asígnele la etiqueta.
    1. Es posible que el subequipo de DevEx ya haya priorizado el problema si es P0. Cambia la prioridad si es necesario.
    2. Cada problema debe tener exactamente una etiqueta de prioridad. Si un problema es P0 o P1, suponemos que se soluciona activamente.
  4. Quita la etiqueta untriaged.

Ten en cuenta que debes estar en 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. Revisa las solicitudes de extracción abiertas.
    1. Opcional: Si se te asignó para la revisión, pero no es la adecuada para ella, reasigna al revisor adecuado para que realice la revisión del código.
  3. Trabaja con el creador de la solicitud de extracción para completar una revisión de código.
  4. Aprobar el comunicado de prensa.
  5. Asegúrate de que se aprueben todas las pruebas.
  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 se exporta de forma correcta, GitHub cerrará automáticamente la PR.

Prioridad

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

  • P0: Funcionalidad principal dañada que provoca que una versión de Bazel (menos los candidatos de lanzamiento) sea inutilizable o un servicio inactivo que afecta gravemente el desarrollo del proyecto de Bazel. Esto incluye regresiones introducidas en una versión nueva que bloquea una cantidad significativa de usuarios o un cambio rotundo incompatible que no cumple con la política de Cambio rotundo. No existe una solución práctica.
  • P1: Defecto o función crítico que se debe solucionar en la próxima versión, o 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 acción inmediata. Con alta demanda y lo que está planificado en la hoja de ruta del trimestre actual
  • P2: Defecto o función que se debe solucionar, pero que no trabajamos en el momento. Problema activo moderado en una versión de Bazel lanzada que es poco conveniente para un usuario que se debe abordar en una versión futura o que existe una solución alternativa sencilla.
  • P3: Se recomienda una corrección o mejora de errores menores con un impacto leve. No se priorizan en las hojas de ruta de Bazel ni en ninguna versión inminente. Sin embargo, se fomentan las contribuciones de la comunidad.
  • P4: Defecto de baja prioridad o solicitud de función que es poco probable que se cierre. También se puede mantener abierto para una posible repriorización si más usuarios se ven afectados.
  • ice-box
    • Problemas que actualmente no tenemos tiempo para tratar ni tiempo para aceptar contribuciones Cerraremos estos problemas para indicar que nadie está trabajando en ellos, pero seguiremos supervisando su validez a lo largo del tiempo y reviviéndolos si hay suficientes personas se ven afectadas y si contamos con recursos para tratar con ellos. Como siempre, siéntete libre de comentar o agregar reacciones a estos problemas, incluso si cierras la ventana.

Etiquetas de equipo

Para problemas nuevos, las etiquetas category: * dejaron de estar disponibles y se reemplazaron por las etiquetas de equipo.

Consulta la lista completa de etiquetas aquí.