Esta página descreve como os colaboradores podem propor e fazer mudanças na base de código do Bazel.
- Leia a política de contribuição do Bazel.
- Crie um problema do GitHub para discutir seu plano e design. As solicitações de pull que mudam ou adicionam comportamento precisam de um problema correspondente para acompanhamento.
- Se você estiver propondo mudanças significativas, escreva um documento de design.
- Confirme se você assinou um contrato de licença de colaborador.
- Prepare um commit do Git que implemente o recurso. Não se esqueça de adicionar testes e atualizar a documentação. Se a mudança tiver efeitos visíveis para o usuário, adicione notas da versão. Se for uma mudança incompatível, leia o guia para lançar mudanças incompatíveis.
- Crie uma solicitação de envio no GitHub. Se você não conhece o GitHub, leia sobre solicitações de pull. Restringimos as permissões para criar ramificações no repositório principal do Bazel. Portanto, você precisa enviar seu commit para seu próprio fork do repositório.
- Um mantenedor do Bazel vai atribuir um revisor a você em até dois dias úteis (exceto feriados nos EUA e na Alemanha). Se você não receber um revisor nesse período, envie um e-mail para bazel-discuss@googlegroups.com.
- Trabalhe com o revisor para concluir uma revisão de código. Para cada mudança, crie uma nova confirmação e envie para fazer alterações na sua solicitação de envio. Se a revisão demorar muito (por exemplo, se o revisor não responder), envie um e-mail para bazel-discuss@googlegroups.com.
Depois que a revisão for concluída, um mantenedor do Bazel vai aplicar o patch ao sistema interno de controle de versão do Google.
Isso aciona verificações internas de pré-envio que podem sugerir mais mudanças. Se você não tiver expressado uma preferência, o mantenedor que enviar sua mudança vai adicionar alterações "triviais" (como linting) que não afetam o design. Se forem necessárias mudanças mais profundas ou se você preferir aplicar alterações diretamente, você e o revisor precisam comunicar as preferências claramente nos comentários da revisão.
Após o envio interno, o patch é exportado como um commit do Git, e a solicitação de envio do GitHub é fechada. Todas as mudanças finais são atribuídas a você.