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 do GitHub para discutir seu plano e design. As solicitações de puxar que mudam ou adicionam comportamento precisam de um problema correspondente para rastreamento.
- Se você estiver propondo mudanças significativas, escreva um documento de design.
- Confira se você assinou um Contrato de Licença do 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ê é novo no GitHub, leia sobre solicitações de pull. Restrição de permissões para criar ramificações no repositório principal do Bazel. Portanto, você vai precisar enviar o commit para seu próprio bifurcação do repositório.
- Um mantenedor do Bazel vai atribuir um revisor a você em dois dias úteis (exceto feriados nos EUA e na Alemanha). Se você não receber um revisor nesse período, solicite um enviando 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 confirmação e envie para fazer alterações na 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.
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 antes do envio que podem sugerir mais mudanças. Se você não tiver expressado uma preferência, o mantenedor que enviar a alteração vai adicionar mudanças "simples" (como linting) que não afetam o design. Se forem necessárias mudanças mais profundas ou se você preferir aplicar as mudanças diretamente, você e o revisor precisam comunicar as preferências de forma clara 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 é encerrada. Todas as mudanças finais são atribuídas a você.