En esta página, se describe cómo los colaboradores pueden proponer y realizar cambios en la base de código de Bazel.
- Consulta la política de contribución de Bazel.
- 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.
- Si propones cambios significativos, escribe un documento de diseño.
- Asegúrate de haber firmado un Contrato de Licencia para Colaboradores.
- Prepara una confirmación de Git que implementa la función. No olvides agregar pruebas y actualizar la documentación. Si el cambio tiene efectos visibles para el usuario, agrega notas de la versión. Si es un cambio incompatible, lee la guía para implementar cambios rotundos.
- 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 la confirmación a tu propia bifurcación del repositorio.
- Un encargado de mantenimiento de Bazel debería asignarte un revisor dentro de los dos días hábiles (excepto los días feriados en EE.UU. y Alemania). Si no se te asignó un visualizador en ese tiempo, puedes solicitarlo enviando un correo electrónico a bazel-dev@googlegroups.com.
- Trabaja con el revisor para completar una revisión de código. Por cada cambio, crea una confirmación nueva y envíala para realizar cambios en la solicitud de extracción. Si la revisión tarda demasiado (por ejemplo, si el revisor no responde), envía un correo electrónico a bazel-dev@googlegroups.com.
Una vez que se completa la revisión, un encargado de mantenimiento de Bazel aplica tu parche al sistema de control de versión interno de Google.
Esto activa verificaciones previas al envío internas que pueden sugerir más cambios. Si no expresaste una preferencia, el encargado de enviar el cambio agrega cambios triviales (como los linting) que no afectan el diseño. Si se requieren cambios más profundos o si prefieres aplicarlos directamente, tú y el revisor deben comunicar las preferencias con claridad en los comentarios de las opiniones.
Después de que se envía de forma interna, el parche se exporta como una confirmación de Git. En ese momento, se cierra la solicitud de extracción de GitHub. Te atribuimos todos los cambios finales.