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: monitorar a integridade da CI do Bazel e informar falhas.
  • 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 problema 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, 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 {: .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 semanalmente. A subequipe vai analisar e avaliar o problema e fornecer uma resoluçã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 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 solicitação de envio 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 analisar a solicitação de envio.
  4. O revisor atribuído analisa a solicitação de envio e trabalha com o autor até que ela seja aprovada ou descartada.
  5. Se aprovado, o revisor importa as confirmações da solicitação de envio 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 solicitação de envio no conjunto de testes internos. É por isso que não mesclamos as solicitações de envio 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 solicitação de envio.

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, vamos presumir que ele está sendo trabalhado ativamente.
  4. Remova o rótulo untriaged.

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

Solicitações de envio

As solicitações de envio (PRs, na sigla em inglês) são a principal maneira de os colaboradores externos agregarem valor ao Bazel. Como um projeto de código aberto, é importante garantir que as solicitações de envio sejam analisadas e processadas de maneira oportuna e eficiente.

  • Triagem

    Analise regularmente as solicitações de envio recebidas com o rótulo awaiting-review e o rótulo da equipe. Isso pode ser feito com uma rotação ou uma reunião de triagem regular. Esperamos que cada solicitação de envio receba uma resposta inicial em até sete dias úteis.

  • Resposta

    • Se a solicitação de envio parecer boa, aprove-a e aplique o rótulo awaiting-PR-merge. A equipe do gTech vai importar a solicitação de envio como uma CL.
    • Caso contrário, deixe seu feedback e substitua o rótulo awaiting-review pelo rótulo awaiting-user-response. A subequipe da DevEx vai atualizar o rótulo regularmente se o autor da solicitação de envio responder.
    • Para solicitações de envio com mudanças importantes, considere pedir um documento de design ou uma discussão anterior em um problema.

  • Interdição

    Devido a recursos limitados, é importante fechar as solicitações de envio que não atendem aos padrões do Bazel ou que não temos capacidade de analisar ou manter.

    • Se a solicitação de envio não estiver alinhada às metas do Bazel, feche-a com uma explicação.
    • Se a solicitação de envio for muito grande e complexa, feche-a com uma solicitação para dividi-la em partes menores.
    • Se a qualidade do código da solicitação de envio não atender aos nossos padrões, feche-a com uma explicação.
    • Se o custo de manutenção futura do código for muito alto, feche-o com uma explicação.
    • Se a solicitação de envio estiver aguardando a resposta do usuário por muito tempo e o colaborador não tiver respondido, ela será marcada automaticamente como obsoleta após 30 dias e fechada após outros 30 dias.

    Ao fechar uma solicitação de envio, seja educado e explique o motivo do fechamento.

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 alterações 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 sério 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, mas as contribuições da comunidade são incentivadas.
  • P4 : defeito de baixa prioridade ou solicitação de recurso que provavelmente não será fechada. 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.