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 você quiser contribuir com o Bazel, leia Como contribuir com o Bazel.

Os objetivos desta página são:

  1. Atuar como mantenedor fonte de verdade para a contribuição do projeto de desenvolvimento de software.
  2. Defina as expectativas entre os colaboradores da comunidade e os mantenedores do projeto.

O grupo principal de colaboradores do Bazel dedicou subequipes 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 usando a propriedade Issue Modelo 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 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, o marcador P0 prioridade e um proprietário da lista de líderes de equipe serão atribuídos.
  4. O membro DevEx atribui o rótulo untriaged e exatamente uma equipe rótulo para roteamento.
  5. O membro 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. Nesse estágio, o problema entra no conjunto de problemas abertos não resolvidos.

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 analisará e avaliará o problema e fornecerá a 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 DevEx atribui um rótulo da equipe e o líder técnico da equipe (TL) 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 build usado internamente no Google, precisamos testar todas as confirmações de RP em relação ao um pacote 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 ao mestre, o GitHub fecha automaticamente a solicitação de envio.

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 pelo 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. Mude a prioridade, se necessário.
    2. Cada problema precisa ter exatamente um marcador de prioridade. Se um problema é P0 ou P1, presumimos que ele 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ê 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 análise de código.
  4. Aprove o PR.
  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 seguintes definições de prioridade serão usadas pelos mantenedores para fazer a triagem 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 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 ativo moderado em uma versão lançada do Bazel que é inconveniente para um usuário que precisa ser resolvidos em uma versão futura e/ou existe uma solução fácil.
  • P3: bug menor desejável correção ou aprimoramento com pouco impacto. não priorizados nos roteiros do Bazel ou qualquer lançamento iminente. No entanto, incentivamos as contribuições da comunidade.
  • P4: solicitação de recurso ou defeito de baixa prioridade que provavelmente não será fechado. Também pode ser mantido aberto por um uma possível nova priorização 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 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 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.