En esta página, se describe cómo los colaboradores pueden proponer y realizar cambios en la implementación de Bazel base de código.
- Lee la política de contribución de Bazel.
- Crea un problema en GitHub para discutir tu plan y diseño. Solicitudes de extracción que cambian o agregan comportamiento Necesito un problema relacionado con el seguimiento.
- Si propones cambios significativos, escribe un documento de diseño.
- Asegúrate de haber firmado una Licencia para colaboradores Acuerdo.
- Prepara una confirmación de Git que implemente la función. No olvides agregar pruebas y actualizar la documentación. Si el cambio tiene efectos visibles para el usuario, agregar notas de la versión. Si se trata de un cambio incompatible, lee la guía para lanzar cambios rotundos.
- Crear una solicitud de extracción en GitHub: Si eres nuevo en GitHub, Leer sobre la extracción solicitudes. Ten en cuenta que restringimos los permisos para crear ramas en el repositorio principal de Bazel. deberás enviar tu confirmación a tu propia bifurcación del Cloud Storage.
- Un encargado de mantenimiento de Bazel debería asignarte un revisor en un plazo de dos días hábiles. (excepto días feriados en EE.UU. y Alemania). Si no tienes asignado un revisor en ese tiempo, puedes solicitar uno enviando un correo electrónico bazel-discuss@googlegroups.com.
- Trabaja con el revisor para completar una revisión de código. Para cada cambio, crea una una confirmación nueva y enviarla para que realice cambios en tu solicitud de extracción. Si la revisión lleva demasiado tiempo (por ejemplo, si el revisor no responde), envía un correo electrónico a bazel-discuss@googlegroups.com.
Una vez completada la revisión, un encargado de mantenimiento de Bazel aplica tu parche a Sistema de control de versión interno de Google
Esto activa las verificaciones internas del envío previo al envío que pueden sugerir más cambios. Si no has expresado ninguna preferencia, el encargado de mantenimiento que envía tu cambio agrega el estado “trivial” cambios (como linting) que no afectan el diseño de tu producto. Si se requieren cambios más profundos o si prefieres aplicar los cambios directamente, tú y el revisor deben comunicar sus preferencias claramente en los comentarios.
Después del envío interno, el parche se exporta como una confirmación de Git. La solicitud de extracción de GitHub se cierra. Todos los cambios finales que se te atribuyen a ti.