proposal

GRPC RFCS

Introdução

Leia as regras de governança e as diretrizes de contribuição da organização GRPC antes de prosseguir.

Este repo contém as propostas de design para alterações substanciais de recursos para o GRPC que precisam ser projetadas antecipadamente. O objetivo do processo de design inicial é::

• Forneça maior visibilidade à comunidade sobre as próximas mudanças e as considerações de design ao seu redor.
• Forneça capacidade de raciocinar sobre "conjuntos" maiores de alterações grandes demais para serem cobertas em um problema ou em um PR.
• Estabeleça um processo consistente para a participação estruturada da comunidade em grandes mudanças, especialmente aquelas que afetam vários tempos de execução e implementações.

Pré -requisitos

Esse processo precisa ser seguido para qualquer alteração significativa no GRPC que precise de design. Alterações consideradas significativas podem ser:

• Recursos que precisam de implementação nos tempos de execução e idiomas.
• Alterações do processo que afetam como o produto GRPC é implementado.
• Quebrar mudanças na API pública (ou seja, grandes mudanças).

Processo

1. Fork o repositório e copie o modelo grfc-template.md.
2. Renomeie-o para $CategoryName-$Summary , por exemplo: A6-client-retries.md (consulte as definições de categoria abaixo)
   • Para propostas específicas do idioma, inclua o nome do idioma: L##-$Language-$Summary . Nomes canônicos: core , cpp , csharp , go , java , node , objc , php , python , ruby .
3. Escreva o RFC.
4. Envie uma solicitação de tração.
5. Alguém da equipe GRPC será designado como aprovador como parte desta revisão. Depois que o aprovador for atribuído, o proprietário precisa iniciar uma discussão sobre o GRPC-IO e atualizar o PR com o link de discussão. Depois disso, o proprietário deve atualizar o GRFC para o estado da In Review . Espera -se que o aprovador ajude o proprietário ao longo desse processo, conforme necessário.
6. Por pelo menos um período de 10 dias úteis (o período mínimo de comentários), espera -se que o proprietário responda aos comentários e faça atualizações na RFC como novas confirmações com o PR. Através do processo, a discussão precisa ser mantida no segmento designado na lista de discussão para evitar conversas de lança. O proprietário é incentivado a solicitar o máximo de feedback sobre a proposta possível durante esse período. Os comentários de RP devem ser limitados à formatação e ao vocabulário.
7. Se houver consenso considerado pelo aprovador durante o período de comentários, o aprovador marcará a proposta como final e atribuirá um número GRFC. Uma vez atribuído (como parte do fechamento da discussão), o proprietário atualizará o estado do PR como final e enviará o PR. Os compromissos não devem ser esmagados; O histórico de compromissos serve como um registro de alterações feitas na proposta.

Aprovador

• Por padrão, a11r é o aprovador, a menos que outro aprovador seja atribuído por proposta.
• Se o aprovador atribuído e o proprietário não puderem resolver um problema satisfatoriamente, o aprovador final ainda será a11r .

Categorias de propostas

As propostas devem ser numeradas em ordem crescente.

• #An - afeta todos os idiomas.
• #Pnn - afeta os processos, como o próprio processo de proposta.
• #Lnnn - Alterações específicas do idioma em APIs externas ou suporte da plataforma.
• #Gnnnn - Alterações no nível do protocolo.

Status da proposta

1. Todo candidato de proposta não comprometida começa no projeto Draft .
2. Depois de aceitar para revisão e publicado no grupo, ele entra no estado In Review .
3. Uma vez aprovado para envio pelo árbitro, ele entra no estado Final . Somente pequenas mudanças são permitidas (o que se qualifica como menor é deixado para o aprovador).
4. Se uma proposta precisar ser revisitada, ela poderá ser transferida de volta ao Draft ou In Review . Isso pode acontecer se os problemas forem descobertos durante a implementação. Nesse ponto, o processo de revisão, conforme descrito acima, deve ser seguido.
5. Depois que uma proposta é Final e se for implementada por um idioma, ela poderá ser atualizada para um status de Implemented com os idiomas implementadores listados. (As versões de listagem não são necessárias.)