Guia para mantenedores do Bazel

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

Se você quiser contribuir com o Bazel, leia Como contribuir para o Bazel.

Os objetivos desta página são:

  1. Servir como a fonte da verdade dos mantenedores no 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 estes:

  • Processo de lançamento: gerencie o processo de lançamento do Bazel.
  • Equipe Verde: crie um ecossistema saudável de regras e ferramentas.
  • Desenvolvedores de experiência do desenvolvedor: incentive contribuições externas, analise 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 da 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 entra no conjunto 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 DevEx geralmente fechará o problema e redirecionará o usuário para StackOverflow e bazel-discuss para maior 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 esse problema para o repositório correto.
    3. Se o problema for vago ou tiver informações ausentes, o membro DevEx 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. Após analisar o problema, o membro DevEx decide se o problema requer atenção imediata. Se for o caso, ele vai atribuir o rótulo de prioridade P0 e um proprietário da lista de líderes da equipe.
  4. O membro 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 grupo de problemas abertos não resolvidos.

Cada subequipe do Bazel faz a triagem de todos os problemas nos rótulos que possui, de preferência semanalmente. A subequipe vai analisar e avaliar o problema e apresentar uma solução, se possível. Se você for o 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ê faz parte de uma equipe do Bazel e envia um PR para sua própria área, você é 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 da equipe (TL, na sigla em inglês) para roteamento.
    1. O líder de equipe pode designar outra pessoa para revisar o PR.
  4. O revisor designado analisa o PR e trabalha com o autor até que ele seja aprovado ou descartado.
  5. Se aprovado, o revisor importa as confirmações do RP para o sistema de controle de versões interno do Google para mais testes. Como o Bazel é o mesmo sistema de compilação usado internamente no Google, precisamos testar todas as confirmações de PR no pacote de testes internos. É por esse motivo que não mesclamos PRs diretamente.
  6. Se a confirmação importada for aprovada em todos os testes internos, ela será comprimida e exportada de volta para o GitHub.
  7. Quando a confirmação é mesclada à mestre, o GitHub fecha automaticamente o PR.

Minha equipe é proprietária de uma gravadora. O que devo fazer?

As subequipes precisam fazer a triagem de todos os problemas nos rótulos que têm, de preferência semanalmente.

Issues

  1. Filtre a lista de problemas pelo marcador da equipe e pelo marcador 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 de DevEx se for um P0. Se necessário, mude a prioridade.
    2. Cada problema precisa ter exatamente um rótulo de prioridade. Se um problema é P0 ou P1, presumimos que ele está ativamente resolvido.
  4. Remova o rótulo untriaged.

Você precisa estar na organização bazelbuild 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. Revise as solicitações de envio abertas.
    1. Opcional: se você for designado para a avaliação, mas não for a pessoa adequada para ela, atribua novamente o revisor apropriado para que ele faça a revisão do código.
  3. Trabalhe com o criador da solicitação de envio para concluir uma revisão do código.
  4. Aprove o PR.
  5. Confira se todos os testes foram aprovados.
  6. Importe o patch para o sistema de controle de versões interno e execute os pré-envios internos.
  7. Enviar 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: funcionalidade corrompida importante que faz com que uma versão do Bazel (menos as candidatas) 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 estava em conformidade com a política Alteração interruptiva. Não existe uma 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 há uma solução alternativa prática. Normalmente, isso não requer ação imediata. Com alta demanda e planejado no roteiro do trimestre atual.
  • P2: defeito ou recurso que precisa ser corrigido, mas ainda não estamos trabalhando. Um problema de ativação moderado em uma versão lançada do Bazel é 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 ou aprimoramento pequeno desejável com pequeno impacto. Não tem prioridade nos roteiros do Bazel ou em qualquer lançamento iminente. No entanto, as contribuições da comunidade são incentivadas.
  • P4: defeito ou solicitação de recurso de baixa prioridade que provavelmente não será encerrado. Também podem ser mantidas abertas para 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 nem tempo para aceitar contribuições no momento. Fecharemos esses problemas para indicar que ninguém está trabalhando neles, mas continuaremos a monitorar a validade deles ao longo do tempo e os restabeleceremos se um número suficiente de pessoas for afetado e se tivermos recursos para lidar com eles. Como sempre, sinta-se livre 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 dos de equipe.

Veja a lista completa de marcadores aqui.