diss
1.0.0
بعد نشر Project to [email protected] ، لفت انتباهي إلى أن أولئك الموجودين في مجتمع Foss قد يكون لديهم مخاوف بشأن استخدام نظام devleopment الخاص مثل Github.
سأترك هذا كما هو لأغراض إرثية كأرشيف لجهودنا الأسبوع الأول.
ستكون التحديثات المستقبلية على مشروع New Project Home على Gitlab والمشروع الجديد Wiki على Gitlab.
أشكركم جميعًا على اهتمامك بهذا المشروع وترحب بكم لمتابعتنا على Gitlab. سأعمل على تحديث BOT IRC في قناة التطوير لدعم إشعارات WebHook للنظام الجديد. لن أقوم بتحديث صفحة المشروع هذه.
المشروع بهدف طموح لدمج موارد دعم دبيان بشكل تآزري وتوفير واجهة بسيطة وبديهية لإجراءات تشخيصية تم اختبارها جيدًا.
هذا لا يعني بأي حال من الأحوال استبدال ، وفي الواقع يعتمد على جميع مواردنا الحالية. الأساس المنطقي هنا هو أن نظامنا ينمو بشكل كبير ونحن "نظام التشغيل الشامل" ، وأن لدينا موارد دعم محدودة وليس الجميع يعرف كيف وبسبب استخدامها كلها بشكل صحيح مما يؤدي إلى العديد من المشكلات المعروفة التي يمكن ملاحظتها بسهولة.
الدعم لفريق الإرهاق من خلال التعامل بشكل متكرر ، والمشكلات المعروفة التي حلناها بالفعل ، واضطررت إلى شرح إجراءاتنا وسياساتنا ، وجمع المعلومات (في بعض الأحيان) ذات الصلة بالمسألة في متناول اليد ، إلخ.
غزل المستخدم من خلال عدم فهم الأنظمة ، والتفاعل غير المنتج مع المؤيدين وما شابه. لقد كانت عقلية موثقة جيدًا بين بعض أفضل مؤيدينا ، حيث شملت نفسي أننا لا نريد حقًا تلك الأنواع من المستخدمين الذين يفتقرون إلى الخبرة لأنهم سيصبحون مجرد قرعة على مواردنا دون المساهمة في مشروعنا. إنها أيضًا حقيقة يمكن ملاحظتها بسهولة مفادها أن المطورين والمستخدمين الأكثر خبرة غالبًا ما يكونون آخر الأشخاص الذين عثروا على الأخطاء والمشكلات لأنهم لا يميلون إلى أن يكونوا أقل مغامرة فقط في تجربة البرامج المختلفة لأنهم يعرفون بالفعل ما يحبون ويستخدمون ، ويستخدمونه بالطريقة التي كان يقصد بها استخدامها. يتطلب الأمر شخصًا عديمي الخبرة لتجربة جميع أنواع الخيارات واستخدام الأشياء بطرق من شأنها أن تكشف عن أخطاء غامضة. هذه سلعة قيمة للحصول على جماهير من المستخدمين الذين يفتقرون إلى الخبرة الذين يتجولون في قاعدة البرمجيات المتنامية باستمرار ، واكتشاف المشكلات التي قد نفتقدها. ومع ذلك ، نحتاج إلى التأكد من أن التعليقات التي نحصل عليها من هذا المورد القيمة ذات معنى وينتهي بها الأمر في المكان المناسب دون حدوث القضية المذكورة أعلاه ، وبالتالي نحتاج إلى مرشح من الأنواع التي تلبي احتياجاتهم وكذلك لاحتياجاتنا.
نحتاج أيضًا إلى التأكد من استخدام كل الجهد نحو هاتين المسألتين. هذا هو أننا لا نستطيع أن نستمر في قدوم المستخدمين إلينا مع المصلحة الذاتية لحل مشكلة ما ، وهذا الجهد غير مستغلب لأنه لم يتم توثيقه بشكل صحيح. يعود بعض المستخدمين ويشاركون حلولًا للمشاكل ، وأحيانًا ننتهي في إنشاء حقيقة واقعة حول هذا الموضوع ، وأحيانًا ينتهي الأمر بكونها صفحة ويكي ، أو تقرير الأخطاء ، وما إلى ذلك. ولكن في معظم الوقت هذا ليس هو الحال. علاوة على ذلك ، لا نعرف دائمًا أن هذا قد تم ذلك عندما تظهر المشكلة مرة أخرى. يعتمد نظامنا الحالي على مؤيدينا لتذكر هذه الأشياء ، وعندما لا يبحث هؤلاء الأشخاص الذين يتذكرونها في ذلك الوقت ، يمكننا أن ننتهي من العودة إلى الإصدار رقم 2 وتنفير مستخدمينا ، أو عدم توثيق المشكلة أو حلها على الإطلاق ، حتى بشكل غير فعال.
العميل/الواجهة الأمامية (READLINE ، CURSES ، GTK ، QT) ، التشخيص (ملفات الأشجار التشخيصية الموقعة) ، BOT (IRC) ، الخادم (تعقب المشكلات)
سيكون العميل هو معالج نمط التقارير الذي سيسمح للمستخدم بتحديد برنامج (على مستويات المهارات المنخفضة ، واستخدام أسماء عامة مثل "Filemanager" واطلب من ذلك تلقائيًا اكتشاف اسم البرنامج الفعلي أو استخدام طباعة الاستيلاء حيث يمكن للمستخدم النقر على أحد المشكلات ، والاختصار ، وإدخال وصفه للمشكلات ، وينبغي أن يكون هناك فئات مختلفة من المشكلات (الشبكة ، تصطدم بأخطاء البناء ، والبناء. ارتد Tracker مع معرف المشكلة والبريد الإلكتروني إلى المستخدم من أجل الخصوصية ، مع القدرة على إلغاء الاشتراك في مزيد من CC عن طريق إرسال بريد إلكتروني مع المعرف الذي يطلب منه التوقف).
ستستخدم الطبقة الأولى بعد ذلك التشخيصات لإجراء اختبارات بسيطة وطرح مزيد من عمليات الرفع ، وجمع المعلومات وتجميع تقرير/تسجيل الدخول إلى المشكلة.
من المرجح أن يتم تحليل السجلات/تسلسلها/تعقيمها لإزالة أو استبدال البيانات الشخصية مثل IPS ، أو MAC IDS ، أو أسماء المستخدمين ، وربما حتى أسماء المسار/الأسماء واستبدالها بألعاب عامة مثل 1.2.3.4 أو 12: 34: 56: 78: 90 أو OR.
بعد ذلك ، إذا لم تتمكن المشكلة من خلال عمليات التشخيص التلقائي التي تحدد المشكلة بناءً على حلول بسيطة معروفة ، وتهوية ، واختبارها ، فإن العميل سيفعل في المستوى الثاني تمامًا كما يفعل تقرير DETROPG وتقارير الأخطاء (و/أو منشورات المنتدى/WIKI) وعرضها على المستخدمين من قواعد بيانات المعرفة الحالية التي لدينا بالفعل.
إذا بقيت المشكلة دون حل ، فستكون في الطبقة الثالثة تسهيل إعادة توجيه المشكلة إلى متتبع القضية وإعطائها رقم معرف ، ثم إعادة توجيهها إلى أدوات الدعم الخاصة بنا (قوائم IRC/البريدية) التي لدينا بالفعل ، من داخل العميل نفسه ، وإذا تم استخدام IRC ، فلا يتم تسهيل هذا الأمر من خلال القضايا التي تم إصدارها ، وإلا. لا يستلم حلًا أو يقرر المغادرة ، يمكن بعد ذلك أن تظل المشكلة مفتوحة و/أو يتم إرسالها إلى قوائم بريدية ويمكنهم المتابعة عن طريق زيارة موقع Tracker مع رقم الهوية أو عن طريق إعادة إخطارات البريد الإلكتروني على المشكلة من المتتبع.
إذا لم يتم حل المشكلة بعد ، فيمكن إعادة توجيهها إلى الطبقة الرابعة التي ستكون أشياء مثل BTS (تقديم التقرير على BTS ، حيث يتم تحديدها لتكون مشكلة في البرمجيات من قبل المؤيدين) ، أو ربما.
يمكن أن تكون ملفات الأشجار التشخيصية من نوع XML أو من هذا القبيل ، وسيحتاج إلى توقيعها والتحقق منها ، وستكون شجرة التشخيص الأساسية مثل ما يفعله تقرير Breatbug ، وسوف يجمع بعض المعلومات الأولية حول الوقت ، والتحقق من أن الإجراءات الصوتية ستعمل على ذلك ، وسوف يتم تشخيصها ، أي إصدار ، وسيتم تشخيصها ، على ما هو مُصدرت. أشياء مثل إجراء اختبار الصوت واسأل المستخدم عما إذا كانوا يسمعون الصوت ، والتحقق من الخلاط ، واطلب منهم التحقق من اتصالاتهم ، إلخ.
ستسهل ملفات الأشجار التشخيصية هذه أيضًا مزيد من المعلومات من خلال تشغيل الأوامر التي تجمع المزيد من المعلومات الخاصة بنوع المشكلة المعنية. يجب إظهار هذه الأوامر وشرحها والتحقق منها من قبل المستخدم ، وكذلك التقارير/السجلات/الإخراج يتم عرضها (اختياريًا) تحليل/تسلسل/قياسي لإزالة أي معلومات شخصية. ستحتاج هذه التشخيصات إلى توقيع وتصنيفها ، وسوف يسهل متتبع القضية القيام بذلك بنفس الطريقة التي يقوم بها أي نظام تصنيف منتدى جيد ، فقط باستخدام توقيعات GPG ، ولن يتسبب تصنيف الحل في توقيع العميل على أن زيادة الثقة في التشخيص ، ولكن أيضًا زيادة ثقة الدعاة الذين ساهموا في تلك الأجزاء من التشخيص.
كلما كان ذلك ممكنًا ، يجب استخدام جميع آليات الأمن المتاحة من أشياء مثل chroots إلى آليات الأمان القائمة على النواة لإغلاق الأشياء التي تقوم بها التشخيصات ، ويجب أن تكون بسيطة وغير متجانسة قدر الإمكان. نحن لا نتطلع إلى إنشاء أداة تشخيصية عاطفية ، فقط عدد قليل من عمليات الفحص البسيطة لمشكلات التكوين المعروفة ، واختبارات بسيطة ، وتجميع البيانات لمزيد من الدعم.
يجب ألا يكون BOT IRC مجرد قناة/وكيل للمستخدم لقنوات دعم IRC (حتى الكثير من النقاش) ربما يتحدث نيابة عن المستخدم في القناة مع معرف المستخدم أو رقم الإصدار الذي لا يسمح لنا فقط بتأكد من أن المستخدم يرتبط فقط بالأدوات التي تتمتع بمسألة القضايا ، بل أن مسار القضية يعرف ما هي الإجابات الداعمة للوثيقة المتأخرة للسياسة. يمكن القيام بذلك طرقًا مختلفة ، ويمكن كتابة برامج نصوص عميل IRC أو ميزات العميل المستخدمة لإكمال هذه المعرفات مثل Nick العادي ، أو ربما يمكن للمؤيد رسالة BOT إلى "تسجيل الدخول" إلى مشكلة حتى يتمثل التحدث إلى الروبوت إلى المستخدم إلى المستخدم الذي تم تسجيله عليه.
سيسهل BOT أيضًا الوصول إلى التقرير المترجم بالمعلومات التي تم جمعها بواسطة التشخيص وتقديمها من قبل المستخدم ، وتوضيح كل الثرثرة حول تشغيل الأوامر الشائعة للغاية واستخدام Pastebins وما شابه. علاوة على ذلك ، يمكن أن يتصرف الروبوت كواجهة عميل لفتح مشكلة جديدة في المتتبع (ربما حتى لو كان من الضروري ، فقط من قبل مؤيد معروف ومسجل) من قبل شخص في عميل IRC المستقل العادي.
باختصار ، يكون الروبوت هو الغراء الذي يربط Diss بقنوات دعم IRC ، ويجب توخي الحذر للتأكد من أن المعلومات تنتهي في القناة الصحيحة اعتمادًا على اللغة المفضلة للمستخدم ، وفرع Debian ، وربما حتى الحزمة أو القضية التي يتمتع بها ، لأن لدينا قنوات محددة لأشياء مختلفة (وبالتالي يلغي الحاجة إلى إحالة الأشخاص إلى القنوات الأخرى والتعامل مع أي شيء قد يكون لديهم أو لديهم.
سيحتوي المتتبع على بيانات تعريف فيما يتعلق بالمشكلة ، وسيقوم بإنشاء معرف مشكلة ، وتتبع أي عنوان CC الذي تم توفيره للمستخدم ، وحيث تكون التقارير (paste.debian.net على الأرجح) ، وحالة القضية ، وكذلك أي منتدى أو قائمة بريدية أو أشياء أخرى تسببها العميل أو الوافدين إلى هذه المشكلة. لا ينبغي أن يكون نوعًا من الويكي أو المنتدى الجديد في حد ذاته ، بل مجرد واجهة تربطها وتلتصق بها جميعًا مع البيانات الوصفية حول هذه القضية. يجب أن يكون لها واجهة ويب مماثلة ل BTS.
القضايا والأخطاء مختلفة. الأخطاء هي مشاكل فعلية في البرنامج ، حيث تكون المشكلات في أغلب الأحيان مجرد pebcak أو ذلك. هذا هو السبب في أنه من الضروري إنشاء متتبع جديد ، لأن هذا الشخص يعمل فقط على تتبع المشكلة على المدى القصير والتأكد من وصوله إلى مكان الراحة النهائي الصحيح. سيزود المتتبع الروبوت والعميل بالمعلومات اللازمة لصنع حقيقة في برامج المعلومات الخاصة بنا ، أو تقديم تقرير الأخطاء ، أو إصدار بريد إلكتروني إلى القوائم البريدية ، ويكون بمثابة مكان يمكن لأي طرف مهتم معرفة أي من هذه الأشياء التي حدثت وأين يمكن العثور عليها. إنه ليس بديلاً ، ولكن غلاف من أنظمتنا الحالية. إنه الغراء الذي يربط جميع مكونات Diss ، بما في ذلك كل تلك التي لدينا بالفعل.
لقد تم اقتراح عدة مرات أننا نحسن ببساطة الأنظمة الحالية ، وهذا جزء من هذا ، لكنه ليس بدلاً من ذلك. سيظل ذلك يواجه مشكلة المشكلة رقم 2 التي تنفر المستخدمين لأنهم بحاجة إلى معرفة وكيفية استخدام هذه الأشياء. سيكون هذا برنامجًا في نظام التشغيل نفسه يدمج ويسهل استخدام كل ذلك بطريقة لا تتطلب عامًا أو أكثر من سياسة التعلم والممارسة.
فيما يتعلق بتحسين الأنظمة الحالية ، سيسعى هذا المشروع ومساهميه إلى توحيد التسجيل عبر أي وجميع أنظمة دعم Debian التي تتطلب التسجيل ، والعمل مع الفرق الحالية من تلك الأنظمة لدمجها معًا بطريقة تآزرية.
علاوة على ذلك ، يمكن استخدام الأنظمة الحالية/تكييفها في قشور المطورين الحاليين الذين يعملون في مجالات أخرى ، على سبيل المثال ، يمكن أن يكون BTS و Artracer واحدًا أو متماثلًا ، وهذه القضايا "يمكن أن تكون فئة أقل من الأخطاء التي لا يتم إزعاجها من الخشب ، ويمكن أن يتم توسيع نطاق التقارير فقط لتشمل هذه الميزات الأخرى ، ويمكن أن يتم تعديلها في IRC. هذا ليس مجرد مشروع يهدف إلى إنشاء جزء جديد من البرامج ، ولكن لتكييف كل ما لدينا الآن لخدمتنا بشكل أفضل للمضي قدمًا.
نحن بحاجة إلى المبرمجين. أولئك الذين يتمتعون بمهارة مع Python لأنها تبدو مناسبة تمامًا لهذه المهام ، وسهلة الترميز وقوة ومرنة بما يكفي لتطوير الأشياء التي نحتاجها مع تبعيات أقل خارج النظام الأساسي. أولئك المهرة مع الأنظمة والخدمات القائمة على الثقة ، وتوقيعات GPG ، وما إلى ذلك. أولئك الذين مطلعون على عملية تطوير دبيان وجميع مخاوف المستخدمين والمطورين على حد سواء. أولئك الذين يمكنهم برمجة مكدسات شبكة العميل/الخادم باستخدام Sockets و HTTP وبروتوكولات البريد الإلكتروني ، وما إلى ذلك. أولئك الذين يمكنهم تطوير واجهة برمجة تطبيقات قوية لأنظمة دعم Debian للتواصل بفعالية ، والتي ستتطلب معرفة التطبيقات على الويب وخارجها.
نحتاج إلى المدخلات والتخطيط حول أنظمتنا الحالية ، والجهد من قبل الفرق الحالية والمساعدة لهم لدمج نظام اعتماد Debian Login Uniform الذي سيعمل في جميع مواقع وخدمات Debian.
نحتاج إلى أشخاص سيعملون على توثيق وتواصل مع وجود الويب لهذا المشروع ، والحفاظ على أهداف معلومات الحالة وأهداف المشروع (المشاريع) ومحددة بوضوح.
بدأ هذا المشروع للتو في ساعات الصباح الباكر من يوم الجمعة 13 أكتوبر 2017 ، حوالي الساعة 2 صباحًا في الولايات المتحدة/باستيا. اعتبارًا من كتابة هذا التقرير ، لم نكن حتى 24 ساعة ، ولدينا بالفعل نصف دزينة أو نحو ذلك من الأشخاص الذين يتسكعون في القناة ، والاستجابات في مختلف المنتديات. نحن جميعًا نتعرف على هذه المرحلة في هذه المرحلة ، ونلقينا حول الأفكار ونحاول اتخاذ قرارات أولية بعناية من شأنها أن تشكل المشروع وتصميمه.
الهدف الأول هنا هو إنشاء وجود حازم على شبكة الإنترنت مع ويكي ، وهذا سيخطط لتشريح هذا النظام المتكامل والتقدم الذي تقدمه ، حتى يتمكن الناس من فهم من أين نأتي ، إلى أين نحن ذاهبون ، ومدىنا.
الهدف الثاني هنا هو تجسيد واجهة برمجة التطبيقات التي ستحدد ميزات واتصالات هذا النظام ، وأنا لست مبرمجًا من ذوي الخبرة للغاية ، لكنني رأيت ذلك منذ عقود ، وأنه في بعض الأحيان يتعين عليك صنع شيء (أداة) لصنع شيء آخر ، وفي هذه الحالة ، أعتقد أن بدء العمل على واجهة العميل ، وخاصة واجهة واجهة المستخدم الرسومية ستتجه بطبيعته. وفي البداية بدون تعقب مشكلة ، لن تكون القضايا ثابتة ، فستكون مجرد عميل يتحدث إلى روبوت بدائي على الأرجح يعيش في قناة التنمية الخاصة بنا.
يجب التأكيد على أن هذا ليس شيئًا نريد الضغط عليه ونشره بسرعة ، نريد الحصول على بعض إطار عمل العمل ونقوم باختبار ألفا خارج القنوات العادية ، في البداية دون أي تعديل للخدمات الحالية للمساعدة في تسهيل التكامل ، لأن واجهة برمجة التطبيقات ليست موجودة بعد. بمجرد أن يكون لدينا مكونات عمل واهتمام المشرف وتلك الموجودة بالفعل داخل دائرة Devian Developer ، نريد أن نبدأ مرحلة اختبار بيتا للاستخدام فقط على أنظمة اختبار/عدم الإنتاج غير المستقرة. بمجرد أن تكون هناك ثقة في تنفيذ آليات الثقة الآمنة للتشخيصات ، يمكن تعبئة النظام فعليًا لـ SID ونأمل أن يتم نشره في إصدار مستقر مستقبلي. من المرجح أن تستخدم ملفات التشخيص نوعًا من المستودعات التي يمكن أن تسمح بتطويرها مع مرور الوقت وتنفيذها في العميل دون انتظار دورة إصدار Debian جديدة ، استنادًا إلى عملية اختبار صلبة وتوقيع/التحقق.
على المدى الطويل ، نود أن نرى Debian Installer يتمتع بتصميم مهارات أكثر قوة كخطوة أولى ، مع أكثر من مجرد وضع تثبيت عادي/خبير ، ويتم تثبيت عميل الدعم هذا تلقائيًا بشكل افتراضي على الأنظمة التي لا تختار مستويات متطورة أو خبراء. نود أن نرى جميع مؤيدينا يشاركون ليس فقط في الدعم المجاني ، ولكن التسجيل في نظام قائم على الثقة واستخدام توقيعات GPG ، بحيث يمكن أن تكون قاعدة المعرفة لدينا جودة أعلى وأكثر ثقة.
ديس ويكي
موضوع Reddit
منتديات ديبيان فقي
مؤشر ترابط قائمة البريد Debian-Project
مؤشر ترابط قائمة البريد ديبيان ديفيل
مؤشر ترابط قائمة البريد ديبيان-المستخدم
منشور ذي صلة من قائمة بريديان بورص البريدية في مارس 2017
