في Mozilla، موافقة مالك الوحدة ليست صلاحية commit ولا وعداً بإصدار Firefox

الخلاصة

• تميز سياسات Mozilla بين موافقة مالك الوحدة أو peer، ومستوى وصول الفرد إلى المستودع، وهبوط التغيير، وإدارة Release Drivers للمعالم والأشجار.
• ينبغي أن يحفظ سجل المراجعة إلى الإصدار الوحدة والتغيير ودور المراجع وأساس الوصول عند الحاجة والمراجعة المدمجة والفرع وقرار الإصدار والمنتج العام، بدلاً من تحويل OK واحدة إلى وعد بأن Firefox سيشحن التغيير.

أربع وقائع خلف كلمة «موافق»

قد تكون عبارة «Mozilla وافقت عليه» صحيحة، لكنها لا تكفي لاتخاذ قرار تشغيل أو توزيع. هل المقصود مراجعة patch داخل وحدة؟ أم منح شخص حقاً في مستودع؟ أم دمج مراجعة في فرع تطوير؟ أم اختيار إصلاح لمعْلم؟ أم وجود منتج Firefox متاح للمستخدمين؟ لكل سؤال صاحب مسؤولية وسجل وأثر مختلف.

تقول سياسة ملكية الوحدات إن مالك الوحدة هو الشخص الذي فُوّضت إليه قيادة عملها. وفي وحدة برمجية يلزم OK من المالك لكي يدخل الكود إليها. ويمكن للمالك تعيين peers يوافقون أيضاً على الكود، لكنه لا يراجع كوده هو بل يفوض تقييمه إلى peer. وله أن يطلب تعديلات أو يرفض patch أو يؤجل المراجعة، على أن يبين السبب في bug ذي الصلة. وعند تعذر حل الخلاف توجد طريق تدخل ضمن Module Ownership.

هذه سلطة حكم تقني محددة النطاق. ليست بطاقة دخول عامة إلى المستودعات، ولا اختياراً لما يظهر في إصدار Firefox. كما تفرق Mozilla بين مالك الوحدة ومالك مكوّن Bugzilla: أحدهما يوجه الكود ويراجعه، والآخر هو المتلقي الافتراضي للتقارير. قد يجتمع الوصفان في شخص، لكن اجتماع الأشخاص لا يلغي اختلاف الوظائف.

صلاحية commit قرار ثقة في فرد

تجيب Commit Access Policy عن سؤال آخر: أي أذونات يحتاجها الشخص للـcommit في المستودعات المختلفة؟ تحدد السياسة مستويات وصول متدرجة ومتطلبات كفالة مختلفة. وللوصول إلى المنتج الأساسي تطلب الكفالات المنصوص عليها من ملاك الوحدات أو peers المعنيين، أو من Tree Sheriffs. ومع ذلك تنص السياسة على أن الضوابط الاجتماعية قد تمنع شخصاً من check-in إلى أشجار بعينها.

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

قد يشارك مالك وحدة في كفالة طلب وصول. لكنه لا يحول كل مراجعة إيجابية إلى حق آلي، ولا يجعل كل من يملك صلاحية مراجعاً مناسباً لكل تغيير يستطيع بلوغه تقنياً. يجب أن يبقى مسار المراجعة وأساس صلاحية الفرد سجلين منفصلين في أي وصف عام أمين.

الهبوط ليس وعداً بالإتاحة العامة

يربط الهبوط التغيير بمراجعة ومستودع وفرع محدد. وهذه معلومة مهمة، لكنها لا تثبت أن المستخدم سيحصل عليه. يصف دليل شحن Firefox فروع firefox-main وfirefox-beta وfirefox-release وقنوات Nightly وBeta وRelease. والانتقال بينها له إيقاع وشروط خاصة؛ إذ ينبغي أن يهبط الكود في main قبل أن يمكن uplift إلى beta.

ولـRelease Drivers وظيفة أخرى: إدارة مشروع إصدارات المعالم، وتوجيه المطورين إلى الإصلاحات المهمة لإصدار معين، واتخاذ قرارات إدارة الأشجار. قد تفتح مراجعة الوحدة الباب إلى التسليم التالي، لكنها لا تختار وحدها محتوى قناة عامة. وبالمثل، لا تعيد أولوية الإصدار كتابة الحكم التقني للوحدة. أما dot release فيرتبط بدافع مهم بما يكفي، وليس نتيجة تلقائية لموافقة سابقة.

جعل عمليات التسليم قابلة للفحص

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

ويجب أن يعلن السجل حدوده أيضاً: لا يسمي مراجعةً تصريحَ وصول، ولا تصريحاً مراجعةً، ولا مراجعةً برمجية إصداراً. هذه ليست محاولة لفرض إجراء جديد على Mozilla؛ بل هي انضباط تحريري يجعل الحدود الموجودة في سياساتها مرئية، ويبين للقارئ ما ثبت وما القرار التالي المطلوب للانتقال من patch إلى منتج.

Sources

1. Mozilla Modules and Module Owners
2. Mozilla Commit Access Policy
3. Becoming A Mozilla Committer
4. Mozilla Roles and Leadership
5. Pocket Guide: Shipping Firefox
6. Lu Heng, The Multi-Stakeholder Mirage
7. Lu Heng, Running-Code Primacy