Guia para mantenedores do Bazel

Informar um problema Acessar código-fonte

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. Servir como fonte de 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 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, revise problemas e solicitações de envio 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/complete-integration (em inglês).

Ciclo de vida de um problema

  1. Um usuário cria um problema usando o modelo de problemas e ele entra no pool de problemas abertos não analisados.
  2. Um membro da rotação de subequipes 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 DevEx geralmente fechará o problema e redirecionará o usuário para StackOverflow e bazel-discuss para ter mais visibilidade sobre a questão.
    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 faltando, o membro do DevEx vai atribuir o problema de volta ao usuário para que ele peça mais informações antes de prosseguir. 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. Em caso afirmativo, eles vão atribuir o rótulo de prioridade P0 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 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 de problema.
  6. Para problemas específicos da plataforma, o membro DevEx atribui um rótulo platform:, como platform:apple para problemas específicos do Mac. Nessa etapa, o problema entra no pool de problemas em aberto não resolvidos.

Cada subequipe do Bazel fará a triagem de todos os problemas com os próprios rótulos, de preferência a cada semana. A subequipe analisará e avaliará o problema e fornecerá uma soluçã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ê é membro de uma equipe do Bazel e envia um RP na sua própria área, é 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 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 designar outra pessoa para avaliar o 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 do PR no sistema de controle de versões 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 PRs diretamente.
  6. Se a confirmação importada passar em todos os testes internos, ela será comprimida e exportada 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 possuírem, de preferência a cada 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 um rótulo.
    1. O problema pode já ter sido priorizado pela subequipe DevEx se for P0. Mude a prioridade, se necessário.
    2. Cada problema precisa ter exatamente um marcador de prioridade. Se um problema for P0 ou P1, supomos que ele já está sendo resolvido.
  4. Remova o marcador untriaged.

Observe que você precisa estar na organização bazelbuild para poder adicionar ou remover rótulos.

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ê foi designado para a revisão, mas não for a pessoa certa 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 os pré-envios internos.
  7. Envie o patch interno. Se o patch for enviado e exportado com sucesso, o PR será fechado automaticamente pelo GitHub.

Prioridade

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

  • P0: principal funcionalidade corrompida que faz com que uma versão do Bazel (menos as versões candidatas) não seja utilizável, ou um serviço desativado 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 alteração interruptiva incompatível que não estava em conformidade com a política de alteração interruptiva. Não existe uma solução alternativa prática.
  • P1: recurso ou defeito 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 requer ação imediata. em alta demanda e planejada no roteiro do trimestre atual.
  • P2: defeito ou recurso que precisa ser resolvido, mas não estamos trabalhando. Problema ativo moderado em uma versão lançada do Bazel que é inconveniente para um usuário que precisa ser resolvido em uma versão futura e/ou há uma solução fácil.
  • P3: correção de pequeno bug ou melhoria desejável com impacto pequeno. Não são priorizadas nos roteiros do Bazel ou em qualquer versão 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á encerrada. Também podem ser mantidos abertos para uma possível nova priorização se mais usuários forem afetados.
  • caixa de gelo
    • Problemas que, no momento, não temos tempo para resolver nem tempo para aceitar contribuições. Encerraremos esses problemas para indicar que ninguém está trabalhando neles, mas continuaremos a monitorar a validade deles ao longo do tempo e reativá-los se um número suficiente de pessoas for impactado e se tivermos recursos para lidar com eles. Como sempre, fique à vontade para comentar ou adicionar reações, mesmo quando fechados.

Marcadores de equipe

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

Veja a lista completa de marcadores aqui.