Guia para mantenedores do Bazel

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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. Servir como fonte da verdade para os mantenedores no processo de contribuição do projeto.
  2. Defina 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: gerencie o processo de lançamento do Bazel.
  • Equipe verde: desenvolva um ecossistema saudável de regras e ferramentas.
  • Jardineiros da experiência do desenvolvedor: incentivam contribuições externas, analisam problemas e solicitações de pull e tornam 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 escolhendo um dos modelos 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 da DevEx geralmente vai fechar o problema e redirecionar o usuário para StackOverflow e bazel-discuss para aumentar a visibilidade da pergunta.
    2. Se o problema pertencer a um dos repositórios de regras da comunidade, como rules_apple, o membro da DevEx vai transferir o problema para o repositório correto.
    3. Se o problema for vago ou estiver incompleto, o membro da DevEx vai atribuir o problema de volta ao usuário para pedir mais informações antes de continuar. Isso geralmente acontece quando o usuário não escolhe o modelo de problema {: .external} correto ou fornece informações incompletas.
  3. Depois de analisar o problema, o membro da DevEx decide se ele precisa de atenção imediata. Se for o caso, eles vão atribuir o rótulo de P0 e um proprietário da lista de líderes de equipe.
  4. O membro da DevEx atribui o rótulo untriaged e exatamente um rótulo da equipe para o encaminhamento.
  5. O membro da DevEx também atribui exatamente um marcador type:, como type: bug ou type: feature request, de acordo com o tipo do problema.
  6. Para problemas específicos da plataforma, o membro da DevEx atribui um rótulo platform:, como platform:apple para problemas específicos do Mac.
  7. Se o problema for de baixa prioridade e puder ser resolvido por um novo colaborador da comunidade, o membro da DevEx vai atribuir o rótulo good first issue. Nessa etapa, o problema entra no pool de problemas abertos sem triagem.

Cada subequipe do Bazel vai triar todos os problemas nos rótulos que possui, de preferência semanalmente. A subequipe vai analisar e avaliar o problema e fornecer uma soluçã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 fechado.

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 uma solicitação de pull na sua própria área, 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 da DevEx atribui um rótulo de equipe e o líder técnico (TL) da equipe para encaminhamento.
    1. O TL pode atribuir a revisão do PR a outra pessoa.
  4. O revisor atribuído analisa a solicitação de pull e trabalha com o autor até que ela seja aprovada ou descartada.
  5. Se aprovado, o revisor importa os commits do PR para o sistema interno de controle de versão do Google para mais 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, não fazemos merge de PRs diretamente.
  6. Se o commit importado passar em todos os testes internos, ele será compactado e exportado de volta para o GitHub.
  7. Quando o commit é mesclado à ramificação principal, o GitHub fecha automaticamente a solicitação de envio.

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

As subequipes precisam triar todos os problemas nos rótulos que possuem, de preferência semanalmente.

Problemas

  1. Filtre a lista de problemas pelo marcador da sua equipe e pelo marcador 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 de DevEx se for um P0. Reordene se necessário.
    2. Cada problema precisa ter exatamente um rótulo de prioridade. Se um problema for P0 ou P1, presumimos que ele está sendo trabalhado ativamente.
  4. Remova o marcador untriaged.

Você precisa 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 sua equipe.
  2. Revise as solicitações de envio abertas.
    1. Opcional: se você foi atribuído à revisão, mas não é a pessoa certa para isso, reatribua o revisor adequado para fazer 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. Aprove o PR.
  5. Confira se todos os testes foram aprovados.
  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 com sucesso, o PR será fechado automaticamente pelo GitHub.

Prioridade

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

  • P0: funcionalidade principal quebrada que torna uma versão do Bazel (exceto candidatos a lançamento) inutilizável ou um serviço inativo que afeta muito o desenvolvimento do projeto Bazel. Isso inclui regressões introduzidas em uma nova versão que bloqueia um número significativo de usuários ou uma mudança interruptiva incompatível que não estava em conformidade com a política de mudança interruptiva. Não há uma solução alternativa prática.
  • P1: defeito ou recurso crítico que precisa ser abordado 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 exige ação imediata. Em alta demanda e planejado no roteiro do trimestre atual.
  • P2: defeito ou recurso que precisa ser resolvido, mas em que não estamos trabalhando no momento. Problema moderado 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 existe uma solução alternativa fácil.
  • P3: correção ou melhoria desejável de um bug menor com pequeno impacto. Não priorizado em roteiros do Bazel ou em qualquer lançamento iminente. No entanto, as contribuições da comunidade são incentivadas.
  • P4: defeito de baixa prioridade ou solicitação de recurso que provavelmente não será fechada. Também pode ser mantido aberto para uma possível repriorização se mais usuários forem afetados.

Marcadores de equipe

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

Confira a lista completa de rótulos aqui.