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:
- Servir como fonte de verdade dos mantenedores para o processo de contribuição do projeto.
- 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
- Um usuário cria um problema usando o modelo de problemas e ele entra no pool de problemas abertos não analisados.
- Um membro da rotação de subequipes de Experiência do desenvolvedor (DevEx) analisa o
problema.
- 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.
- 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.
- 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.
- 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.
- O membro do DevEx atribui o rótulo
untriaged
e exatamente um rótulo de equipe para roteamento. - O membro DevEx também atribui exatamente um rótulo
type:
, comotype: bug
outype: feature request
, de acordo com o tipo de problema. - Para problemas específicos da plataforma, o membro DevEx atribui um rótulo
platform:
, comoplatform: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
- Um usuário cria uma solicitação de envio.
- 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.
- 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.
- O TL pode designar outra pessoa para avaliar o RP.
- O revisor atribuído analisa a RP e trabalha com o autor até que ela seja aprovada ou descartada.
- 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.
- Se a confirmação importada passar em todos os testes internos, ela será comprimida e exportada de volta para o GitHub.
- 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
- Filtre a lista de problemas pelo rótulo da equipe e pelo rótulo
untriaged
. - Analise o problema.
- Identifique um nível de prioridade e atribua um rótulo.
- O problema pode já ter sido priorizado pela subequipe DevEx se for P0. Mude a prioridade, se necessário.
- Cada problema precisa ter exatamente um marcador de prioridade. Se um problema for P0 ou P1, supomos que ele já está sendo resolvido.
- Remova o marcador
untriaged
.
Observe que você precisa estar na organização bazelbuild para poder adicionar ou remover rótulos.
Solicitações de envio
- Filtre a lista de solicitações de envio pelo rótulo da sua equipe.
- Analise as solicitações de envio abertas.
- 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.
- Trabalhe com o criador da solicitação de envio para concluir uma análise de código.
- Aprove o PR.
- Confira se todos os testes são aprovados.
- Importe o patch para o sistema de controle de versões interno e execute os pré-envios internos.
- 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
team-Android
: problemas da equipe do Android- Contato: ahumesky
team-Bazel
: problemas gerais de produto/estratégia do Bazel- Contato: sventiffe
team-Build-Language
: problemas no BUILD, nas APIs .bzl e no Stardoc.- Contato: brandjon
team-Configurability
: problemas para a equipe de configuração- Contato: gregestren
team-Core
: problemas da equipe principal- Contato: haxorz
team-Documentation
: problemas para a equipe de documentação- Contato: communikit
team-ExternalDeps
: processamento de dependências externas, Bzlmod, repositórios remotos e arquivo do ESPAÇO DE TRABALHO- Contato: meteorcloudy
team-Local-Exec
: problemas para a equipe de execução (local).- Contato: meisterT
team-OSS
: problemas para a equipe do Bazel OSS: instalação, processo de lançamento, empacotamento do Bazel, site, infraestrutura de documentos- Contato: meteorcloudy
team-Performance
: problemas da equipe de desempenho do Bazel- Contato: meisterT
team-Remote-Exec
: problemas de execução (remoto)- Contato: coeuvre
team-Rules-CPP
: problemas de regras de C++, incluindo a lógica de regras nativas da Apple- Contato: oquenchil
team-Rules-Java
: problemas com regras do Java- Contato: comius
team-Rules-Python
: problemas das regras nativas do Python- Contato: comius
team-Rules-Server
: problemas em regras do lado do servidor incluídas no Bazel- Contato: comius
team-Starlark-integration
: integração entre Bazel e Starlark não API. Inclui: como o Bazel aciona o intérprete Starlark, o Stardoc, a injeção de integrados e a codificação de caracteres. Não inclui: problemas de linguagem BUILD ou .bzl.- Contato: brandjon
team-Starlark-interpreter
: problemas para o intérprete do Starlark (qualquer coisa em java.net.starlark). Os problemas das APIs .bzl e BUILD, que representam a integração do Bazel com o Starlark, ficam emteam-Build-Language
.- Contato: brandjon
Para novos problemas, descontinuamos os rótulos category: *
em favor dos rótulos
de equipe.
Veja a lista completa de marcadores aqui.