Guia para mantenedores do Bazel

Informar um problema Mostrar fonte Por noite · 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. Atuar como mantenedor fonte de verdade para a contribuição do projeto de desenvolvimento de software.
  2. Definir expectativas entre os colaboradores da comunidade e o projeto mantenedores.

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: gerencie 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 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 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 designado analisa a RP e trabalha com o autor até que ela seja aprovado ou recusado.
  5. Em caso de aprovação, o revisor importa as confirmações do RP para os sistema de controle de versão interno para testes adicionais. 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 no mestre, o GitHub fecha automaticamente o PR.

Minha equipe tem uma gravadora. 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. 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 envio

  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. 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 corretamente, o O PR será fechado automaticamente pelo GitHub.

Prioridade

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

  • P0 - Problema grave que faz com que uma versão do Bazel (menos as versões candidatas) seja inutilizável ou inativo que afete gravemente o desenvolvimento do Bazel em um projeto de IA. 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 existe uma 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 requer 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: defeito de baixa prioridade ou de recurso que provavelmente não será encerrada. Também pode ser mantido aberto por um uma possível nova priorização se mais usuários forem afetados.
  • caixa de gelo
    • Problemas com os quais não temos tempo para lidar no momento nem os para aceitar contribuições. Encerraremos esses problemas para indicar que ninguém está trabalhando nelas, mas continuará a monitorar sua validade durante tempo e reviver pessoas suficientes se forem afetadas e se acontecermos recursos para lidar com elas. 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 da equipe rótulos.

Veja a lista completa de marcadores aqui.