دليل أدوات صيانة Bazel

هذا دليل لصيانة مشرفي مشروع Bazel مفتوح المصدر.

وإذا كنت تريد المساهمة في Bazel، يُرجى قراءة المساهمة في Bazel بدلاً من ذلك.

تهدف هذه الصفحة إلى ما يلي:

  1. العمل بمثابة عامل صيانة&#39؛ كمصدر صحيح لعملية المساهمة في المشروع.
  2. حدد التوقعات بين المساهمين في المنتدى ومسؤولي المشروع.

وقد خصصت مجموعة أساسية من المساهمين في Bazel فِرقًا فرعية لإدارة جوانب المشروع مفتوح المصدر. وهي:

  • عملية الإصدار: إدارة عملية إصدار Bazel&#39.
  • الفريق الأخضر: لتطوير منظومة متكاملة سليمة من القواعد والأدوات.
  • مطوّرو برامج مطوّري البرامج: يمكنك تشجيع المساهمات الخارجية ومراجعة المشاكل وسحب الطلبات وزيادة سير عمل التطوير.

الإصدارات

تكامل مستمر

يمكنك قراءة دليل الفريق الأخضر حول بنية CI التابعة لـ Bazel' في مستودع bazelbuild/continuous-integration.

مراحل نشاط المشكلة

  1. يُنشئ مستخدم مشكلة باستخدام نموذج المشكلة ويُدخِل مجموعة المشاكل المفتوحة التي لم تتم مراجعتها.
  2. يراجع أحد أعضاء فريق تناوب تجارب مطوّري البرامج (DevEx) المشكلة.
    1. إذا لم تكن المشكلة خطأ أو طلب ميزة، سيغلق عادةً عضو DevEx المشكلة ويعيد توجيه المستخدم إلى StackOverflow و bazel-مناقشة للوصول إلى مستوى ظهور أعلى في السؤال.
    2. وإذا كانت المشكلة تنتمي إلى أحد مستودعات القواعد التي يملكها المنتدى، مثل rules_apple، سيتمكّن عضو DevEx من نقل هذه المشكلة إلى المستودع الصحيح.
    3. وإذا كانت المشكلة غامضة أو لا تتوفّر فيها معلومات، سيعيد عضو DevEx المشكلة إلى المستخدم لطلب المزيد من المعلومات قبل الاستمرار. ويحدث هذا عادةً عندما لا يتّبع المستخدم نموذج المشكلة.
  3. بعد مراجعة المشكلة، يقرّر عضو DevEx ما إذا كانت المشكلة تستدعي الاهتمام الفوري. وفي هذه الحالة، سيتم تعيين التصنيف P0 الأولوية ومالك من قائمة العملاء المحتملين للفريق.
  4. يخصّص عضو DevEx تصنيف untriaged وتصنيف فريق واحدًا لتوجيهه.
  5. ويخصّص عضو DevEx أيضًا تصنيف type: واحدًا بالضبط، مثل type: bug أو type: feature request، وفقًا لنوع المشكلة.
  6. بالنسبة إلى المشاكل الخاصة بالمنصّات، يحدّد عضو DevEx تصنيف platform: واحدًا، مثل platform:apple للمشاكل المتعلقة بنظام Mac. في هذه المرحلة، تدخل المشكلة في مجموعة المشاكل المفتوحة غير السابقة.

سيعمل كل فريق فرعي في Bazel على فرز جميع المشاكل ضمن التصنيفات التي يمتلكونها، ويفضَّل أن يكون ذلك على أساس أسبوعي. سيراجع الفريق الفرعي المشكلة ويقيّمها ويقدم حلاً لها إن أمكن. إذا كنت مالكًا لتصنيف فريق، راجِع هذا القسم للحصول على مزيد من المعلومات.

وعندما يتم حلّ مشكلة، يمكن إغلاقها.

مراحل النشاط لطلب السحب

  1. يُنشئ مستخدم طلب سحب.
  2. وإذا كنت عضوًا في فريق Bazel وتُرسل العلاقات العامة في منطقتك، فأنت مسؤول عن تعيين تصنيف فريقك والعثور على أفضل مراجع.
  3. وبخلاف ذلك، خلال الفرز اليومي، يُخصِّص أحد أعضاء DevEx تصنيف فريق واحدًا والعميل الفني للفريق (TL) للتوجيه.
    1. قد يُسند بشكل اختياري موظف آخر إلى "مستخدم الدعم" لمراجعة العلاقات العامة.
  4. يراجع المراجعون المعيّنون العلاقات العامة ويعمل مع المؤلف إلى أن تتم الموافقة عليه أو إسقاطه.
  5. في حال الموافقة، يستورد المُراجع عمليات التقيُّد بالشروط والعلاقات، إلى نظام Google الداخلي لاختبار الإصدارات لمزيد من الاختبارات. نظرًا لأن Bazel هو نظام الإصدار نفسه المُستخدَم داخليًا في Google، نحتاج إلى اختبار جميع التزامات " العلاقات العامة" مع مجموعة الاختبارات الداخلية. ولهذا السبب، لا ندمج العلاقات العامة مباشرةً.
  6. إذا اجتاز الاختبار المستورَد جميع الاختبارات الداخلية، سيتم ضغطه وتصديره إلى GitHub.
  7. عندما يتم دمج الالتزام في الحساب الرئيسي، يغلق GitHub العلاقات العامة تلقائيًا.

فريقي يملك تصنيفًا. ماذا يجب أن أفعل؟

تحتاج الفرق الفرعية إلى فرز جميع المشاكل في التصنيفات التي تمتلكها، ويُفضّل أن تكون على أساس أسبوعي.

الإصدارات

  1. يمكنك فلترة قائمة المشاكل حسب تصنيف فريقك والتصنيف untriaged.
  2. راجِع المشكلة.
  3. تحديد مستوى الأولوية وتحديد التصنيف.
    1. قد تكون هذه الأولوية حسب الأولوية لدى فريق DevEx الفرعي إذا كانت P0. أعِد ترتيب الأولويات إذا لزم الأمر.
    2. ويجب أن يكون لكل مشكلة تصنيف أولوية واحد فقط. وإذا كانت المشكلة هي P0 أو P1، نفترض أنّه تم العمل عليها بشكل نشط.
  4. إزالة التصنيف untriaged

تجدر الإشارة إلى أنه يجب أن تكون في مؤسسة Babelbuild لتتمكّن من إضافة تصنيفات أو إزالتها.

طلبات السحب

  1. فلترة قائمة طلبات السحب حسب تصنيف فريقك
  2. راجِع طلبات السحب المفتوحة.
    1. اختياري: إذا تم تعيين المراجعة للمراجعة ولكنّها غير مناسبة لها، يمكنك إعادة تخصيص المراجع المناسب لإجراء مراجعة للرمز.
  3. تعاون مع منشئ طلب السحب لإكمال مراجعة الرمز.
  4. الموافقة على طلب العلاقات العامة
  5. تأكد من اجتياز جميع الاختبارات.
  6. يمكنك استيراد التصحيحات إلى نظام التحكم في الإصدارات الداخلية وتشغيل عمليات الإرسال المسبقة.
  7. أرسِل رمز التصحيح الداخلي. إذا تم إرسال التصحيحات وتم تصديرها بنجاح، سيتم إغلاق العلاقات العامة تلقائيًا من خلال GitHub.

درجة الأهمية

سيتم استخدام التعريفات التالية للأولوية من قِبل مسؤولي الصيانة لفرز المشاكل.

  • P0 - الوظائف الرئيسية المعطلة التي تتسبب في عدم قابلية استخدام إصدار البازل (باستثناء الإصدارات المرشحة) أو الخدمة التي تؤثر سلبًا على تطوير مشروع Bazel. ويشمل ذلك التراجع الذي تم طرحه في إصدار جديد يحظر عددًا كبيرًا من المستخدمين أو تغييرًا غير متوافق في الشبكة الإعلانية لم يكن متوافقًا مع سياسة التغيير. ليس هناك حل عملي.
  • P1 - عيب أو ميزة فادحة يجب معالجتها في الإصدار التالي، أو مشكلة خطيرة تؤثر في العديد من المستخدمين (بما في ذلك تطوير مشروع Bazel)، ولكن هناك حل عملي عملي. وعادةً لا تتطلب هذه الخطوة اتخاذ إجراء فوري. في ظل ارتفاع الطلب المخطّط له في خارطة الطريق الحالية
  • P2 - عيب أو ميزة يجب معالجتها، ولكننا لا نعمل حاليًا على معالجتها. مشكلة مباشرة معتدلة في إصدار تم إصداره من Bazel وغير ملائم للمستخدم الذي يلزم حلّه في إصدار مستقبلي و/أو حل بديل بسهولة.
  • P3 - يُفضَّل إصلاح خطأ طفيف أو إجراء تحسينات ذات تأثير طفيف. ولا يتم إعطاء الأولوية لخرائط Bazel على الطريق أو أي إصدار وشيك، ومع ذلك، يتم تشجيع مساهمات المنتدى.
  • P4 - عيّن ذو أولوية منخفضة أو طلب ميزة ليس من المرجح إغلاقه. ويمكن الإبقاء عليها مفتوحة لمنح الأولوية المحتملة في حالة تأثر عدد أكبر من المستخدمين.
  • ice-box
    • المشاكل التي لا نمتلك حاليًا وقتًا للتعامل معها أو لا وقت مناسب لقبول المساهمات. سنغلق هذه المشاكل للإشارة إلى أنّه ليس هناك أي شخص يعمل على حلّها، ولكنّنا سنواصل مراقبة صلاحيتها مع مرور الوقت وإعادة استعادتها في حال تأثُّر عدد كافٍ من المستخدمين وفي حال توفّر مراجع للتعامل معها. وكالعادة، يمكنك التعليق على هذه المشاكل أو إضافتها حتى ولو كانت مغلقة.

تصنيفات الفريق

  • team-Android: مشاكل فريق Android
  • team-Bazel: مشاكل استراتيجية/منتج عامة في Bazel
  • team-Build-Language: مشاكل في واجهات برمجة التطبيقات BUILD و.bzl وStardoc.
  • team-Configurability: مشاكل فريق قابلية الضبط
  • team-Core: مشاكل الفريق الأساسي
  • team-Documentation: مشاكل فريق الوثائق
  • team-ExternalDeps: التعامل مع تبعية خارجية وBzlmod والمستودعات عن بُعد وملف WORKSPACE
  • team-Local-Exec: مشاكل في التنفيذ (المحلي)
  • team-OSS: مشاكل في فريق Bazel OSS: التثبيت وعملية الإصدار وحزمة Bazel والموقع الإلكتروني والبنية الأساسية للمستندات
  • team-Performance: مشاكل في فريق Bazel Performance
  • team-Remote-Exec: مشاكل في التنفيذ (عن بُعد)
  • team-Rules-CPP: مشاكل في قواعد ++C، بما في ذلك منطق القواعد الأصلي في Apple
  • team-Rules-Java: مشاكل في قواعد Java
    • جهة الاتصال: comius
  • team-Rules-Python: مشاكل في قواعد Python الأصلية
    • جهة الاتصال: comius
  • team-Rules-Server: مشاكل في القواعد من جهة الخادم المضمّنة في Bazel
    • جهة الاتصال: comius
  • team-Starlark-integration: دمج واجهة برمجة تطبيقات Bazel + Starlark يشمل: كيفية تشغيل Bazel للمترجم الفوري في Starlark وStardoc وإدخالات مضمنة وترميز الأحرف. لا يتضمن: مشاكل لغة BUILD أو .bzl.
  • team-Starlark-interpreter: مشاكل في الترجمة الفورية لـ Starlark (أي شيء في java.net.starlark). يتم حل مشاكل واجهة برمجة التطبيقات BUILD و .bzl (التي تمثّل دمج Bazel&#39 مع Starlark) في team-Build-Language.

بالنسبة إلى المشاكل الجديدة، تم إيقاف تصنيفات category: * لصالح تصنيفات الفريق.

اطّلع على القائمة الكاملة للتصنيفات هنا.