Nesta página, descrevemos 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 no GitHub para discutir seu plano e projeto. As solicitações de envio que mudam ou adicionam comportamentos precisam de um problema correspondente para rastreamento.
- Se você estiver propondo mudanças 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 ao 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. Observe que restringimos permissões para criar ramificações no repositório principal do Bazel. Por isso, você vai precisar enviar sua confirmação para sua própria bifurcação do repositório.
- Um administrador do Bazel deve designar um revisor em dois dias úteis, exceto feriados nos EUA e na Alemanha. Se você não receber um revisor nesse período, poderá solicitar um enviando um e-mail para bazel-discuss@googlegroups.com.
- Trabalhe com o revisor para concluir uma revisão de código. Para cada alteração, crie uma nova confirmação e envie-a por push para fazer alterações na sua solicitação de envio. Se a análise demorar muito (por exemplo, se o revisor não responder), envie um e-mail para bazel-discuss@googlegroups.com.
Após a conclusão da revisão, um administrador do Bazel aplica seu patch ao sistema de controle de versões interno 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 responsável que envia sua mudança adicionará mudanças "triviais" (como lint) que não afetam o design. Se forem necessárias alterações mais profundas ou se você preferir aplicá-las diretamente, você e o revisor precisarão informar as preferências claramente nos comentários da análise.
Após o envio interno, o patch é exportado como uma confirmação do Git. Então, a solicitação de envio do GitHub é encerrada. Todas as mudanças finais são atribuídas a você.