proposal

GRPC RFCS

Introducción

Lea las reglas de gobierno y las pautas de contribución de la Organización GRPC antes de continuar.

Este repositorio contiene las propuestas de diseño para cambios de características sustanciales para GRPC que deben diseñarse por adelantado. El objetivo del proceso de diseño inicial es:

• Proporcione una mayor visibilidad a la comunidad en los próximos cambios y las consideraciones de diseño a su alrededor.
• Proporcione la capacidad de razonar sobre "conjuntos" más grandes de cambios que son demasiado grandes para ser cubiertos en un problema o en un PR.
• Establezca un proceso consistente para la participación estructurada por parte de la comunidad en grandes cambios, especialmente aquellos que afectan múltiples tiempos e implementaciones de ejecución.

Requisitos previos

Este proceso debe seguirse para cualquier cambio significativo a GRPC que necesita diseño. Los cambios que se consideran significativos pueden ser:

• Características que necesitan implementación en tiempos de ejecución e idiomas.
• Cambios de proceso que afectan la forma en que se implementa el producto GRPC.
• Rompiendo cambios en la API pública (es decir, los cambios importantes de Semver).

Proceso

1. Bifurca el repositorio y copie la plantilla GRFC-Template.md.
2. Cambíe el nombre a $CategoryName-$Summary , por ejemplo: A6-client-retries.md (ver definiciones de categoría a continuación)
   • Para propuestas específicas del lenguaje, incluya el nombre del idioma: L##-$Language-$Summary . Nombres canónicos: core , cpp , csharp , go , java , node , objc , php , python , ruby .
3. Escribir el RFC.
4. Envíe una solicitud de extracción.
5. Alguien del equipo de GRPC será asignado como aprobador como parte de esta revisión. Una vez que se asigna el aprobador, el propietario debe iniciar una discusión sobre GRPC-IO y actualizar el PR con el enlace de discusión. Una vez hecho esto, el propietario debe actualizar el GRFC al estado de In Review . Se espera que el aprobador ayude al propietario a lo largo de este proceso según sea necesario.
6. Durante al menos un período de 10 días hábiles (el período mínimo de comentarios), se espera que el propietario responda a los comentarios y realice actualizaciones al RFC como nuevas compromisos con el PR. A través del proceso, la discusión debe mantenerse en el hilo designado en la lista de correo para evitar la astilla de las conversaciones. Se alienta al propietario a solicitar tantos comentarios sobre la propuesta como sea posible durante este período. Los comentarios de relaciones públicas deben limitarse al formato y al vocabulario.
7. Si hay consenso según lo considere el aprobador durante el período de comentarios, el aprobador marcará la propuesta como final y le asignará un número GRFC. Una vez que esto se asigne (como parte del cierre de la discusión), el propietario actualizará el estado del PR como final y enviará el PR. Los compromisos no deben ser aplastados; El Historial de Commit sirve como un registro de cambios realizados a la propuesta.

Aprobador

• Por defecto, a11r es el aprobador a menos que otro aprobador se asigne por propuesta.
• Si el aprobador asignado y el propietario no pueden resolver satisfactoriamente un problema, el aprobador final sigue siendo a11r .

Categorías de propuestas

Las propuestas se numerarán en orden creciente.

• #An - afecta todos los idiomas.
• #Pnn : afecta los procesos, como el proceso de propuesta en sí.
• #Lnnn - Cambios específicos del lenguaje en API externos o soporte de plataforma.
• #Gnnnn - Cambios en el nivel de protocolo.

Estatus de propuesta

1. Cada candidato de propuesta no comprometida comienza en el Draft del estado.
2. Después de que aceptó para su revisión y publicado en el grupo, ingresa al estado In Review .
3. Una vez que el árbitro lo aprueba, entra en el estado Final . Solo se permiten cambios menores (lo que califica como menor se deja al aprobador).
4. Si una propuesta necesita ser revisada, puede regresar al Draft o In Review . Esto puede suceder si se descubren problemas durante la implementación. En ese momento, se debe seguir el proceso de revisión como se describe anteriormente.
5. Una vez que una propuesta es Final y si ha sido implementada por un idioma, se puede actualizar a un estado de Implemented con los idiomas de implementación enumerados. (No se requieren versiones de listado).