Guia para mantenedores do Bazel

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

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 revisados.
  2. Um membro da rotação da subequipe de experiência do desenvolvedor (DevEx, na sigla em inglês) 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 da 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 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 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 pull.
  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 rótulo untriaged.
  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 pull 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 um novo lançamento 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 resolvido 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 resolvido, 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 resolvido 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. No entanto, 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.

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.