Processo de aceitação do patch

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

Esta página descreve como os colaboradores podem propor e fazer mudanças na base de código do Bazel.

  1. Leia a política de contribuição do Bazel.
  2. Crie um problema no GitHub para discutir seu plano e design. As solicitações de pull que mudam ou adicionam comportamento precisam de um problema correspondente para acompanhamento.
  3. Se você estiver propondo mudanças significativas, escreva um documento de design.
  4. Confira se você assinou um Contrato de licença de colaborador Agreement.
  5. 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, por favor adicione notas de versão. Se for uma mudança incompatível, leia o guia para implementar mudanças interruptivas.
  6. Crie uma solicitação de pull no GitHub. Se você não conhece o GitHub, leia sobre solicitações de pull requests. Restringimos as permissões para criar ramificações no repositório principal do Bazel. Portanto, será necessário enviar o commit para seu próprio fork do repositório.
  7. Um responsável pela manutenção 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, solicite um enviando um e-mail para bazel-dev@googlegroups.com.
  8. Trabalhe com o revisor para concluir uma revisão de código. Para cada mudança, crie um novo commit e envie-o para fazer alterações na solicitação de pull. Se a revisão demorar muito (por exemplo, se o revisor não responder), envie um e-mail para bazel-dev@googlegroups.com.

  9. Depois que a revisão for concluída, um responsável pela manutenção do Bazel vai aplicar o patch ao sistema de controle de versão 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 pela manutenção que enviar a mudança vai adicionar mudanças "triviais" (como linting) que não afetam o design. Se forem necessárias mudanças mais profundas ou se você preferir aplicar mudanças 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 pull do GitHub é fechada. Todas as mudanças finais são atribuídas a você.