Proceso de aceptación de parches

En esta página, se describe cómo los colaboradores pueden proponer y realizar cambios en la base de código de Bazel.

1. Lee la política de contribución de Bazel.
2. Crea un problema de GitHub para analizar tu plan y diseño. Las solicitudes de extracción que cambian o agregan comportamiento necesitan un problema correspondiente para el seguimiento.
3. Si propones cambios significativos, escribe un documento de diseño.
4. Asegúrate de haber firmado un Acuerdo de licencia de colaborador.
5. Prepara una confirmación de Git que implemente la función. No olvides agregar pruebas y actualizar la documentación. Si tu cambio tiene efectos visibles para el usuario, por favor agrega notas de la versión. Si se trata de un cambio incompatible, lee la guía para implementar cambios rotundos.
6. Crea una solicitud de extracción en GitHub. Si es la primera vez que usas GitHub, lee sobre las solicitudes de extracción. Ten en cuenta que restringimos los permisos para crear ramas en el repositorio principal de Bazel, por lo que deberás enviar tu confirmación a tu propia bifurcación del repositorio.
7. Un mantenedor de Bazel debería asignarte un revisor en un plazo de 7 días hábiles (sin incluir los días festivos en EE.UU. y Alemania). Si no se te asigna un revisor en ese tiempo, puedes hacer ping a @bazelbuild/triage en la solicitud de extracción.
8. Trabaja con el revisor para completar una revisión de código. Para cada cambio, crea una confirmación nueva y envíala para realizar cambios en tu solicitud de extracción. Si la revisión tarda demasiado (por ejemplo, si el revisor no responde), puedes hacer ping @bazelbuild/triage en la solicitud de extracción.

9. Una vez que se completa la revisión, un mantenedor de Bazel aplica tu parche al sistema de control de versiones interno de Google.

   Esto activa las verificaciones internas previas a la confirmación que pueden sugerir más cambios. Si no expresaste una preferencia, el mantenedor que envía tu cambio puede agregar cambios "triviales" (como la linting) que no afecten el diseño. Si se requieren cambios más profundos o prefieres aplicar los cambios directamente, tú y el revisor deben comunicar las preferencias con claridad en los comentarios de la revisión.

   Después del envío interno, el parche se exporta como una confirmación de Git, momento en el que se cierra la solicitud de extracción de GitHub. Todos los cambios finales se te atribuyen.