من مترجم: هذا النص هو ترجمة لنشر مدونة شخصية بواسطة Michael Stapelberg ، وهو مطور بارز مفتوح المصدر ( GitHub profile ) ، الذي ساهم مساهمة كبيرة في تطوير دبيان.
كان من الصعب الكتابة على هذا المنشور من وجهة نظر عاطفية ، لكنني لم أحصر نفسي في "رسالة قصيرة ، لأنني لم يكن لدي وقت". من فضلك ، قبل قراءة هذا النص ، ضع في اعتبارك أنني أكتبه بأفضل النوايا ولا تضع نفسي هدفًا لإلغاء تنشيط مساهمة أحد المطورين أو التقليل من أهميتها. بدلاً من ذلك ، أريد أن أوضح سبب تجاوز مستوى الإحباط لدي جميع القيم المقبولة.
لقد كانت دبيان جزءًا من حياتي منذ 10 سنوات.
قبل بضعة أسابيع ، في اجتماع دبيان في زيوريخ ، قابلت أصدقائي القدامى الذين لم أرهم منذ سنوات عديدة. عندما كنت أركب دراجتي بالفعل في المنزل ، بدا لي أن كل المواضيع التي نناقشها بطريقة أو بأخرى جاءت إلى ما ناقشناه معهم في المرة الأخيرة. ناقشنا مزايا systemd ، التي جذبت انتباه مجتمع المصادر المفتوحة مرة أخرى ، وتطرقت إلى موضوع العمليات في دبيان. وكانت ذروة مناقشة الديمقراطية في حد ذاتها والأخطاء النظرية والعملية المقابلة. لكن ، في الواقع ، هذا موضوع سويسري بحت.
هذه ليست مراجعة للتخفيف الماضي ، أريد فقط أن أشرح ما الذي جعلني أفكر في موقفي الحالي تجاه دبيان وما إذا كان ذلك يناسبني.
لذا ، فقد اتخذت قرارًا اضطررت إلى اتخاذه منذ فترة طويلة: أقيد مشاركتي في تطوير دبيان.
ماذا يعني هذا؟
في الأسابيع المقبلة ، سيحدث ما يلي:
- سوف أقوم بتمرير الحزم المهمة إلى الأمر الذي تمت صيانته ؛
- سأزيل نفسي من حزم Uploaders التي تحتوي على جهات صيانة أخرى ؛
- الحزم التي كنت فيها الحراسة الوحيدة ستصبح أيتاما.
سأحاول مواصلة صيانة الصفحات
manpages.debian.org وخدمة
codesearch.debian.net ، لكنني
سأقدر أي مساعدة في هذا المجال.
إذا كان لديك أي أسئلة أو أي مهام ، فاعتبر أنني في إجازة غير محددة. سأحاول المشاركة في بعض المسائل الإدارية (على سبيل المثال ، نقل التصاريح) والمهام الموجهة إلي شخصيًا ، لكن فقط إذا لم يستغرق الأمر وقتًا طويلاً.
لماذا؟
عندما انضممت إلى دبيان ، كنت لا أزال أدرس ، أي كان لدي الكثير من وقت الفراغ. الآن ، بعد خمس سنوات من العمل بدوام كامل ، تعلمت الكثير - سواء من حيث كيفية وما الذي يعمل في مشاريع تطوير البرمجيات الكبيرة ، ومن حيث فهم تفضيلاتي الشخصية في أنظمة الكمبيوتر. الآن أدرك بوضوح ما قضيته في هذا الجزء الصغير من وقت فراغي وما تركته في نهاية اليوم.
سوف يركز كل قسم من الأقسام التالية على الأشياء التي تؤذيني كمطور. وترد هذه القائمة في ترتيب عشوائي. تؤثر بعض هذه المشكلات على بعضها البعض ، على سبيل المثال - إذا تم تنفيذ تغييرات النظام بشكل أفضل ، فستكون لدينا فرصة لتسهيل معالجة الحزم بواسطة الجهاز.
عملية تغيير دبيان
على مدار الأعوام القليلة الماضية ، كان فريقي الحالي يعمل على إعادة تنظيم متنوعة في جميع أنحاء قاعدة الكود (التي تؤثر على آلاف المشاريع) ، لذلك تلقينا العديد من الدروس القيمة حول كيفية إجراء هذه التغييرات بكفاءة. يزعجني أن دبيان يعمل بكل طريقة تقريبًا في الاتجاه المعاكس تقريبًا. أقدر حقيقة اختلاف كل مشروع ، لكنني أعتقد أن العديد من النقاط المذكورة أدناه تنطبق على دبيان ككل.
في دبيان ، يتجه تطوير الحزمة في الاتجاه الصحيح باستخدام مستند يسمى سياسة دبيان ، أو إصدار البرنامج الخاص بها
، لينتيان .
على الرغم من حقيقة أن لينت مناسب جدًا للحصول على ملاحظات سريعة مباشرة أو محلية / مستقلة ، فمن الأفضل عدم طلب هذه الأداة على الإطلاق. على سبيل المثال ، يجب أن يكون الأمر C ++ ، الذي يقدم علامة أمان جديدة لجميع الحزم ، قادرًا على جعل عمله شفافًا بالنسبة لي أيضًا (
استنادًا إلى ملف تعريف GitHub ، فإن لغة Go الرئيسية هي Michael ، approx. Trans. ).
بدلاً من ذلك ، أصبحت جميع الحزم الآن "قذرة" (الأصل - لينت غير نظيفة): يجب على جميع الحاضرين قراءة ما هو هذا الشيء الجديد ، وكيف يمكن كسره ، وما إذا كان يؤثر على عملهم بشكل عام ، وإذا كان الأمر كذلك ، فكيف. ثم تحتاج إلى إجراء بعض الاختبارات يدويًا ، وأخيراً ، تجاهل التغييرات. كل هذا هو العديد من العمليات الميكانيكية اليدوية واليدوية بين الحزم.
في نموذج دبيان ، يعتمد
قرار نشر الأخبار على الحزم المصاحبة وليس للمطورين. في وظيفتي الرئيسية ، وجدنا أنه من الأفضل القيام بالعكس: إذا كان التغيير المكتوب يؤثر على جزء كبير من المستخدمين ، فعندئذ المطورين هم الذين يجب عليهم تقرير الحاجة إلى تنفيذه. هذا النهج يجعل تطوير المشروع أكثر كفاءة ويقلل من الوقت وتكاليف العمالة. بالطبع ، هناك استثناءات ، على سبيل المثال ، في المساحات الكبيرة التي يتم فيها استخدام شرائح اللغة ، والتي يجب على مسؤولي المالك المعنيين الاهتمام بها ، ولكن الشيء المهم هو أن كل شيء افتراضيًا سيكون مختلفًا عما هو عليه الآن.
تفتقر دبيان
إلى الأدوات اللازمة لإجراء تغييرات كبيرة : من الصعب برمجيًا العمل مع الحزم والمستودعات المجزأة (المزيد حول هذا في القسم أدناه). إن الحدث الأقرب إلى "إرسال التغييرات إلى المراجعة" الافتراضي هو عملية فتح تقرير بالأخطاء مع إرفاق التصحيح بها. يبدو لي أن العملية الحالية لقبول إصلاح الخلل كانت معقدة للغاية ، وبدأت العمل على دمج الروبوتات ، ولكن فقط غيدو ولا أحد أبدى اهتمامًا به (على
ما يبدو ، يتحدث المؤلف عن غيدو آجكس جونتر ، مطور ديبيان آخر ، - تقريبا .
بعبارةٍ أدبية ، يكون رد الفعل على الدفع ، وبالتالي ، تلقي ردود الفعل بطيئًا. ببساطة لا توجد مواعيد نهائية. في بعض الأحيان ، تلقيت رسائل بريد إلكتروني تفيدني بأن التصحيح الذي أرسلته قبل عدة سنوات (!!!) تم احتواؤه في النهاية. هذا يمتد المشاريع الأسبوعية لسنوات عديدة ، والتي بالنسبة لي هو demotivator قوية.
من الغريب أن نلاحظ ذلك ، ولكن ممارسة السلحفاة على الإنترنت يتم عرضها أيضًا على الثقافة غير المتصلة بالإنترنت ، ولا أريد مناقشة مزايا systemd بعد 10 سنوات من سماعي لأول مرة.
وأخيرًا ، يمكن إيقاف أي تغييرات من قِبل أولئك الذين يختلفون ، والذين يرفضون التعاون في النهاية. بلدي المثال الكنسي لهذا الموقف هو rsync. رفض المنسق تصحيحاتي ، التي تضيف دعمًا غير متقن إلى الحزمة ، فقط من معتقداتهم الخاصة.
إن منح مثل هذه الدرجة من الحرية الشخصية للمشرفين الأفراد يمنعنا جميعًا من المشاركين في المشروع من رفع مستوى التجريد من تصميم دبيان ، الأمر الذي يؤدي بدوره إلى تعقيد أدوات التطوير.
كيف سيبدو كل شيء في عالم مثالي؟
- كمشروع ، يجب أن نسعى جاهدين من أجل التوحيد. بعد كل شيء ، لا يستبعد التوحيد التجارب ؛ إنه يغير ببساطة الحل الوسط الحالي بين التجارب الأبسط والأتمتة الأكثر تعقيدًا إلى حل وسط بين تجارب أكثر تعقيدًا وأتمتة أبسط.
- يجب أن تبتعد ثقافتنا التنموية عن النموذج "هذه الحزمة هي أسرتي ، كيف تجرؤ أن تلمسها" ، وهو إحساس عام بالملكية ، حيث يمكن لأي مشارك إجراء تغييرات أو التحقق منها بسهولة ، حتى دون إشراك القيمين المعنيين الذين يرافقونهم.
لفهم كيف تبدو التغييرات الكبيرة الناجحة (تصحيحات) ، نوصيك بقراءة العرض التقديمي لزميلي حيرام رايت
"التغييرات على نطاق واسع في Google: الدروس المستفادة من عمليات الترحيل الجماعي لخمس سنوات" .
مجزأة سير العمل والبنية التحتية
تفضل دبيان عادةً النهج اللامركزية على النهج المركزية. على سبيل المثال ، يتم تخزين الحزم المنفصلة في مستودعات منفصلة ، ويمكن لكل مستودع استخدام أي SCM (عادةً git و svn) أو لا يستخدم على الإطلاق. بالإضافة إلى ذلك ، يمكن استضافة كل مستودع على أي موقع. بالطبع ، يختلف محتوى كل مستودع أيضًا اختلافًا طفيفًا من فريق لآخر ، وحتى داخل الفريق.
في الممارسة العملية ، نادراً ما يتم استخدام خيارات الاستضافة غير القياسية ، لأنها لا تبرر تكلفتها ، ولكنها في الغالب كافية لإحداث ألم كبير عند محاولة أتمتة عملية إجراء تغييرات على الحزم. لذا بدلاً من استخدام واجهة برمجة تطبيقات GitLab لإنشاء طلبات دمج ، تحتاج إلى تطوير نظام مختلف تمامًا وأكثر تعقيدًا يعمل بشكل دوري (أو باستمرار!) مستودعات لا يمكن الوصول إليها ، يلخص الاختلافات في التصحيحات المقدمة (تقارير الأخطاء ، طلبات دمج) وطلبات الاستخراج) وهكذا دواليك ...
عمليات التطوير المختلفة جذرياً ليست مجرد مضيعة للوقت. شاركت في نقاشات طويلة حول عمليات تطوير git المختلفة خلال DebConf 13 وأدركت أنه تم إجراء مناقشات مماثلة في ذلك الوقت.
شخصيا ، لا أستطيع أن أضع في الاعتبار ما يكفي من التفاصيل حول منهجيات التنمية المختلفة. في كل مرة أتطرق فيها إلى حزمة لا تعمل مثل بلدي ، أشعر بالضيق الشديد لأن عليّ إعادة النظر في جوانب عملها.
لقد لاحظت تجزؤًا مشابهًا لسير العمل في فريق التغليف Go الخاص بي وحاولت إصلاحه من خلال
تقديم اقتراحات للتغييرات في سير العمل ، لكنني لم أتمكن من تنفيذها. أدى الافتقار إلى التشغيل الآلي الفعال وانخفاض معدل التغيير في الأدوات ، على الرغم من رغبتي في قضاء وقتي وطاقتي ، إلى تحفيز أي دافع.
البنية التحتية المهملة: تنزيل الحزم
عندما تريد إتاحة حزمة في دبيان ، فأنت تقوم بتحميل الملفات الموقعة بواسطة GPG عبر FTP مجهول. هناك عدة أنواع من المهام (قائمة انتظار الخفي ، إلغاء تحديد ، إلغاء التثبيت ، وغيرها) التي تعمل على جدول زمني ثابت (على سبيل المثال ، يتم تشغيل التثبيت في 01:52 UTC ، 07:52 UTC ، 13:52 UTC ، 19:52 UTC).
حسبت أنه وفقًا للوقت من اليوم ، يمكنك الانتظار أكثر من 7 ساعات (!!!) قبل تثبيت الحزمة الخاصة بك.
ولكن الجزء الأسوأ بالنسبة لي هو أن الملاحظات غير متزامنة فيما يتعلق بالتحميل. أحب أن أفعل شيئًا ، وأنهيه والانتقال إلى المهمة التالية. يتطلب الإعداد الحالي انتظارًا طويلًا ، وفي الواقع ، تبديلًا باهظًا بين المهام دون أسباب فنية جيدة. قد تلاحظ أن بضع دقائق لا تهمك حقًا ، ولكن عندما يتم قياس كل الوقت الذي يمكنني أن أقضيه في دبيان بالدقائق ، فمن الأهمية بمكان إدراك أدائي الخاص ورضائي من العمل المنجز.
الرسالة الأخيرة التي يمكنني العثور عليها حول تسريع هذه العملية هي
مشاركة لجورج غانيف جاسبرت من عام 2008.
كيف سيبدو كل شيء في عالم مثالي؟
- سيتم استبدال FTP المجهول بخدمة الويب التي تقبل الحزمة الخاصة بي وتعود في ردها بقرار رسمي بقبولها أو رفضها.
- بالنسبة للحزم المستلمة ، هناك صفحة تعرض حالة الإنشاء والوقت الذي ستتوفر فيه الحزمة من خلال شبكة من المرايا.
- يجب أن تكون الحزم متوفرة في غضون دقائق من اكتمال التجميع.
البنية التحتية المهملة: Bug Tracker
أخشى التفاعل مع تعقب أخطاء دبيان. Debbugs هي جزء من الشفرة مباشرة منذ عام 1994 ويستخدمها حاليًا فقط دبيان ومشروع جنو.
تعتمد عمليات تصحيح الأخطاء على استخدام البريد الإلكتروني ، أي أنها غير متزامنة ومرهقة. على الرغم من أنه يعمل على أسرع الأجهزة التي لدينا في مشروع دبيان (حسنًا ، أخبروني متى تم طرح هذا الموضوع آخر مرة) ، فإن واجهة الويب الخاصة به يتم تحميلها ببطء شديد.
والجدير بالذكر أن واجهة الويب على bugs.debian.org للقراءة فقط.
يعد إعداد مساحة عمل البريد الإلكتروني لـ
reportbug (1) أو العمل يدويًا مع المرفقات تحديًا خطيرًا للغاية.
لسبب لا أفهمه ، يؤدي كل تفاعل مع debbugs إلى
الكثير من المحادثات .
إلى جانب التنفيذ الفني ، لا أتذكر أيضًا الطرق المختلفة التي تستخدم بها دبيان حزم توليد زائفة للأخطاء والعمليات. أحتاجها نادراً ما أضعها أخيرًا في رأسي وأتذكر بالضبط كيف تعمل وتستخدم ، لكنني أواجهها من حين لآخر ، لذلك هذا التنوع مزعج.
كيف سيبدو كل شيء في عالم مثالي؟
- سيتحول دبيان من طريقة غير قياسية لتتبع الأخطاء إلى (أي) استقر بالفعل.
- تقوم دبيان بأتمتة هذه العمليات. يجب أن تكون الواجهة الرئيسية أكثر ملاءمة (على سبيل المثال ، نموذج ويب).
البنية التحتية المهملة: أرشيف مراسلات البريد الإلكتروني
إنني مرتبك من حقيقة أنه في عام 2019 ، ما زلنا لا نملك أداة ملائمة لعرض سلاسل المناقشة المؤرشفة في البريد. على نطاق واسع كما هو الحال في دبيان ، لم تعد تستخدم البريد الإلكتروني والمحادثات في أي مكان ، لذلك فمن السخرية إلى حد ما. يبدو أن استخدام
Gmane لحل هذه المشكلة ، لكن توفرها على مدار السنوات القليلة الماضية كان ، بعبارة بسيطة ، فجأة (الآن ، في وقت كتابة هذا المنشور ، لا يعمل على الإطلاق).
لقد حاولت إنشاء أرشيف متعدد الخيوط ، لكن أساتذة الأوراق لم يتأثروا ورفضوا دعم المشروع.
من الصعب أن تعمل الآلات مع دبيان
على الرغم من أنه من الواضح أنه يمكنك العمل مع حزم دبيان بطريقة برمجية ، إلا أن هذه التجربة بالكاد ممتعة. كل شيء يبدو بطيئا وضخمة. لقد اخترت ثلاثة أمثلة صغيرة لتوضيح موقفي بشأن هذه المسألة.
يحتاج
debiman إلى
مساعدة من piuparts في تحليل الآلية البديلة لكل حزمة لعرض صفحات الوثائق ، على سبيل المثال ،
PSQL (1) . هذا مطلوب لأن البرامج النصية تعديل قاعدة البيانات البديلة عن طريق استدعاء البرامج النصية shell. لكن بدون تثبيت الحزمة بالفعل ، فلن تعرف التغييرات التي تجريها.
يجب أن يحافظ
pk4 على ذاكرة التخزين المؤقت الخاصة به للبحث عن بيانات تعريف الحزمة بناءً على اسمه. أدوات أخرى تحليل قاعدة البيانات من نقطة الصفر مع كل مكالمة. سيكون تنسيق قاعدة البيانات الصحيح ، أو تنسيق التبادل الثنائي على الأقل ، ذا أهمية كبيرة لهذه العملية.
يريد
Debian Code Search استلام حزم جديدة في أسرع وقت ممكن. تم
استخدام مثيل
fedmsg مسبقًا ، لكنه لم يعد موجودًا. ليس من الواضح مكان تلقي إشعارات الحزم الجديدة والأفضل أن تستلمها.
بناء مجمع المكدس
هنا يمكنك فقط قراءة مشاركتي
"Debian Package Build Tools" . ما يقلقني حقًا هو أن زيادة عدد الأدوات لا يعتبر مشكلة.
دبيان هي تجربة مؤلمة للمطور
تتعلق معظم الأسئلة التي أثارتها بتجربة تطوير دبيان ، ولكن كما وصفت مؤخرًا في
منشور Debian Debug Debugging Experience ، فإن تجربة التطوير
باستخدام دبيان تترك الكثير مما هو مرغوب فيه.
لدي المزيد من الأفكار
تبين أن المقال ضخم للغاية ، لكنني آمل أن تكونوا قد تلقيت فكرة تقريبية عن دوافعي.
على الرغم من أنني وصفت عددًا من العيوب المحددة أعلاه ، فإن الظفر الأخير في غطاء التابوت هو الافتقار إلى نظرة إيجابية للمستقبل. لديّ أفكار أخرى تبدو مقنعة حقًا لي ، لكن بناءً على التقدم الذي أحرزته مشاريعي السابقة ، لا أعتقد أنني أستطيع تنفيذ أي منها كجزء من مشروع دبيان.
أنوي نشر عدد قليل من المشاركات على طرق محددة لتحسين أنظمة التشغيل على مدونتي. حتى تسقط في.
وأخيراً ، آمل أن يكون هذا المنشور مصدر إلهام لشخص ما ، من الناحية المثالية مجموعة من الأشخاص ، لجعل حياة مطوري دبيان أفضل.