Guia para mantenedores do Bazel

Reportar um problema Ver código-fonte Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Este é um guia para os mantenedores do projeto de código aberto Bazel.

Se você quiser contribuir com o Bazel, leia Como contribuir com o Bazel.

Os objetivos desta página são:

  1. Serve como a fonte da verdade dos mantenedores para o processo de contribuição do projeto.
  2. Defina as expectativas entre os colaboradores da comunidade e os mantenedores do projeto.

O grupo principal de colaboradores do Bazel tem subequipes dedicadas para gerenciar aspectos do projeto de código aberto. São eles:

  • Processo de lançamento: gerenciar o processo de lançamento do Bazel.
  • Equipe verde: crie um ecossistema saudável de regras e ferramentas.
  • Cuidadores da experiência do desenvolvedor: incentive contribuições externas, revise problemas e solicitações de pull e torne nosso fluxo de trabalho de desenvolvimento mais aberto.

Lançamentos

Integração contínua

Leia o guia da equipe Green sobre a infraestrutura de CI do Bazel no repositório bazelbuild/continuous-integration.

Ciclo de vida de um problema

  1. Um usuário cria um problema usando o modelo de problema e ele entra no conjunto de problemas abertos não revisados.
  2. Um membro da rotação da subequipe de experiência do desenvolvedor (DevEx) analisa o problema.
    1. Se o problema não for um bug ou uma solicitação de recurso, o membro do DevEx geralmente fechará o problema e redirecionará o usuário para o StackOverflow e o bazel-discuss para maior visibilidade da pergunta.
    2. Se o problema pertencer a um dos repositórios de regras da comunidade, como rules_apple, o membro do DevEx vai transferir o problema para o repositório correto.
    3. Se o problema for vago ou tiver informações ausentes, o membro do DevEx vai atribuir o problema de volta ao usuário para solicitar mais informações antes de continuar. Isso geralmente ocorre quando o usuário não segue o modelo de problema.
  3. Depois de analisar o problema, o membro do DevEx decide se ele precisa de atenção imediata. Se sim, eles vão atribuir o rótulo P0 prioridade e um proprietário da lista de líderes da equipe.
  4. O membro do DevEx atribui o rótulo untriaged e exatamente um rótulo de equipe para o roteamento.
  5. O membro do DevEx também atribui exatamente um rótulo type:, como type: bug ou type: feature request, de acordo com o tipo do problema.
  6. Para problemas específicos da plataforma, o membro do DevEx atribui um rótulo platform:, como platform:apple para problemas específicos do Mac. Nesse estágio, o problema entra no conjunto de problemas abertos não resolvidos.

Cada subequipe do Bazel vai classificar todos os problemas nos rótulos que pertencem a ela, de preferência semanalmente. A subequipe vai analisar e avaliar o problema e fornecer uma resolução, se possível. Se você for proprietário de um rótulo de equipe, consulte esta seção para mais informações.

Quando um problema é resolvido, ele pode ser encerrado.

Ciclo de vida de uma solicitação de envio

  1. Um usuário cria uma solicitação de envio.
  2. Se você for membro de uma equipe do Bazel e enviar um PR para sua própria área, você será responsável por atribuir o rótulo da equipe e encontrar o melhor revisor.
  3. Caso contrário, durante a triagem diária, um membro do DevEx atribui um rótulo de equipe e o líder técnico (LT) da equipe para roteamento.
    1. O TL pode atribuir outra pessoa para revisar a solicitação de pull.
  4. O revisor designado analisa a solicitação de pull e trabalha com o autor até que ela seja aprovada ou descartada.
  5. Se aprovado, o revisor imports as confirmações do PR para o sistema de controle de versão interno do Google para outros testes. Como o Bazel é o mesmo sistema de build usado internamente no Google, precisamos testar todos os commits de PR no conjunto de testes interno. É por isso que não mesclamos as PRs diretamente.
  6. Se a confirmação importada passar em todos os testes internos, ela será compactada e exportada de volta para o GitHub.
  7. Quando a confirmação é mesclada ao mestre, o GitHub fecha automaticamente a solicitação de envio.

Minha equipe tem um rótulo. O que devo fazer?

As subequipes precisam classificar todos os problemas nos rótulos delas, de preferência semanalmente.

Problemas

  1. Filtre a lista de problemas pelo rótulo da equipe e o rótulo untriaged.
  2. Analise o problema.
  3. Identifique um nível de prioridade e atribua o rótulo.
    1. O problema pode já ter sido priorizado pela subequipe do DevEx se for um P0. Repriorize se necessário.
    2. Cada problema precisa ter exatamente um rótulo de prioridade. Se um problema é P0 ou P1, presumimos que ele está sendo trabalhado ativamente.
  4. Remova o marcador untriaged.

É necessário estar na organização bazelbuild para adicionar ou remover rótulos.

Solicitações de pull

  1. Filtre a lista de solicitações de envio pelo rótulo da equipe.
  2. Analise as solicitações de envio abertas.
    1. Opcional: se você foi designado para a revisão, mas não é o candidato certo para ela, atribua novamente o revisor adequado para realizar uma revisão de código.
  3. Trabalhe com o criador da solicitação de envio para concluir uma revisão de código.
  4. Aprovar a RP.
  5. Garanta a aprovação de todos os testes.
  6. Importe o patch para o sistema interno de controle de versão e execute as pré-submissões internas.
  7. Envie o patch interno. Se o patch for enviado e exportado, a PR será fechada automaticamente pelo GitHub.

Prioridade

As definições de prioridade a seguir serão usadas pelos mantenedores para triagem de problemas.

  • P0: funcionalidade principal com falha que faz com que uma versão do Bazel (menos candidatos à versão) seja inutilizável ou um serviço desativado que afete gravemente o desenvolvimento do projeto do Bazel. Isso inclui regressões introduzidas em uma nova versão que bloqueia um número significativo de usuários ou uma alteração interruptiva incompatível que não atende à política de mudanças interruptivas. Não há solução alternativa prática.
  • P1: defeito ou recurso crítico que precisa ser resolvido na próxima versão ou um problema grave que afeta muitos usuários (incluindo o desenvolvimento do projeto Bazel), mas existe uma solução alternativa prática. Normalmente, não requer ação imediata. Em alta demanda e planejado no roteiro do trimestre atual.
  • P2: defeito ou recurso que precisa ser resolvido, mas não estamos trabalhando nele no momento. Problema moderado no ambiente em uma versão lançada do Bazel que é inconveniente para um usuário e precisa ser resolvido em uma versão futura e/ou uma solução alternativa fácil existe.
  • P3: correção de bugs ou melhoria desejável com pequeno impacto. Não foi priorizado nos planos de ação do Bazel nem em nenhuma versão iminente. No entanto, as contribuições da comunidade são incentivadas.
  • P4: solicitação de recurso ou defeito de baixa prioridade que provavelmente não será fechado. Também pode ser mantido aberto para uma priorização em potencial se mais usuários forem afetados.
  • ice-box
    • Problemas que não temos tempo para lidar ou aceitar contribuições. Vamos fechar esses problemas para indicar que ninguém está trabalhando neles, mas vamos continuar monitorando a validade deles ao longo do tempo e revivê-los se muitas pessoas forem afetadas e se tivermos recursos para lidar com elas. Como sempre, fique à vontade para comentar ou adicionar reações a esses problemas, mesmo quando eles estiverem fechados.

Marcadores de equipe

Para novos problemas, descontinuamos os rótulos category: * em favor dos rótulos de equipe.

Confira a lista completa de identificadores aqui.