الصفحة الرئيسية>المتعلقة بالبرمجة>شفرة المصدر الأخرى
تنزيل

GRPC RFCS

مقدمة

يرجى قراءة قواعد حوكمة منظمة GRPC وإرشادات المساهمة قبل المتابعة.

يحتوي هذا الريبو على مقترحات التصميم الخاصة بتغييرات كبيرة في الميزات لـ GRPC والتي تحتاج إلى تصميم مقدمًا. الهدف من عملية التصميم المقدمة هو:

  • توفير زيادة الوضوح للمجتمع حول التغييرات القادمة واعتبارات التصميم من حولهم.
  • توفير القدرة على التفكير حول "مجموعات" أكبر من التغييرات التي تكون كبيرة جدًا بحيث لا يمكن تغطيتها إما في مشكلة أو في العلاقات العامة.
  • إنشاء عملية متسقة للمشاركة المنظمة من قبل المجتمع حول تغييرات كبيرة ، وخاصة تلك التي تؤثر على أوقات التشغيل المتعددة والتطبيقات.

المتطلبات الأساسية

يجب اتباع هذه العملية لأي تغيير كبير في GRPC يحتاج إلى التصميم. يمكن أن تكون التغييرات التي تعتبر مهمة:

  • الميزات التي تحتاج إلى تنفيذ عبر أوقات التشغيل واللغات.
  • التغييرات التي تؤثر على كيفية تنفيذ منتج GRPC.
  • كسر التغييرات على واجهة برمجة التطبيقات العامة (أي التغييرات الرئيسية 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 وتحديث العلاقات العامة باستخدام رابط المناقشة. بعد الانتهاء من ذلك ، يجب على المالك تحديث GRFC إلى الحالة In Review . من المتوقع أن يساعد الموافقة المالك على طول هذه العملية حسب الحاجة.
  6. على الأقل لمدة 10 أيام عمل (الحد الأدنى من فترة التعليق) ، من المتوقع أن يستجيب المالك للتعليقات وإجراء تحديثات إلى RFC كما يرتكب العلاقات العامة الجديدة. من خلال هذه العملية ، يجب إبقاء المناقشة في الخيط المعين في القائمة البريدية لتجنب التقسيم. يتم تشجيع المالك على التماس أكبر قدر ممكن من التعليقات على الاقتراح خلال هذه الفترة. يجب أن تقتصر تعليقات العلاقات العامة على التنسيق والمفردات.
  7. إذا كان هناك إجماع كما يعتبره الموافق خلال فترة التعليق ، فسيحدد الموافق الاقتراح على أنه نهائي ويعينه رقم GRFC. بمجرد تعيين ذلك (كجزء من إغلاق المناقشة) ، سيقوم المالك بتحديث حالة العلاقات العامة على أنها نهائية وتقديم العلاقات العامة. يجب ألا يتم سحق الالتزامات ؛ تاريخ الالتزام بمثابة سجل للتغييرات التي تم إجراؤها على الاقتراح.

الموافقة

  • افتراضيًا a11r هو الموافقة ما لم يتم تعيين موافق آخر على أساس كل ما في كل شيء.
  • إذا كان الموافق المخصص ولم يتمكن المالك من تسوية قضية ما ، فإن الموافق النهائي لا يزال a11r .

فئات الاقتراح

يجب ترقيم المقترحات بترتيب متزايد.

  • #An - يؤثر على جميع اللغات.
  • #Pnn - يؤثر على العمليات ، مثل عملية الاقتراح نفسها.
  • #Lnnn - التغييرات الخاصة باللغة في واجهات برمجة التطبيقات الخارجية أو دعم النظام الأساسي.
  • #Gnnnn - تغيير مستوى البروتوكول.

حالة الاقتراح

  1. كل مرشح اقتراح غير ملتزم يبدأ في Draft الدولة.
  2. بعد قبولها للمراجعة ونشرها على المجموعة ، فإنها تدخل In Review .
  3. بمجرد الموافقة عليها لتقديمها من قبل الحكم ، فإنه يذهب إلى الحالة Final . لا يُسمح إلا بتغييرات طفيفة (ما المؤهل كركان صغير يترك للموافقة).
  4. إذا احتاجت إلى إعادة النظر في الاقتراح ، فيمكن العودة إلى Draft أو In Review . يمكن أن يحدث هذا إذا تم اكتشاف المشكلات أثناء التنفيذ. عند هذه النقطة ، يجب اتباع عملية المراجعة كما هو موضح أعلاه.
  5. بمجرد أن يكون الاقتراح Final وإذا تم تنفيذه بواسطة لغة ما ، فيمكن تحديثه إلى حالة Implemented مع اللغات المنفذة المدرجة. (الإصدارات غير مطلوبة.)
يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل