Guia para mantenedores do Bazel

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

Se você quiser contribuir com o Bazel, leia o artigo Contribuir com o Bazel.

Os objetivos desta página são:

  1. Servir como fonte da verdade dos mantenedores para o processo de contribuição do projeto.
  2. Definir 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 elas:

  • Processo de lançamento: gerenciar o processo de lançamento do Bazel.
  • Equipe verde: desenvolver um ecossistema saudável de regras e ferramentas.
  • Jardineiros da experiência do desenvolvedor: incentivar contribuições externas, analisar problemas e solicitações de envio e tornar nosso fluxo de trabalho de desenvolvimento mais aberto.

Lançamentos

Integração contínua

Leia o guia da equipe verde para a infraestrutura de CI do Bazel no bazelbuild/continuous-integration repositório.

Ciclo de vida de um problema

  1. Um usuário cria um problema escolhendo um dos modelos de problemas e ele entra no pool de problemas abertos não analisados.
  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 o StackOverflow e o bazel-discuss para maior visibilidade na pergunta.
    2. Se o problema pertencer a um dos repositórios de regras pertencentes à comunidade, como rules_apple, o membro da DevEx vai transferir esse problema para o repositório correto.
    3. Se o problema for vago ou tiver informações ausentes, o membro da 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 escolhe o modelo de problema {: .external} correto ou fornece informações incompletas.
  3. Depois de analisar o problema, o membro da DevEx decide se o problema exige atenção imediata. Em caso afirmativo, eles vão atribuir o rótulo de prioridade P0 prioridade 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 de equipe para o roteamento.
  5. O membro da DevEx também atribui exatamente um rótulo type:, como type: bug ou type: feature request, de acordo com o tipo de 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 trabalhado por um novo colaborador da comunidade, o membro da DevEx vai atribuir o rótulo good first issue. Nessa fase, o problema entra no pool de problemas abertos não triados.

Cada subequipe do Bazel vai triar todos os problemas nos rótulos que possui, de preferência a semanalmente. A subequipe vai analisar e avaliar o problema e fornecer uma resolução, se possível. Se você é 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 RP para 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, na sigla em inglês) da equipe para o roteamento.
    1. O TL pode atribuir outra pessoa para revisar a RP.
  4. O revisor atribuído analisa a RP e trabalha com o autor até que ela seja aprovada ou descartada.
  5. Se aprovado, o revisor importa as confirmações da RP para o sistema de controle de versão interno do Google para mais testes. Como o Bazel é o mesmo sistema de build usado internamente no Google, precisamos testar todas as confirmações de RP no conjunto de testes internos. É por isso que não mesclamos as RPs 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 triar todos os problemas nos rótulos que possuem, de preferência semanalmente.

Problemas

  1. Filtre a lista de problemas pelo rótulo da equipe e o untriaged rótulo.
  2. Analise o problema.
  3. Identifique um nível de prioridade e atribua o rótulo.
    1. O problema já pode ter sido priorizado pela subequipe da DevEx se for um P0. Re-priorize, 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 rótulo untriaged.

É necessário estar na organização bazelbuild organization para adicionar ou remover rótulos.

Solicitações de envio

  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ê for atribuído à revisão, mas não for a pessoa certa para ela, 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 revisão de código.
  4. Aprove a RP.
  5. Verifique se todos os testes foram aprovados.
  6. Importe o patch para o sistema de controle de versão interno e execute os pré-envios internos.
  7. Envie o patch interno. Se o patch for enviado e exportado com sucesso, a RP será fechada automaticamente pelo GitHub.

Prioridade

As definições de prioridade a seguir serão usadas pelos mantenedores para triar problemas.

  • P0 : funcionalidade principal quebrada que faz com que uma versão do Bazel (menos candidatos a lançamento) fique inutilizável ou um serviço inativo que afeta 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 mudança incompatível que não estava em conformidade com a política de mudanças interruptivas. Não há 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 do 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 abordado, mas não estamos trabalhando nele no momento. Problema moderado em uma versão lançada do Bazel que é inconveniente para um usuário e precisa ser abordado em uma versão futura e/ou uma solução alternativa fácil.
  • P3 : correção de bug menor desejável ou melhoria com pequeno impacto. Não priorizado em roteiros do Bazel ou em qualquer lançamento iminente, mas as contribuições da comunidade são incentivadas.
  • P4 : defeito de baixa prioridade ou solicitação de recurso que provavelmente não será fechado. Também pode ser mantido aberto para uma possível repriorização se mais usuários forem afetados.
  • ice-box
    • Problemas que não temos tempo para lidar nem para o tempo para 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.

Rótulos de equipe

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

Consulte a lista completa de rótulos aqui.