अनुवादक से: यह पाठ माइकल स्टेपेलबर्ग, एक प्रमुख ओपन सोर्स डेवलपर ( GitHub प्रोफ़ाइल ) द्वारा एक व्यक्तिगत ब्लॉग पोस्ट का अनुवाद है, जिसने डेबियन के विकास में महत्वपूर्ण योगदान दिया।
यह पोस्ट एक भावनात्मक दृष्टिकोण से लिखना मुश्किल था, लेकिन मैंने अपने आप को "एक छोटे पत्र के लिए सीमित नहीं किया, क्योंकि मेरे पास समय नहीं था।" कृपया, इस पाठ को पढ़ने से पहले, यह ध्यान रखें कि मैं इसे सबसे अच्छे इरादों के साथ लिख रहा हूं और खुद को डेवलपर्स में से किसी एक के योगदान को ध्वस्त करने या उसमें बाधा डालने का लक्ष्य निर्धारित नहीं करता। बल्कि, मैं यह समझाना चाहता हूं कि मेरी कुंठा का स्तर सभी स्वीकार्य मूल्यों से अधिक क्यों है।
डेबियन 10 साल से मेरे जीवन का हिस्सा है।
कुछ हफ्ते पहले, ज्यूरिख में एक डेबियन बैठक में, मैं अपने पुराने दोस्तों से मिला, जिन्हें मैंने कई सालों से नहीं देखा था। जब मैं पहले से ही अपनी बाइक की सवारी कर रहा था, तो यह मुझ पर हावी हो गया कि हमने जिन विषयों पर चर्चा की थी, वे उस समय हमारे साथ चर्चा में आए थे। हमने सिस्टमड के गुणों पर चर्चा की, जिसने एक बार फिर खुले स्रोत समुदाय का ध्यान आकर्षित किया, डेबियन में प्रक्रियाओं के विषय पर छुआ। परिणति लोकतंत्र की चर्चा थी जैसे कि और सैद्धांतिक और व्यावहारिक त्रुटियों के अनुसार। लेकिन, वास्तव में, यह एक विशुद्ध रूप से स्विस विषय है।
यह पिछले मिटप की समीक्षा नहीं है, मैं सिर्फ यह बताना चाहता हूं कि मुझे डेबियन के प्रति मेरे वर्तमान रवैये के बारे में क्या सोचना है और क्या यह मुझे सूट करता है।
इसलिए, मैंने एक निर्णय लिया कि मुझे बहुत पहले करना था: मैं डेबियन के विकास में अपनी भागीदारी के लिए उत्सुक हूं।
इसका क्या मतलब है?
आने वाले हफ्तों में, निम्नलिखित होगा:
- मैं बनाए रखा कमान के लिए महत्वपूर्ण संकुल पारित करेंगे;
- मैं अपने आप को अपलोडर पैकेज से हटा दूंगा जिसमें अन्य अनुरक्षक शामिल हैं;
- जिन पैकेजों में मैं एकमात्र एस्कॉर्ट था, वे अनाथ हो जाएंगे।
मैं पेज
manpages.debian.org और
codesearch.debian.net सेवा को बनाए रखना जारी रखने की कोशिश करूंगा, लेकिन मैं इस क्षेत्र में किसी भी मदद की बहुत सराहना करूंगा।
यदि आपके कोई प्रश्न या कोई कार्य हैं, तो विचार करें कि मैं अनिश्चितकालीन छुट्टी पर हूं। मैं कुछ प्रशासनिक मुद्दों (उदाहरण के लिए, परमिट के हस्तांतरण) और कार्यों को व्यक्तिगत रूप से मुझे संबोधित करने की कोशिश करूंगा, लेकिन केवल अगर इसमें ज्यादा समय नहीं लगता है।
क्यों?
जब मैं डेबियन में शामिल हो गया, तब भी मैं अध्ययन कर रहा था, अर्थात, मेरे पास बहुत खाली समय था। अब पांच साल के पूरे समय के बाद, मैंने बहुत कुछ सीखा है - दोनों बड़े सॉफ्टवेयर विकास परियोजनाओं में कैसे और क्या काम करते हैं, और कंप्यूटर सिस्टम में मेरी व्यक्तिगत प्राथमिकताओं को समझने के संदर्भ में। अब मुझे स्पष्ट रूप से पता है कि मैं अपने खाली समय के उस छोटे से हिस्से पर क्या खर्च करता हूं और दिन के अंत में मैंने क्या छोड़ा है।
निम्न में से प्रत्येक अनुभाग उन चीजों पर ध्यान केंद्रित करेगा जो मुझे एक डेवलपर के रूप में चोट पहुंचाती हैं। यह सूची यादृच्छिक क्रम में दी गई है। इनमें से कुछ समस्याएं एक-दूसरे को प्रभावित करती हैं, उदाहरण के लिए - अगर सिस्टम में बदलाव बेहतर तरीके से किए गए, तो हमारे पास एक मौका होगा कि पैकेज मशीन द्वारा संभालना आसान होगा।
डेबियन परिवर्तन प्रक्रिया
पिछले कुछ वर्षों में, मेरी वर्तमान टीम कोड आधार (हज़ारों परियोजनाओं को प्रभावित करने) के दौरान विभिन्न पुनर्गठन पर काम कर रही है, इसलिए हमें इन परिवर्तनों को कुशलतापूर्वक बनाने के लिए कई मूल्यवान सबक मिले हैं। यह मुझे गुस्सा दिलाता है कि डेबियन लगभग हर तरह से लगभग विपरीत तरीके से काम करता है। मैं इस तथ्य की सराहना करता हूं कि प्रत्येक परियोजना अलग है, लेकिन मुझे लगता है कि नीचे सूचीबद्ध कई बिंदु पूरे के रूप में डेबियन पर लागू होते हैं।
डेबियन में, पैकेज डेवलपमेंट को डेबियन पॉलिसी, या इसके सॉफ्टवेयर संस्करण
, लिंटियन नामक एक दस्तावेज़ का उपयोग करके सही दिशा में ले
जाया जाता है ।
इस तथ्य के बावजूद कि लिंट एक त्वरित प्रत्यक्ष या स्थानीय / स्वायत्त प्रतिक्रिया प्राप्त करने के लिए बहुत सुविधाजनक है, इस तरह के उपकरण की आवश्यकता नहीं है और भी बेहतर है। उदाहरण के लिए, C ++ कमांड, जो सभी पैकेजों के लिए एक नया सुरक्षा ध्वज प्रस्तुत करता है, को अपने काम को पारदर्शी बनाने में सक्षम होना चाहिए (
GitHub प्रोफ़ाइल को देखते हुए, गो की मुख्य भाषा माइकल है, लगभग। ट्रांस। )।
इसके बजाय, अब सभी पैकेजों को "गंदा" (मूल। - लिंट-अशुद्ध) किया जा रहा है: सभी उपस्थित लोगों को यह पढ़ना चाहिए कि यह नई चीज क्या है, यह कैसे टूट सकती है, क्या यह सामान्य रूप से उनके काम को प्रभावित करता है, और यदि हां, तो कैसे। फिर आपको मैन्युअल रूप से कुछ परीक्षण चलाने और अंत में, परिवर्तनों को त्यागने की आवश्यकता है। यह सब पैकेज के बीच ओवरहेड और मैनुअल मैकेनिकल ऑपरेशंस की भीड़ है।
डेबियन मॉडल में,
समाचार को रोल आउट करने का
निर्णय साथ के पैकेज के साथ रहता है, न कि डेवलपर्स के साथ। मेरी मुख्य नौकरी पर, हमने पाया कि इसके विपरीत करना अधिक कुशल है: यदि लिखित परिवर्तन उपयोगकर्ताओं के एक महत्वपूर्ण हिस्से को प्रभावित करता है, तो यह डेवलपर्स हैं जिन्हें इसके कार्यान्वयन की आवश्यकता पर निर्णय लेना चाहिए। यह दृष्टिकोण परियोजना के विकास को अधिक कुशल बनाता है और समय और श्रम लागत को कम करता है। बेशक, अपवाद हैं, उदाहरण के लिए, बड़े क्षेत्रों में जहां भाषा के चिप्स का उपयोग किया जाता है, जिसे संबंधित मालिक-क्यूरेटर द्वारा ध्यान दिया जाना चाहिए, लेकिन महत्वपूर्ण बात यह है कि डिफ़ॉल्ट रूप से सब कुछ अब की तुलना में अलग होना चाहिए।
डेबियन के पास
बड़े बदलाव करने के लिए उपकरणों का अभाव है : खंडित पैकेज और रिपॉजिटरी (इससे नीचे के अनुभाग में इस पर अधिक) के साथ काम करना प्रोग्रामेटिक रूप से कठिन है। डिफ़ॉल्ट के लिए निकटतम घटना "समीक्षा में परिवर्तन भेजना" एक बग रिपोर्ट खोलने की प्रक्रिया है, जिसके साथ एक पैच संलग्न है। मुझे ऐसा लगा कि बग फिक्स को स्वीकार करने की मौजूदा प्रक्रिया बहुत जटिल थी, और मैंने मर्ज बॉट पर काम करना शुरू कर दिया, लेकिन केवल गुइडो और किसी और ने इसमें दिलचस्पी नहीं दिखाई (
जाहिर है, लेखक गुइडो एग्क्स गुंटर , एक और डेवलेयर डेवलपर के बारे में बात करता है) - लगभग ।
इसे साहित्यिक रूप से कहने के लिए, पुश की प्रतिक्रिया और, तदनुसार, प्रतिक्रिया की प्राप्ति धीमी है। बस कोई समय सीमा नहीं हैं। कभी-कभी मुझे ऐसे ईमेल मिलते हैं जो मुझे सूचित करते हैं कि जो पैच मैंने कई साल पहले भेजा था (!!!) आखिरकार निहित था। यह कई वर्षों के लिए साप्ताहिक परियोजनाओं को बढ़ाता है, जो मेरे लिए एक शक्तिशाली लोकतंत्र है।
यह नोट करने के लिए उत्सुक है, लेकिन कछुआ ऑनलाइन गतिविधि का अभ्यास भी ऑफ़लाइन संस्कृति पर आधारित है, और मैं इसके बारे में पहली बार सुनने के 10 साल बाद सिस्टमड के फायदे पर चर्चा नहीं करना चाहता हूं।
और अंत में, किसी भी परिवर्तन से उन लोगों को रोका जा सकता है जो असहमत हैं, जो अंततः सहयोग करने से इनकार करते हैं। इस स्थिति का मेरा विहित उदाहरण rsync है। क्यूरेटर ने मेरे पैच से इनकार कर दिया, जो पैकेज के लिए डिफ्लेपर समर्थन को जोड़ते हैं, पूरी तरह से अपने स्वयं के विश्वासों से।
व्यक्तिगत रख-रखाव के लिए व्यक्तिगत स्वतंत्रता की ऐसी डिग्री प्रदान करना हम सभी परियोजना प्रतिभागियों को डेबियन बिल्ड के अमूर्त स्तर को बढ़ाने से रोकता है, जो बदले में, विकास साधनों को जटिल करता है।
एक आदर्श दुनिया में यह सब कैसा दिखेगा?
- एक परियोजना के रूप में, हमें एकीकरण के लिए प्रयास करना चाहिए। सब के बाद, एकीकरण प्रयोगों को बाहर नहीं करता है, यह बस सरल प्रयोगों और अधिक जटिल स्वचालन के बीच वर्तमान समझौता को और अधिक जटिल प्रयोगों और सरल स्वचालन के बीच एक समझौता में बदल देता है।
- हमारी विकास संस्कृति को प्रतिमान से दूर ले जाना चाहिए "यह पैकेज मेरा घर है, आप इसे कैसे छू सकते हैं", स्वामित्व का एक सामान्य अर्थ है, जिसमें कोई भी प्रतिभागी विशिष्ट क्यूरेटर को शामिल किए बिना आसानी से बदलाव कर सकता है या सत्यापित कर सकता है।
यह समझने के लिए कि बड़े परिवर्तन (पैच) कितने सफल हो सकते हैं, मैं सुझाव देता हूं कि आप मेरे सहयोगी हीराम राइट
की प्रस्तुति
"Google पर बड़े पैमाने पर परिवर्तन: पांच साल के सामूहिक पलायन से सीखे सबक" पढ़ें।
खंडित वर्कफ़्लो और बुनियादी ढाँचा
डेबियन आमतौर पर केंद्रीकृत लोगों पर विकेंद्रीकृत दृष्टिकोण पसंद करते हैं। उदाहरण के लिए, अलग-अलग पैकेज अलग-अलग रिपॉजिटरी में संग्रहीत किए जाते हैं, और प्रत्येक रिपॉजिटरी किसी भी SCM (आमतौर पर git और svn) का उपयोग कर सकती है या बिल्कुल नहीं। साथ ही, प्रत्येक रिपॉजिटरी को किसी भी साइट पर होस्ट किया जा सकता है। बेशक, प्रत्येक रिपॉजिटरी की सामग्री भी टीम से टीम में थोड़ी भिन्न होती है, और टीम के भीतर भी।
व्यवहार में, गैर-मानक होस्टिंग विकल्पों का उपयोग शायद ही कभी किया जाता है, क्योंकि वे अपनी लागत का औचित्य नहीं करते हैं, लेकिन अक्सर पैकेज में बदलाव करने की प्रक्रिया को स्वचालित करने की कोशिश करते समय बहुत दर्द होता है। इसलिए मर्ज अनुरोधों को बनाने के लिए गिटलैब एपीआई का उपयोग करने के बजाय, आपको पूरी तरह से अलग, अधिक जटिल प्रणाली विकसित करने की आवश्यकता है जो समय-समय पर (या लगातार!) दुर्गम रिपॉजिटरी के साथ काम करता है, वितरित पैच (त्रुटि रिपोर्ट, मर्ज अनुरोधों में अंतर को अमूर्त करता है) निकासी अनुरोध) और इतने पर और आगे ...
मूल रूप से विभिन्न विकास प्रक्रियाएं केवल समय की बर्बादी नहीं हैं। मैंने डेबोनफ़ 13 के दौरान विभिन्न गिट विकास प्रक्रियाओं के बारे में लंबी चर्चा में भाग लिया और मुझे एहसास हुआ कि इसी तरह की चर्चाएँ तब भी हो रही थीं।
व्यक्तिगत रूप से, मैं विभिन्न विकास विधियों के बारे में पर्याप्त विवरण को ध्यान में नहीं रख सकता। जब भी मैं किसी ऐसे पैकेज को छूता हूं, जो मेरा काम नहीं करता है, तो मैं बहुत परेशान हो जाता हूं क्योंकि मुझे इसके काम के पहलुओं की फिर से जांच करनी होती है।
मैंने अपने स्वयं के गो पैकेजिंग टीम में वर्कफ़्लो के समान विखंडन को देखा और वर्कफ़्लो में
बदलाव के लिए सुझाव देकर इसे ठीक करने की कोशिश की, लेकिन मैंने उन्हें लागू किया है। प्रभावी स्वचालन की कमी और उपकरणों में बदलाव की कम दर, मेरे अपने समय और ऊर्जा खर्च करने की इच्छा के बावजूद, किसी भी प्रेरणा को मार डाला।
पदावनत अवसंरचना: डाउनलोड संकुल
जब आप डेबियन में पैकेज उपलब्ध कराना चाहते हैं, तो आप गुमनाम एफ़टीपी के माध्यम से जीपीजी-हस्ताक्षरित फाइलें अपलोड करते हैं। कई प्रकार के कार्य हैं (कतार डेमॉन, अनियंत्रित, स्थापना रद्द करना, और अन्य) जो एक निश्चित समय पर चलते हैं (उदाहरण के लिए, इंस्टॉलेशन 01:52 UTC, 07:52 UTC, 13:52 UTC और 19:52 UTC पर चलते हैं)।
मैंने गणना की कि दिन के समय के आधार पर, आप अपने पैकेज को स्थापित करने से पहले 7 घंटे (!!!) से अधिक इंतजार कर सकते हैं।
लेकिन मेरे लिए सबसे बुरी बात यह है कि लोडिंग के संबंध में प्रतिक्रिया अतुल्यकालिक है। मुझे कुछ करना पसंद है, इसे समाप्त करें और अगले असाइनमेंट पर आगे बढ़ें। वर्तमान सेटअप के लिए लंबे इंतजार और वास्तव में, अच्छे तकनीकी कारणों के बिना कार्यों के बीच एक महंगा स्विच की आवश्यकता होती है। आप देख सकते हैं कि कुछ मिनट वास्तव में मायने नहीं रखते हैं, लेकिन जब दिन में हर समय जो मैं डेबियन पर खर्च कर सकता हूं, उसे मिनटों में मापा जाता है, तो यह मेरे स्वयं के प्रदर्शन और किए गए कार्य से संतुष्टि के लिए बहुत महत्व का है।
आखिरी संदेश जो मैं इस प्रक्रिया को तेज करने के बारे में पा सकता हूं वह 2008 से
जॉर्ज गनेफ जैस्पर द्वारा पोस्ट किया गया है ।
एक आदर्श दुनिया में यह सब कैसा दिखेगा?
- बेनामी एफ़टीपी एक वेब सेवा द्वारा प्रतिस्थापित किया जाएगा जो मेरे पैकेज को स्वीकार करता है और इसकी प्रतिक्रिया में इसे स्वीकार करने या अस्वीकार करने के लिए एक आधिकारिक निर्णय है।
- प्राप्त पैकेजों के लिए, बिल्ड स्टेटस प्रदर्शित करने वाला एक पेज होता है और वह समय जब पैकेज दर्पण के नेटवर्क के माध्यम से उपलब्ध होगा।
- विधानसभा के पूरा होने के कुछ मिनटों के भीतर पैकेज उपलब्ध होना चाहिए।
पदावनत अवसंरचना: बग ट्रैकर
मुझे डेबियन बग ट्रैकर के साथ बातचीत करने में डर लगता है। डेबग्स 1994 से सीधे कोड का एक टुकड़ा है जो वर्तमान में केवल डेबियन और GNU प्रोजेक्ट द्वारा उपयोग किया जाता है।
डीबग की प्रक्रिया ई-मेल के उपयोग पर आधारित होती है, अर्थात वे अतुल्यकालिक और बोझिल होती हैं। इस तथ्य के बावजूद कि यह सबसे तेज मशीनों पर काम करता है जो हमारे पास डेबियन प्रोजेक्ट पर है (अच्छी तरह से, उन्होंने मुझे बताया कि जब यह विषय आखिरी बार उठाया गया था), तो इसका वेब इंटरफ़ेस बहुत धीरे-धीरे लोड होता है।
विशेष रूप से, bugs.debian.org पर वेब इंटरफ़ेस केवल-पढ़ने के लिए है।
रिपोर्टबग (1) के लिए एक ईमेल
कार्यक्षेत्र स्थापित करना या मैन्युअल रूप से संलग्नक के साथ काम करना एक बहुत गंभीर चुनौती है।
किसी कारण से, जो मुझे समझ में नहीं आता है, डिबग के साथ प्रत्येक इंटरैक्शन में
बहुत सारी बातचीत होती है ।
तकनीकी कार्यान्वयन के अलावा, मैं किसी भी तरह से याद नहीं रख सकता, जिसमें विभिन्न तरीके से त्रुटियों और प्रक्रियाओं के लिए डेबियन छद्म पीढ़ी के पैकेज का उपयोग करता है। मुझे उनके लिए भी शायद ही कभी आवश्यकता होती है आखिरकार इसे मेरे सिर में डाल दें और याद रखें कि वे कैसे कार्य करते हैं और उपयोग किए जाते हैं, लेकिन मैं कभी-कभी उनका सामना करता हूं, इसलिए यह विविधता कष्टप्रद है।
एक आदर्श दुनिया में यह सब कैसा दिखेगा?
- डेबियन ट्रैकिंग मानकों के एक गैर-मानक तरीके से (किसी भी) पहले से ही तय हो जाएगी।
- डेबियन इन प्रक्रियाओं को स्वचालित करता है। मुख्य इंटरफ़ेस अधिक सुविधाजनक होना चाहिए (उदाहरण के लिए, एक वेब फॉर्म)।
पदावनत अवसंरचना: ईमेल पत्राचार अभिलेखागार
मैं इस तथ्य से भ्रमित हूं कि 2019 में हमारे पास अभी भी मेल में संग्रहीत चर्चा सूत्र देखने के लिए एक सुविधाजनक उपकरण नहीं है। जैसा कि डेबियन में व्यापक रूप से है, ईमेल और वार्तालाप अब कहीं भी उपयोग नहीं किए जाते हैं, इसलिए यह कुछ हद तक विडंबनापूर्ण भी है।
Gmane का उपयोग कर इस समस्या को हल करने के लिए लग रहा था, लेकिन पिछले कुछ वर्षों में इसकी उपलब्धता, हल्के ढंग से, अचानक (अब, इस पोस्ट को लिखने के समय, यह काम नहीं करता है) डाल दिया गया है।
मैंने एक बहु-थ्रेडेड संग्रह बनाने की कोशिश की, लेकिन हमारे शीट मास्टर्स प्रभावित नहीं हुए और परियोजना का समर्थन करने से इनकार कर दिया।
मशीनों के लिए डेबियन के साथ काम करना मुश्किल है
यद्यपि यह स्पष्ट है कि आप डेबियन पैकेज के साथ प्रोग्राम कर सकते हैं, यह अनुभव शायद ही सुखद हो। सब कुछ धीमा और भारी लगता है। मैंने इस मुद्दे पर अपनी स्थिति को स्पष्ट करने के लिए तीन छोटे उदाहरणों का चयन किया।
उदाहरण के लिए,
PSQL (1) प्रलेखन पृष्ठों को प्रदर्शित करने के लिए प्रत्येक पैकेज के वैकल्पिक तंत्र का विश्लेषण करने में
डेबिट को piuparts से मदद की ज़रूरत है। यह आवश्यक था क्योंकि स्क्रिप्ट शेल स्क्रिप्ट को कॉल करके वैकल्पिक डेटाबेस को संशोधित करती हैं। लेकिन वास्तव में पैकेज को स्थापित किए बिना, आपको नहीं पता कि यह क्या बदलाव करता है।
pk4 को अपने नाम के आधार पर पैकेज मेटाडेटा की खोज करने के लिए अपना कैश रखना चाहिए। अन्य उपकरण प्रत्येक कॉल के साथ खरोंच से उपयुक्त डेटाबेस का विश्लेषण करते हैं। सही डेटाबेस प्रारूप, या कम से कम बाइनरी एक्सचेंज प्रारूप, इस प्रक्रिया के लिए बहुत महत्वपूर्ण होगा।
डेबियन कोड सर्च नए पैकेज को जल्द से जल्द प्राप्त करना चाहता है।
फ़ेडम्सग इंस्टेंस का उपयोग पहले किया गया था, लेकिन अब यह मौजूद नहीं है। यह स्पष्ट नहीं है कि नए पैकेजों की सूचनाएं कहाँ से प्राप्त की जाएँ और उन्हें प्राप्त करना कहाँ तक सर्वोत्तम है।
जटिल बिल्ड स्टैक
यहाँ आप सिर्फ मेरी पोस्ट
"डेबियन पैकेज बिल्ड टूल्स" पढ़ सकते हैं। वास्तव में मुझे जो चिंता है वह यह है कि उपकरणों की संख्या में वृद्धि को समस्या नहीं माना जाता है।
डेबियन एक डेवलपर के लिए एक दर्दनाक अनुभव है
अधिकांश प्रश्न मैंने डेबियन विकास के अनुभव से उठाए थे, लेकिन, जैसा कि मैंने हाल ही में अपने
डेबियन डिबग डिबगिंग अनुभव पोस्ट में वर्णित किया है,
डेबियन का उपयोग करने का विकास अनुभव भी वांछित होने के लिए बहुत कुछ छोड़ देता है।
मेरे पास और विचार हैं
लेख काफी बड़ा निकला, लेकिन मुझे आशा है कि आपको मेरी प्रेरणा का एक अनुमान है।
हालांकि मैंने ऊपर कई विशिष्ट दोषों का वर्णन किया था, ताबूत के ढक्कन में आखिरी कील भविष्य के लिए सकारात्मक दृष्टिकोण की कमी है। मेरे पास अन्य विचार हैं जो मुझे वास्तव में आश्वस्त करते हैं, लेकिन मेरी पिछली परियोजनाएं कैसे आगे बढ़ती हैं, इसके आधार पर, मुझे नहीं लगता कि मैं उनमें से किसी को भी डेबियन परियोजना के हिस्से के रूप में लागू कर सकता हूं।
मैं अपने ब्लॉग पर ऑपरेटिंग सिस्टम को बेहतर बनाने के लिए विशिष्ट तरीकों पर कुछ और पोस्ट करने का इरादा रखता हूं। तो अंदर ही छोड़ दो।
और अंत में, मुझे उम्मीद है कि यह पोस्ट किसी को, आदर्श रूप से लोगों के एक समूह को प्रेरित करती है, डेबियन डेवलपर्स के जीवन को बेहतर बनाने के लिए।