Guia para mantenedores do Bazel

Informar um problema Ver código-fonte Nightly · 7.4 . 7,3 · 7.2 · 7,1 · 7,0 · 6,5

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

Se quiser contribuir com o Bazel, leia Como contribuir para 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.
  • Developer Experience Gardeners: incentive contribuições externas, revisão problemas e solicitações de envio, além de deixar 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 bazelbuild/continuous-integration repositório de dados.

Ciclo de vida de um problema

  1. Um usuário cria um problema escolhendo uma das modelos de problemas e ela entra no grupo de usuários problemas.
  2. Um membro da rotação de subequipe da Experiência do desenvolvedor (DevEx) revisa as problema.
    1. Se o problema não for um bug ou uma solicitação de recurso, o membro do DevEx geralmente fecha o problema e redireciona o usuário para StackOverflow e bazel-discuss para maior visibilidade sobre a pergunta.
    2. Se o problema pertence a um dos repositórios de regras de propriedade do comunidade, como rules_apple, o participante DevEx vai transferir este problema no repositório correto.
    3. Se o problema for vago ou tiver informações faltando, o membro DevEx atribua o problema de volta ao usuário para solicitar mais informações antes continuar. Isso geralmente ocorre quando o usuário não escolhe modelo de problema {: .external} ou fornece informações incompletas.
  3. Após analisar o problema, o membro DevEx decide se ele exige atenção imediata. Em caso afirmativo, o P0 é atribuído priority e um proprietário na lista de líderes de equipe.
  4. O membro DevEx atribui o rótulo untriaged e exatamente uma equipe rótulo para 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. No caso de problemas específicos da plataforma, o membro 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 uma nova comunidade colaborador, o participante do DevEx atribui o rótulo good first issue. Nessa etapa, o problema entra no pool de vulnerabilidades de suporte.

Cada subequipe do Bazel fará a triagem de todos os problemas com os rótulos próprios, de preferência em um semanalmente. A subequipe vai analisar e avaliar o problema e fornecer uma resolução, se possível. Se você for proprietário de um marcador 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ê faz parte de uma equipe do Bazel e envia um RP da sua área, você é responsável por atribuir seu rótulo de equipe e encontrar o melhor avaliador.
  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 designar outra pessoa para avaliar o RP.
  4. O revisor atribuído analisa a RP e trabalha com o autor até que ela seja aprovado ou recusado.
  5. Se aprovado, o revisor importa 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 PRs diretamente.
  6. Se a confirmação importada passar em todos os testes internos, ela será comprimida e exportados de volta para o GitHub.
  7. Quando a confirmação é mesclada no mestre, o GitHub fecha automaticamente o PR.

Minha equipe tem um identificador. O que devo fazer?

As subequipes precisam fazer a triagem de todos os problemas nos rótulos que pertencem a elas, de preferência uma vez por semana.

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. Talvez o problema já tenha sido priorizado pela subequipe DevEx se for um P0. Mude a prioridade, se necessário.
    2. Cada problema precisa ter exatamente um marcador de prioridade. Se um o problema é P0 ou P1, supomos que está sendo trabalhado ativamente.
  4. Remova o marcador untriaged.

Você precisa estar no bazelbuild organização para adicionar ou remover marcadores.

Solicitações de pull

  1. Filtre a lista de solicitações de envio pelo rótulo da sua equipe.
  2. Analise as solicitações de envio abertas.
    1. Opcional: se você receber a atribuição para a revisão, mas não for a opção ideal para isso, reatribua o revisor adequado para realizar uma revisão de código.
  3. Trabalhe com o criador da solicitação de envio para concluir uma análise de código.
  4. Aprovar a RP.
  5. Confira se todos os testes são aprovados.
  6. Importe o patch para o sistema de controle de versões interno e execute o pré-envios.
  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 número significativo de usuários ou uma alteração interruptiva incompatível que não foi em conformidade com os Termos Alterar política. Não há solução alternativa prática.
  • P1: defeito crítico ou que deve ser abordado na próxima versão, ou um problema sério que afeta muitos usuários (incluindo o desenvolvimento do projeto do Bazel), mas uma existe uma solução prática. Normalmente, não exige ação imediata. Em alta demanda e planejada no roteiro do trimestre atual.
  • P2: defeito ou recurso que deve ser resolvido, mas não estamos trabalhando nisso. 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 ou melhoria de bugs menores desejáveis com pequeno impacto. Não é priorizado nos planos de ação do Bazel ou em nenhuma versão iminente. No entanto, as contribuições da comunidade são incentivadas.
  • P4: defeito de baixa prioridade ou de recurso que provavelmente não será encerrada. Também pode ser mantido aberto para uma priorização em potencial se mais usuários forem afetados.
  • caixa de gelo
    • 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 um número suficiente de pessoas for afetado e se tivermos recursos para lidar com eles. 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.