proposal

RFC GRPC

Introduction

Veuillez lire les règles de gouvernance et les directives de contribution de l'organisation GRPC avant de procéder.

Ce dépôt contient les propositions de conception pour des changements de fonctionnalités substantiels pour GRPC qui doivent être conçus à l'avance. L'objectif du processus de conception initial est de:

• Offrez une visibilité accrue à la communauté sur les changements à venir et les considérations de conception qui les entourent.
• Offrez la capacité de raisonner sur les «ensembles» de changements plus importants qui sont trop importants pour être couverts soit dans un numéro ou dans un RP.
• Établir un processus cohérent de participation structurée par la communauté sur de grands changements, en particulier ceux qui ont un impact sur plusieurs temps et implémentations.

Condition préalable

Ce processus doit être suivi pour tout changement significatif de GRPC qui nécessite une conception. Les changements considérés comme significatifs peuvent être:

• Fonctionnalités qui nécessitent une implémentation à travers les temps et les langues.
• Les changements de processus qui affectent la façon dont le produit GRPC est mis en œuvre.
• Rompre les modifications de l'API publique (IE Semver Modifications majeures).

Processus

1. Fourchez le dépôt et copiez le modèle Grfc-Template.md.
2. Renommez-le à $CategoryName-$Summary , par exemple: A6-client-retries.md (voir les définitions de catégorie ci-dessous)
   • Pour les propositions spécifiques à la langue, incluez le nom de la langue: L##-$Language-$Summary . Noms canoniques: core , cpp , csharp , go , java , node , objc php , python , ruby .
3. Rédigez le RFC.
4. Soumettre une demande de traction.
5. Quelqu'un de l'équipe GRPC sera attribué en tant qu'approbateur dans le cadre de cette revue. Une fois l'approbateur attribué, le propriétaire doit commencer une discussion sur GRPC-IO et mettre à jour le PR avec le lien de discussion. Une fois cela fait, le propriétaire doit mettre à jour le GRFC à l'état de In Review . On s'attend à ce que l'approbateur aide le propriétaire le long de ce processus au besoin.
6. Pendant au moins une période de 10 jours ouvrables (la période de commentaire minimale), il est prévu que le propriétaire répondra aux commentaires et fera des mises à jour de la RFC en tant que nouveaux engagements dans le PR. Grâce au processus, la discussion doit être conservée sur le fil désigné dans la liste de diffusion afin d'éviter les conversations éclatées. Le propriétaire est encouragé à solliciter autant de commentaires que possible sur la proposition au cours de cette période. Les commentaires de relations publiques doivent être limités à la mise en forme et au vocabulaire.
7. S'il y a un consensus considéré par l'approbateur pendant la période de commentaire, l'approbateur marquera la proposition comme final et lui attribuera un numéro GRFC. Une fois celle-ci attribué (dans le cadre de la fermeture de la discussion), le propriétaire mettra à jour l'état du PR comme final et soumettra le PR. Les commits ne doivent pas être écrasés; L'histoire de la validation sert de journal des modifications apportées à la proposition.

Approbateur

• Par défaut, a11r est l'approbateur, sauf si un autre approbateur est attribué sur une base de proposition.
• Si l'approbateur assigné et que le propriétaire ne peut pas régler de manière satisfaisante un problème, l'approbateur final est toujours a11r .

Catégories de propositions

Les propositions doivent être numérotées par ordre croissant.

• #An - affecte toutes les langues.
• #Pnn - affecte les processus, tels que le processus de proposition lui-même.
• #Lnnn - modifications spécifiques à la langue des API externes ou de la prise en charge de la plate-forme.
• #Gnnnn - Changements de niveau de protocole.

Statut de proposition

1. Chaque candidat de proposition non engagé commence dans le Draft d'état.
2. Après avoir accepté pour examen et publié au groupe, il entre In Review .
3. Une fois qu'il est approuvé pour soumission par l'arbitre, il entre dans l'état Final . Seuls les modifications mineures sont autorisées (ce qui est considéré comme mineur est laissé à l'approbateur).
4. Si une proposition doit être revisitée, elle peut être retournée au Draft ou In Review . Cela peut se produire si des problèmes sont découverts lors de la mise en œuvre. À quel moment, le processus d'examen décrit ci-dessus doit être suivi.
5. Une fois qu'une proposition est Final et si elle a été implémentée par une langue, elle peut être mise à jour à un statut d' Implemented avec les langages d'implémentation répertoriés. (Les versions de listing ne sont pas requises.)