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 (em inglês) para discutir seu plano e design. As solicitações de envio que mudam ou adicionam comportamento precisam de um problema correspondente para o rastreamento.
- Se 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 para o usuário, adicione notas da versão. Se ela for incompatível, leia o guia para implantar alterações interruptivas.
- Crie uma solicitação de envio no GitHub. Se você está começando a usar o GitHub, leia sobre solicitações de envio. Nós restringimos as permissões para criar ramificações no repositório principal do Bazel. Por isso, você precisará enviar sua confirmação para sua própria bifurcação do repositório.
- Um administrador do Bazel precisa atribuir um revisor em até dois dias úteis (exceto feriados nos EUA e na Alemanha). Se você não receber um revisor nesse período, solicite um por e-mail bazel-dev@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-a por push para fazer alterações na solicitação de envio. Se a avaliação demorar, por exemplo, se ela não responder, envie um e-mail para bazel-dev@googlegroups.com.
Após a conclusão da análise, um mantenedor do Bazel aplica o patch ao sistema de controle de versões interno do Google.
Isso aciona verificações de pré-envio internas que podem sugerir mais alterações. Se você não tiver expresso uma preferência, o mantenedor que enviará sua alteração adicionará alterações triviais (como linting) que não afetam o design. Se alterações mais profundas forem necessárias ou se você preferir aplicar as alterações diretamente, é necessário que o revisor informe claramente as preferências nos comentários da avaliação.
Após o envio interno, o patch é exportado como uma confirmação do Git. Nesse ponto, a solicitação de envio do GitHub é fechada. Todas as alterações finais são atribuídas a você.