Guia para mantenedores do Bazel

Informar um problema Ver a fonte Nightly · 8.0 · 7.5 · 7.4 · 7.3 · 7.2

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 vai 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 de 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 PR.
  4. O revisor designado analisa a PR e trabalha com o autor até que ela seja aprovada ou descartada.
  5. Se aprovado, o revisor imports as confirmações da PR para o sistema interno de controle de versões 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 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 RP.

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 roteiros do Bazel ou 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 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.