proposal

GRPC RFCS

Einführung

Bitte lesen Sie die Regeln und Beitragsrichtlinien der GRPC -Organisation vor dem Verfahren.

Dieses Repo enthält die Entwurfsvorschläge für wesentliche Merkmalsänderungen für GRPC, die im Voraus gestaltet werden müssen. Das Ziel des Entwurfsprozesses im Voraus ist:

• Stellen Sie der Community die Community mehr Sichtbarkeit zu bevorstehenden Veränderungen und den Entwurfsüberlegungen um sie herum.
• Bieten Sie die Fähigkeit zur Grund, dass größere „Sätze“ von Änderungen, die zu groß sind, um entweder in einem Problem oder in einer PR abgedeckt zu werden.
• Erstellen Sie einen konsistenten Prozess für die strukturierte Teilnahme durch die Community zu großen Veränderungen, insbesondere für solche, die sich auf mehrere Laufzeiten und Implementierungen auswirken.

Voraussetzungen

Dieser Prozess muss für eine wesentliche Änderung der GRPC befolgt werden, die Design benötigt. Änderungen, die als signifikant angesehen werden, können sein:

• Merkmale, die implementiert werden müssen über Laufzeiten und Sprachen hinweg.
• Prozessänderungen, die sich auf die Implementierung des GRPC -Produkts auswirken.
• Veränderungen an der öffentlichen API (dh Semver -Hauptänderungen).

Verfahren

1. Geben Sie das Repo auf und kopieren Sie die Vorlage grfc-template.md.
2. Benennen Sie es in $CategoryName-$Summary , A6-client-retries.md .
   • Für sprachspezifische Vorschläge geben Sie den Namen der Sprache an: L##-$Language-$Summary . Kanonische Namen: core , cpp , csharp , go , java , node , objc , php , python , ruby .
3. Schreiben Sie den RFC auf.
4. Senden Sie eine Pull -Anfrage.
5. Jemand vom GRPC -Team wird als Teil dieser Überprüfung als Genehmiger zugewiesen. Sobald der Genehmiger zugewiesen ist, muss der Eigentümer eine Diskussion über GRPC-IO starten und die PR mit dem Diskussionslink aktualisieren. Danach sollte der Eigentümer den GRFC auf den Stand der In Review aktualisieren. Es wird erwartet, dass der Genehmiger dem Eigentümer bei Bedarf bei diesem Prozess hilft.
6. Für mindestens einen Zeitraum von 10 Werktagen (Mindestdauer der Mindestdauer) wird erwartet, dass der Eigentümer auf die Kommentare antwortet und die RFC als neue Commits an die PR aktualisiert. Während des Vorgangs muss die Diskussion in der Mailingliste am bestimmten Thread aufbewahrt werden, um Splittergespräche zu vermeiden. Der Eigentümer wird ermutigt, in diesem Zeitraum so viel Feedback zum Vorschlag wie möglich einzuholen. PR -Kommentare sollten auf Formatierung und Wortschatz beschränkt sein.
7. Wenn der Konsens, wie es während der Kommentierungszeit vom Genehmigenden angesehen wird, wird der Genehmiger den Vorschlag als endgültig markiert und ihm eine GRFC -Nummer zuweist. Sobald dies zugewiesen ist (als Teil der Diskussionsverschluss), aktualisiert der Eigentümer den Zustand des PR als endgültig und reicht die PR ein. Commits darf nicht gequetscht werden; Die Verschingungsgeschichte dient als Protokoll der Änderungen am Vorschlag.

Genehmiger

• Standardmäßig ist a11r der Genehmiger, es sei denn, ein anderer Genehmiger wird pro Zeitpunkt zugewiesen.
• Wenn der zugewiesene Genehmiger und der Eigentümer ein Problem zufriedenstellend nicht zufrieden stellen können, ist der endgültige Genehmiger immer noch a11r .

Vorschlagkategorien

Die Vorschläge sind in zunehmender Reihenfolge zu zahlen.

• #An - betrifft alle Sprachen.
• #Pnn - wirkt sich auf Prozesse wie den Vorschlagsprozess selbst aus.
• #Lnnn - Sprachspezifische Änderungen an externen APIs oder Plattformunterstützung.
• #Gnnnn - Protokollspiegeländerungen.

Vorschlagstatus

1. Jeder nicht übereinstimmende Vorschlagkandidat startet im Draft des Staates.
2. Nachdem es zur Überprüfung angenommen und an die Gruppe veröffentlicht wurde, tritt es In Review ein.
3. Sobald es vom Arbiter zur Einreichung genehmigt wurde, geht es in den Final Zustand. Es sind nur geringfügige Änderungen zulässig (was als Nebenfach dem Genehmiger überlassen wird).
4. Wenn ein Vorschlag überarbeitet werden muss, kann er auf den Draft oder In Review zurückgeführt werden. Dies kann passieren, wenn während der Implementierung Probleme entdeckt werden. An diesem Punkt muss der oben beschriebene Überprüfungsprozess befolgt werden.
5. Sobald ein Vorschlag Final ist und wenn er von einer Sprache implementiert wurde, kann er auf einen Status der Implemented implementierenden Sprachen aktualisiert werden. (Listing -Versionen sind nicht erforderlich.)