proposal

GRPC RFC

소개

진행하기 전에 GRPC 조직의 거버넌스 규칙 및 기부 지침을 읽으십시오.

이 repo에는 선불 설계 해야하는 GRPC의 실질적인 기능 변경에 대한 설계 제안이 포함되어 있습니다. 선행 설계 프로세스의 목표는 다음과 같습니다.

• 다가오는 변화와 주변의 설계 고려 사항에 대해 커뮤니티에 가시성이 향상됩니다.
• 문제 나 PR에서 다루기에는 너무 큰 변화의 더 큰 "세트"에 대해 추론 할 수있는 능력을 제공합니다.
• 커뮤니티가 큰 변화, 특히 여러 런타임과 구현에 영향을 미치는 변화에 대해 커뮤니티의 구조화 된 참여를위한 일관된 프로세스를 설정하십시오.

전제 조건

이 프로세스는 설계가 필요한 GRPC에 대한 중대한 변경을 위해 따라야합니다. 중요한 것으로 간주되는 변화는 다음과 같습니다.

• 런타임 및 언어에 걸쳐 구현이 필요한 기능.
• GRPC 제품 구현 방식에 영향을 미치는 프로세스 변경.
• 공개 API의 변화를 중단합니다 (예 : Semver 주요 변경).

프로세스

1. repo를 포크하고 템플릿 Grfc-template.md를 복사하십시오.
2. $CategoryName-$Summary (예 : A6-client-retries.md )로 이름을 바꿉니다 (아래 카테고리 정의 참조)
   • 언어 별 제안의 경우 언어 이름을 포함하십시오 : L##-$Language-$Summary . 표준 이름 : core , cpp , csharp , go , java , node , objc , php , python , ruby .
3. RFC를 작성하십시오.
4. 풀 요청을 제출하십시오.
5. GRPC 팀의 누군가 가이 검토의 일부로 승인자로 지정됩니다. 승인자가 할당되면 소유자는 GRPC-IO에 대한 토론을 시작하고 토론 링크로 PR을 업데이트해야합니다. 이 작업이 완료되면 소유자는 grfc를 In Review 상태로 업데이트해야합니다. 승인자는 필요에 따라이 과정을 따라 소유자가 도움을 줄 것으로 예상됩니다.
6. 영업일 기간 (최소 의견 기간)의 기간 동안 소유자는 댓글에 응답하고 새로운 PR에 대한 새로운 커밋으로 RFC를 업데이트 할 것으로 예상됩니다. 이 과정을 통해 논의는 대화를 피하기 위해 메일 링리스트의 지정된 스레드에 보관해야합니다. 소유자는이 기간 동안 가능한 한 제안에 대한 많은 피드백을 요청하는 것이 좋습니다. PR 의견은 서식 및 어휘로 제한되어야합니다.
7. 주석 기간 동안 승인자로 간주되는 합의가있는 경우 승인자는 제안을 최종으로 표시하고 GRFC 번호를 할당합니다. 이것이 (토론 폐쇄의 일부로) 할당되면 소유자는 PR의 상태를 최종으로 업데이트하고 PR을 제출합니다. 커밋은 찌그러져서는 안됩니다. Commit History는 제안에 대한 변경 로그 역할을합니다.

승인

• 기본적으로 a11r 은 다른 승인자가 비공개별로 할당되지 않는 한 승인입니다.
• 할당 된 승인자와 소유자가 문제를 만족스럽게 해결할 수없는 경우, 최종 승인은 여전히 a11r 입니다.

제안 범주

제안서는 명령의 증가로 번호가 매겨 져야합니다.

• #An 모든 언어에 영향을 미칩니다.
• #Pnn 제안 프로세스 자체와 같은 프로세스에 영향을 미칩니다.
• #Lnnn 언어 별 변경 외부 API 또는 플랫폼 지원 변경.
• #Gnnnn 프로토콜 수준 변경.

제안 상태

1. 모든 커밋되지 않은 제안 후보는 Draft 상태에서 시작됩니다.
2. 검토를 수락하고 그룹에 게시 한 후에는 In Review 들어갑니다.
3. 중재인이 제출하도록 승인되면 Final 상태로 들어갑니다. 사소한 변경 만 허용됩니다 (미성년자가 승인을받는 자격이 있음).
4. 제안서를 재검토 해야하는 경우 Draft 또는 In Review 상태로 다시 이동할 수 있습니다. 구현 중에 문제가 발견되면 발생할 수 있습니다. 이 시점에서 위에서 설명한 검토 프로세스를 따라야합니다.
5. 제안이 Final 이고 언어로 구현 된 경우 구현 언어로 Implemented 상태로 업데이트 될 수 있습니다. (목록 버전이 필요하지 않습니다.)