Guia para mantenedores do Bazel

Informar um problema Ver origem

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. Sirvam como fonte de 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 estes:

  • Processo de lançamento: gerencie o processo de lançamento do Bazel.
  • Equipe Verde: desenvolva um ecossistema saudável de regras e ferramentas.
  • jardineiros de experiência para desenvolvedores: 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 Green sobre a infraestrutura de CI do Bazel no repositório bazelbuild/execution-integration.

Ciclo de vida de um problema

  1. Um usuário cria um problema escolhendo um dos modelos de problemas e 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 DevEx geralmente fechará o problema e redirecionará o usuário para StackOverflow e 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 DevEx vai transferir esse 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 escolhe o modelo de problema {: .external} correto ou fornece informações incompletas.
  3. Depois de analisar o problema, o membro DevEx decide se o problema requer atenção imediata. Se for o caso, ele 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.
  7. Se o problema for de baixa prioridade e puder ser resolvido por um novo colaborador da comunidade, o membro DevEx atribuirá o rótulo good first issue. Nessa etapa, o problema entra no conjunto de problemas abertos não resolvidos.

Cada subequipe do Bazel vai fazer a triagem de todos os problemas nos próprios identificadores, de preferência uma vez por semana. A subequipe vai analisar e avaliar o problema e oferecer 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ê é membro de uma equipe do Bazel e envia um PR para sua própria área, você é responsável por atribuir seu rótulo de 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) da equipe para o roteamento.
    1. O TL 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 PR para o sistema interno de controle de versões 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 RP no pacote de testes internos. É por isso que não combinamos 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 com a 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 marcadores, de preferência uma vez por semana.

Issues

  1. Filtre a lista de problemas por marcador de equipe e 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 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 já está sendo resolvido.
  4. Remova o rótulo untriaged.

Para adicionar ou remover rótulos, é preciso estar na organização bazelbuild.

Solicitações de envio

  1. Filtre a lista de solicitações de envio por rótulo da equipe.
  2. Revise as solicitações de envio abertas.
    1. Opcional: se for atribuído à revisão, mas você não for a pessoa certa para ela, atribua novamente o revisor apropriado para que ele faça a revisão do código.
  3. Trabalhar com o criador da solicitação de envio para concluir uma revisão do código.
  4. Aprove o PR.
  5. Verificar 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, o PR será fechado automaticamente pelo GitHub.

Prioridade

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

  • P0: principal funcionalidade corrompida que faz com que uma versão do Bazel (menos candidatos a lançamento) 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, não requer ação imediata. Com alta demanda e conforme planejado no roteiro do trimestre atual.
  • P2: defeito ou recurso que precisa ser resolvido, mas ainda não estamos trabalhando nele. Problema ativo 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 uma solução alternativa fácil.
  • P3: é uma pequena correção ou aprimoramento de bug com pouco 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 de baixa prioridade ou solicitação de recurso que provavelmente não será encerrada. Ela também pode ser mantida aberta para uma possibilidade de re-priorização se mais usuários forem afetados.
  • caixa de gelo
    • Problemas com os quais não temos tempo de resolver no momento nem tempo para aceitar contribuições. Encerraremos esses problemas para indicar que ninguém está trabalhando neles, mas continuaremos monitorando a validade deles ao longo do tempo e os recuperaremos se um número suficiente de pessoas for impactado e se tivermos recursos para lidar com eles. Como sempre, sinta-se à vontade para comentar ou reagir a esses problemas, mesmo quando fechados.

Marcadores de equipe

Para novos problemas, suspendemos o uso dos rótulos category: * em favor dos rótulos de equipe.

Veja a lista completa de marcadores aqui.