proposal

GRPC RFCS

Введение

Пожалуйста, прочитайте правила управления и взносов организации GRPC, прежде чем продолжить.

Этот репо содержит проектные предложения для существенных изменений функций для GRPC, которые должны быть разработаны заранее. Цель исходящего процесса проектирования -:

• Обеспечить повышенную видимость сообществу о предстоящих изменениях и соображениях дизайна вокруг них.
• Обеспечить способность рассуждать о больших «наборах» изменений, которые слишком велики, чтобы быть покрытыми либо в проблеме, либо в PR.
• Установить последовательный процесс для структурированного участия сообществом в больших изменениях, особенно те, которые влияют на множественные время забега и реализации.

Предварительные условия

За этим процессом необходимо следовать за любые существенные изменения в GRPC, который нуждается в проектировании. Изменения, которые считаются значимыми, могут быть:

• Особенности, которые нуждаются в реализации в рамках пробега и языков.
• Изменения процесса, которые влияют на то, как реализуется продукт GRPC.
• Нарушение изменений в общественном API (то есть Semver Courge Change).

Процесс

1. Разветвляется репо и скопируйте шаблон 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. В течение как минимум периода в 10 рабочих дней (минимальный период комментариев) ожидается, что владелец ответит на комментарии и сделает обновления в RFC в качестве новых коммитов в PR. Благодаря процессу обсуждение должно быть приведено в указанном потоке в списке рассылки, чтобы избежать разбивания разговоров. Владельцу рекомендуется запрашивать как можно больше отзывов о предложении в течение этого периода. Комментарии PR должны быть ограничены форматированием и словарным запасом.
7. Если существует консенсус, который считается утверждением в течение периода комментариев, утверждающий пометит это предложение окончательным и назначит ему номер GRFC. Как только это будет назначено (как часть закрытия обсуждения), владелец обновит состояние PR как окончательное и отправит PR. Коммуты не должны быть раздавлены; История коммита служит журналом изменений, внесенных в предложение.

Утверждающий

• По умолчанию a11r является утверждением, если только другой утверждающий не назначен для каждого предварительного предприятия.
• Если назначенный утверждающий и владелец не может удовлетворительно решить проблему, окончательный утверждающий по -прежнему остается a11r .

Категории предложений

Предложения должны быть пронумерованы в растущем порядке.

• #An - влияет на все языки.
• #Pnn - влияет на процессы, такие как сам процесс предложения.
• #Lnnn - Языковые конкретные изменения во внешних API или поддержке платформы.
• #Gnnnn - Изменения уровня протокола.

Статус предложения

1. Каждый непревзойденный кандидат начинается в Draft штата.
2. После того, как он принят на рассмотрение и отправлено в группу, он входит в состояние In Review .
3. Как только он будет утвержден для подачи арбитра, он попадает в Final состояние. Разрешены только незначительные изменения (то, что квалифицируется как несовершеннолетний, остается для утверждающего).
4. Если предложение необходимо пересмотреть, оно может быть перенесено обратно в Draft или In Review . Это может произойти, если проблемы обнаружены во время реализации. В этот момент должен соблюдаться процесс обзора, как описано выше.
5. После того, как предложение будет Final , и если оно было реализовано языком, его можно обновить до статуса Implemented с перечисленными языками реализации. (Версии листинга не требуются.)