Esta página descreve como os colaboradores podem propor e fazer alterações na base de código do Bazel.
- Leia a política de contribuição do Bazel.
- Crie um problema no GitHub (em inglês) para discutir seu plano e design. As solicitações de envio que alteram ou adicionam comportamento precisam de um problema correspondente para acompanhamento.
- Se você estiver propondo alterações significativas, escreva um documento de design.
- Verifique se você assinou um Contrato de licença de colaborador.
- Prepare uma confirmação 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 alteração incompatível, leia o guia para implementar alterações interruptivas.
- Crie uma solicitação de envio no GitHub. Se você é novo no GitHub, leia sobre solicitações de envio. Nós restringimos as permissões para criar ramificações no repositório principal do Bazel. Portanto, você precisará enviar sua confirmação para sua própria bifurcação do repositório.
- Um administrador do Bazel atribui um revisor em até dois dias úteis (exceto feriados nos EUA e na Alemanha). Se você não receber um revisor nesse período, poderá solicitar um por e-mail para bazel-discuss@googlegroups.com.
- Trabalhe com o revisor para concluir uma revisão do código. Para cada alteração, crie uma nova confirmação e a 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 administrador do Bazel aplicará seu patch ao sistema de controle de versão interno do Google.
Isso aciona verificações de pré-envio internas que podem sugerir mais alterações. Se você não tiver expressado uma preferência, o mantenedor que enviará sua alteração adicionará alterações "triviais" (como linting) que não afetam o design. Se for necessário fazer alterações mais profundas ou se preferir aplicar as alterações diretamente, você e o revisor precisam comunicar claramente as preferências nos comentários da avaliação.
Após o envio interno, o patch é exportado como uma confirmação do Git e, nesse momento, a solicitação de envio do GitHub é fechada. Todas as alterações finais são atribuídas a você.