الخلاصة
- يميز مسار PEP في Python بين النقاش العلني، وقرار Steering Council أو PEP-Delegate معتمد، والتنفيذ المرجعي، ودمجه في مستودع المصدر الرئيس، وضوابط مراحل الإصدار.
- ينبغي لإيصال من القرار إلى الإصدار أن يبقي PEP وصاحب القرار والقرار والمراجعة والفرع والمرحلة والقطعة المنشورة أدلة منفصلة، فلا يجعل كلمة Accepted مرادفًا للتسليم.
ما الذي تثبته عبارة «قبلت Python التغيير»؟
قد تعني العبارة أن وثيقة PEP صارت موجودة، أو أن نقاشًا عامًا جرى، أو أن مجلسًا اتخذ قرارًا، أو أن شخصًا مفوضًا فصل في PEP معين، أو أن تنفيذًا دخل CPython، أو أن نسخة نهائية نُشرت. ترابط هذه الوقائع لا يجعل أي واحدة منها بديلًا عن الأخرى. ومن يقرر نشر حزمة أو دعم نظام يحتاج إلى معرفة الحلقة التي ثبتت، لا إلى عنوان مختصر فقط.
تصف PEP 1 الـ PEP بوصفها وثيقة تصميم تجمع المقترح والرأي المجتمعي وأسباب الاختيار والاعتراض. على المؤلف أن يبني توافقًا وأن يوثق الاعتراضات. هذه مهمة معرفية مهمة، لكنها لا تجعل عدد المشاركين سلطة قرار، ولا تجعل وجود الوثيقة دليلًا على وجود إصدار قابل للاستخدام.
لذلك يجب البدء بالفعل: المراجعة التحريرية تتناول صياغة الوثيقة ولا تقبل مضمونها؛ النقاش يختبر التصميم ولا يقطع إصدارًا؛ القرار يحسم مصير المقترح ولا يثبت اكتمال الكود؛ والمراجعة في المستودع تصل التنفيذ بسجل محدد لكنها لا تنتج بذاتها أرشيفًا نهائيًا. انتقال السلطة أو الدليل من مرحلة إلى أخرى يحتاج إلى سجل صريح.
التفويض قرار محدد لا لقب شامل
تحتفظ Steering Council المنتخبة بالسلطة النهائية لقبول PEPs. ويجوز لمطور أساسي أن يعرض أن يكون PEP-Delegate لمقترح محدد؛ فإذا وافق Council صار له أن يقبل ذلك الـ PEP أو يرفضه. ويمكن لمن لديه قلق بشأن ملاءمة المفوض أن يعرضه على Council.
هذه صيغة تفويض مقيدة. فهي تضع الحكم قرب الخبرة الفنية، لكنها تبقي مسار الاعتماد والمساءلة والاستئناف ظاهرًا. ولا يمتد نطاقها تلقائيًا إلى كل تصميم في اللغة أو كل مستودع أو كل تاريخ إصدار. ويصف PEP 13 Council بأنه ذو سلطة واسعة، يسعى إلى التوافق قبل الفعل الرسمي، ويمكنه تفويض بعض سلطاته ويكون محكمة الاستئناف النهائية عند فشل الطرق الأخرى. اتساع الإطار لا يبرر استخدامه ختمًا لكل commit أو وعدًا زمنيًا.
السجل الجيد يذكر PEP المقصود، والحالة، وصلة القرار، ودور صاحب القرار، والتفويض إن وجد. المشاركة تمنح خبرة وإنذارًا واعتراضًا؛ لا تمنح وحدها حق إلزام فرع أو إعلان أن قطعة برمجية أصبحت جاهزة للإصدار.
Accepted وFinal وreleased ليست حالة واحدة
تنص PEP 1 على أن التنفيذ المرجعي يجب أن يكتمل ويُدمج في مستودع المصدر الرئيس قبل أن ينتقل PEP المقبول إلى Final. لذلك لا تثبت Accepted اكتمال التنفيذ. وتربط Final قرارًا سابقًا بتنفيذ مرجعي مكتمل، وليست مجرد نبرة أقوى لنفس الوصف.
كما أن PEP المقبول مؤقتًا يمكن أن يُرفض أو يُسحب حتى بعد ظهور تغييرات مرتبطة به في إصدار Python. لا تضمن الحالة الاستقرار الدائم أو التوافق لدى جميع المستخدمين أو غياب إعادة التصميم. يجب ألا تحمل الكلمة أكثر مما تمنحه القاعدة التي عرّفتها.
ويضيف دليل التطوير طبقة مختلفة من الضبط. تتقدم الميزات في فرع التطوير؛ وعند beta ينشأ فرع صيانة كي يستقر المسار الحالي بينما يواصل المسار التالي عمله في main. في مرحلة release candidate لا تقبل إلا إصلاحات أخطاء مراجعَة وذات أثر كافٍ. وعند قطع إصدار نهائي، لا يغير الفرع إلا release manager. هذه حراسة لسطح الاستقرار، وليست نقلًا لسلطة قرار PEP إلى مدير الإصدار ولا تصريحًا للقرار بتجاوز قواعد الاستقرار.
إيصال يصل المراحل من دون دمجها
جزء القرار ينبغي أن يحفظ رقم PEP وإصداره، والنقاش المرجعي، وصاحب القرار، والتفويض إن وجد، وصلة القرار والحالة. ويجب أن يصرح بما لم يحسم: نسخة الهدف أو backports أو اكتمال التنفيذ أو الموعد، حيث لا تكون مقررة. ويضيف جزء التنفيذ المراجعة المرجعية والمستودع والفرع والاختبارات العلنية. ويضيف جزء الإصدار الفرع والمرحلة ومعرف القطعة وفعل release manager والنسخة المنشورة.
ليست هذه دعوة إلى طقوس إدارية جديدة في Python. إنها قاعدة تحريرية تمنع ثلاثة قفزات: تحويل المشاركة إلى تفويض، والتفويض إلى كود مكتمل، والكود المدمج إلى حقيقة تشغيلية منشورة.
المصادر
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات