MOTU / डेवलपर पथ पर चलने के लिए सबसे बड़ी बाधाएं क्या हैं? [बन्द है]


26

उन लोगों के लिए जो MOTU नहीं हैं (वे लोग जो यूनिवर्स और मल्टीवर्स सॉफ़्टवेयर रिपॉजिटरी बनाए रखते हैं ) और जिनके पास "मैं $ तारीख तक मोटू पर लागू होगा" की योजना नहीं है:

क्या आप और आपके जैसे अन्य व्यक्ति को मोटू बनने की कोशिश से दूर रखता है? आपको क्या लगता है कि आप एक नहीं बन सकते?

मैं सामाजिक और तकनीकी दोनों बाधाओं की बात कर रहा हूँ।

संपादित करें: मैं केवल मोटू कह रहा हूं क्योंकि यह एक बहुत ही सामान्य समूह है, लेकिन "आप अपलोडिंग के लिए प्रयास करने के लिए आखिरकार पैकेजिंग / पैचिंग और इरादा क्यों नहीं कर रहे हैं?" और भी सामान्य संस्करण है।


7
कृपया MOTU को wiki.ubuntu.com/MOTU का लिंक उन लोगों के लिए बनाएं जो यह नहीं जानते हैं कि यह क्या है (मेरे जैसे)
स्टीव आर्मस्ट्रांग

1
मैं मानता हूं कि एक लिंक मददगार होगा। हालांकि, यह देखते हुए कि यह सवाल इस बारे में है कि लोग किसी विशेष चीज का हिस्सा क्यों नहीं हैं, यह बेहतर होगा कि प्रश्न में शब्दजाल की व्याख्या करें।
मबेरली

@ रॉबर्टली: MOTU डेवलपर्स हैं जो उबंटू अभिलेखागार के ब्रह्मांड (और मल्टीवर्स) अनुभाग में पैकेज अपलोड कर सकते हैं।
txwikinger

मेरे ubuntu-dev और ubuntu-coredev सदस्यता को नवीनीकृत करने के लिए भूल जाते हैं और फिर से प्रक्रिया से गुजरने का समय नहीं छोड़ते हैं यही कारण है कि मैं अब कोई MOTU / कोरडेव नहीं हूं ;-)
19:aphink

1
प्रश्न की शैली के कारण सामुदायिक विकी में परिवर्तित।
मार्को Ceppi

जवाबों:


11

बेहतर प्रलेखन प्रदान करें।

मैंने पैकेजिंग और मोटू सामान (दो बार पहले ही) से संबंधित डेवलपर हफ्तों के आईआरसी सत्रों में भाग लिया है और पाया है कि उन सत्रों के दौरान आपको आमतौर पर प्रक्रिया की अस्पष्ट समझ होती है। लेकिन अगर आप दो सप्ताह बाद उबंटू विकी के पन्नों को देखते हैं, तो आपको सभी टुकड़े एक साथ नहीं मिल सकते हैं। वे पृष्ठ अक्सर उन लोगों की बुलेट बिंदु सूचियों की तरह होते हैं जो पहले से ही इस प्रक्रिया को विस्तार से समझते हैं। लेकिन वह सामग्री को नए के लिए समझने योग्य बनाने के लिए पर्याप्त नहीं है।

तो शायद आपको दस्तावेज़ विकी पृष्ठों को प्राप्त करने की कोशिश करनी चाहिए, प्रक्रिया, उपकरण और लोगों को और अधिक विस्तार से समझाएं। या पूरे उदाहरणों के साथ भी। आईआरसी सत्रों के दौरान हमेशा दोहराए जाने वाले उदाहरण होते हैं, हो सकता है कि वे विकी पृष्ठों में अंतर करते हैं।


2
मैं मानता हूं कि विकी पेज बहुत मददगार नहीं हैं। मुझे YouTube पर डैनियल होलबैक के वीडियो सबसे अधिक मददगार लगे जब मैं शुरू कर रहा था। क्या IRC सत्र के लॉग विकि पर पोस्ट किए गए हैं?
maco

14

मुझे लगता है कि सबसे बड़ा तकनीकी अवरोध डेबियन पैकेज बनाने का तरीका जान रहा है। हालांकि वर्किंग पैकेज बनाना अपेक्षाकृत सरल है, डेबियन और उबंटू के मानक तक पैकेज बनाना बहुत कठिन है। इसके अलावा, पैकेज बनाने के बारे में गाइड आमतौर पर ऐसी स्थिति से निपटते हैं जिसमें आपके पास स्रोत कोड होता है जिसे संकलन की आवश्यकता होती है। यह व्याख्या की गई भाषाओं में लिखे गए अनुप्रयोगों के लिए भ्रामक हो सकता है।

सबसे बड़ा सामाजिक अवरोध शायद यह जानना चाहता है कि ब्रह्मांड / मल्टीवर्स रिपॉजिटरी में अपलोड किए गए पैकेज कैसे प्राप्त करें। यह सिर्फ अपने स्वयं के ppa बनाने और वहाँ संकुल अपलोड करने के लिए एक बहुत सरल है।


11

आजकल लोग ड्राइव-बाय योगदान पसंद करते हैं

20 साल पहले आप आमतौर पर एक पालतू प्रोजेक्ट पर अपनी ऊर्जा का एक बहुत ध्यान केंद्रित करेंगे, अगर आपके पास एक था। आज आप एक दिन में दर्जनों इंटरनेट पृष्ठों पर जाते हैं, और बहुत सारे सोशल नेटवर्क या अन्य समुदाय हैं, जहाँ आप विकी, फ़ोरम और अन्य सामान में योगदान कर सकते हैं। जबकि इसने और अधिक लोगों को योगदान दिया है, इसने लोगों को निम्न बाधा प्रविष्टियों (एक ला "बस इसे संपादित करने के लिए वेबसाइट पर क्लिक करने की उम्मीद की) का नेतृत्व किया। अन्यथा वे सिर्फ अन्य समुदायों की ओर रुख कर सकते हैं।

इसलिए आपको मोटू प्रक्रिया में बाधाओं को देखना चाहिए। मुझे याद है कि लॉन्चपैड की मेजबानी वाली परियोजनाओं में पैच योगदान के लिए बाधा को कम करने के लिए ग्राउंडकंट्रोल प्रोजेक्ट। हो सकता है कि आपको ऐसे ही नए टूल की आवश्यकता हो, इसलिए नए MOTU उम्मीदवारों को बहुत सारी कमांड लाइन टूल के साथ फिडेल करने की आवश्यकता नहीं है। जबकि वे वर्तमान उपकरण शक्तिशाली हो सकते हैं, संभवतः उन्हें सही तरीके से उपयोग करने के तरीके सीखने में बहुत अधिक ऊर्जा लगती है।


3
मुझे नहीं पता कि क्या मुझे ऐसे लोगों का विचार पसंद है जो शेल बनाए रखने वाले पैकेज का उपयोग नहीं कर सकते हैं, क्योंकि शेल स्क्रिप्टिंग पैकेजिंग का एक महत्वपूर्ण हिस्सा है (यानी, शेल स्क्रिप्ट हैं जिन्हें आपको कई पैकेज बनाने के लिए लिखने / संशोधित करने की आवश्यकता है। काम)।
maco

@ मैको: क्या आप नए योगदानकर्ता प्राप्त करना चाहते हैं या नहीं? यदि हां, तो आपको स्वीकार करना चाहिए कि प्रक्रियाओं को बदलने की आवश्यकता हो सकती है (और प्रक्रियाओं में शामिल लोगों को नहीं)। संभ्रांत सोच संभावित समुदाय के एक बड़े हिस्से को बाहर कर देगी। और यदि आप आरंभ करने के लिए वितरित प्रयास प्राप्त करना चाहते हैं, तो कमांड लाइन आम तौर पर उस का समर्थन करने के लिए एक बहुत खराब उपकरण है।
बनान्वेइज़न

1
यह कहने जैसा है कि "आपको कर्नेल पैच लिखने के लिए कुछ सी जानने की आवश्यकता है" अभिजात्य है। आपको बस यह जानने की जरूरत है कि पैकेज में जाने वाली स्क्रिप्ट को लिखने के लिए कमांड लाइन कैसे काम करती है। यहां तक ​​कि अगर आपके पास एक पैकेज बनाने के लिए जीयूआई था, तो यह "यहां पोस्टस्टोन शेल स्क्रिप्ट टाइप करें" के एक समूह के साथ समाप्त होगा।
मैको

1
मेरी टिप्पणी तकनीकी आवश्यकताओं के बारे में नहीं थी। मैं रीफ़्रेज़ करने का प्रयास करूँगा (मैं एक देशी अंग्रेजी वक्ता नहीं हूँ): सबसे पहले आप अतिरिक्त योगदानकर्ताओं के लिए पूछते हैं। बाद में मैंने आपकी टिप्पणी में पढ़ा: यदि आप शेल स्क्रिप्ट नहीं लिख सकते हैं, तो आपको पैकेजिंग में भाग लेने के लिए गूंगा होना चाहिए। वह मुझे परेशान करता है। मुझे अभी भी विश्वास है कि आपकी धारणाएँ गलत हैं। ग्राउंड कंट्रोल तक हर किसी को एलपी में कुछ प्रोजेक्ट को पैच करने में सक्षम होने के लिए संस्करण नियंत्रण प्रणालियों को जानना था। संस्करण नियंत्रण को आसान बनाने के बजाय, जीसी ने पैचिंग के एकल उपयोग मामले पर विरोधाभास किया और संस्करण नियंत्रण प्रणालियों के बारे में कुछ भी जानने की आवश्यकता को हटा दिया।
Bananeweizen

1
मैंने कहीं भी "गूंगा" नहीं कहा। मैंने कहा यह एक आवश्यक कौशल है। किसी भी जटिल पैकेज के लिए, आपको एक शेल स्क्रिप्ट लिखनी होगी । अज्ञानता ( अभी तक एक निश्चित कौशल नहीं सीखा है) और खुफिया किसी भी तरह से समान नहीं हैं।
मैको

9

सबसे बड़ा बैरियर मैंने पाया है उबंटू डेवलपर पेज: http://www.ubuntu.com/community/get-involved/developers

इसलिए कई बार, मैंने उत्साहपूर्वक उबंटू में कम से कम 1 पैच योगदान करने के लिए निर्धारित किया है ... इसलिए मैं वेबसाइट पर प्राकृतिक स्थान पर जाता हूं ... और प्रलेखन के समुद्र में खो गया। घंटों बाद, मुझे अभी तक पता नहीं है कि मुझे किस लिए पैच लिखना चाहिए। जब मैं उबंटू कीड़े के माध्यम से देखता हूं, तो मुझे अक्सर पैच मिलते हैं ... कई जो वहां अप्रयुक्त बैठते हैं।

जहां तक ​​पैकेज जाते हैं, मैंने यह पता लगाने की कोशिश की है कि उन्हें कैसे बनाया जाए, यह वास्तव में भ्रमित करने वाला है। मैंने लॉन्च पैड में शामिल होने की भी कोशिश की, लेकिन स्रोत फोर्ज की तुलना में इंटरफ़ेस बहुत अधिक जटिल है, मैं एलपी पर अपना कोड प्राप्त नहीं कर सका। एक नए उपयोगकर्ता के लिए यह बहुत मुश्किल है।


2
हां, लॉन्चपैड डिजाइन में एक समस्या है। एलपी पर चीजें स्पष्ट नहीं हैं। यह आसान है लेकिन आपको इसके लिए बहुत कुछ देखना होगा। नए उपयोगकर्ता जल्दी खो जाते हैं। इसे GitHub की तरह इसे अधिक स्पष्ट और सरल बनाने के लिए एक नया स्वरूप चाहिए।
ओवैस लोन

8

मोटू बनना एक जिम्मेदारी है

ठीक है, स्पष्ट रूप से # 1 कारण तकनीकी रूप से पर्याप्त रूप से जानकार नहीं है, और # 2 कारण आपके पास एक स्क्वील चीजें हैं जो आप नहीं करेंगे। लेकिन आपके लक्षित दर्शकों के बीच, मुझे लगता है कि इसका मुख्य कारण यह जिम्मेदारी है।

अगर मैं अपने लिए एक पैकेज संकलित करता हूं, तो किसी और को परवाह नहीं है कि मैंने तकनीकी और कानूनी नीतियों का पालन किया है या नहीं। कोई भी मेरे पास यह उम्मीद करने नहीं आएगा कि मैं एक नया संस्करण पैकेज करूं। कोई मुझे बग ठीक करने के लिए नहीं कहेगा।

अगर मैं अपना पैकेज एक ppa पर अपलोड करता हूं, तो कुछ लोग देखभाल कर सकते हैं। लेकिन उम्मीदें उतनी नहीं हैं। मैं बस गायब हो सकता हूं और लोगों को अपने ब्लॉग पर शिकायत करने दे सकता हूं कि यह कितना दुख की बात है कि पैकेज नैटली के लिए उपलब्ध नहीं है।

अगर मैं एक मोटू बन जाता हूं, तो अचानक मेरी बड़ी जिम्मेदारी बन जाती है। उपयोगकर्ता बग रिपोर्ट के साथ मेरे पास आएंगे और यदि मैं उन्हें कल हल नहीं करता हूं तो शिकायत करूंगा। उपयोगकर्ता यह उम्मीद करेंगे कि जैसे ही यह अपस्ट्रीम उपलब्ध होगा मैं पैकेज का नया संस्करण अपलोड कर दूंगा। मुझे गैर-तकनीकी उपयोगकर्ताओं को यह समझाना होगा कि उन्होंने क्या गलत किया। एक मंच पर पोस्ट करने के विपरीत, मुझे उन सवालों को नजरअंदाज नहीं करना चाहिए जिन्हें मैं जवाब देने की तरह महसूस नहीं करता हूं। और अन्य डेवलपर्स मेरे पीछे पड़ सकते हैं क्योंकि मैंने कुछ गड़बड़ कर दी है - यह डराने वाला हो सकता है।

और मुझे क्या मिलेगा?

  • एक फजी एहसास कि मैंने लोगों की मदद की है। वह बात कर सकता है। लेकिन अगर यह मेरी मुख्य प्रेरणा है, तो पैकेजिंग सॉफ्टवेयर की तुलना सूप किचन में मदद करने या अपने आउट-ऑफ-वर्क-आप्रवासी पड़ोसी के बच्चों की ट्यूशन से कैसे की जा सकती है?

  • मेरे फिर से शुरू होने पर एक गोली बिंदु? मेह, एक प्रोग्रामर के रूप में एफओएसएस में भाग लेना बहुत अधिक सराहना होगी। (यह आपको परियोजना प्रबंधन और दीर्घावधि मैटिनेन्स जैसी चीजों के साथ अनुभव प्रदान करता है जो कॉलेज के पाठ्यक्रमों में पढ़ाने के लिए कठिन हैं।) वास्तव में, डीडी / मोटू होने के नाते कई नियोक्ताओं को संदेह होता है जो राजनीतिक रूप से शामिल कर्मचारियों पर भड़कते हैं (आप FOSS को खुले तौर पर राजनीतिक समर्थन देना)।

  • संतुष्टि की भावना? खरोंच से अपना कार्यक्रम लिखने से बहुत कम होगा। प्रोग्रामिंग पैकेजिंग की तुलना में बहुत अधिक रचनात्मक है। इसमें उपलब्धि का एक बड़ा अर्थ है। डींग मारने का अधिकार है। लेकिन पैकेजिंग में? यह एक घर का काम है। यह ग्लैमरस नहीं है।

(यह एक तीसरा व्यक्ति "मैं" ऊपर है। मुझे लगता है कि मैं जिन कारणों को देता हूं, वे ज्यादातर लोगों पर लागू होते हैं, लेकिन अलग-अलग विशेषज्ञों के लिए लागू होते हैं। व्यक्तिगत रूप से यह मुख्य रूप से एक स्किलियन चीजें हैं जो मैं नहीं करूंगा, और पैकेजिंग में रचनात्मक उपलब्धि की भावना की कमी है।)

(जिज्ञासा से बाहर, क्या उबंटू में जनशक्ति की कमी है?)


1
हाँ यह करता है। क्या आपने हमारा बगट्रैकर देखा है?
मैको

@ मैको: मोटू पेज पर , मैं आसानी से देखता हूं कि एक मोटू क्या है और मैं एक कैसे बन सकता हूं। मुझे "अंकल उबंटू को आपकी जरूरत है!" मुझे नहीं लगता कि बगट्रैकर एक आकस्मिक उपयोगकर्ता को बहुत कुछ बताता है; उदाहरण के लिए बहुत सारे अस्पष्ट बगों का मतलब बहुत सारे रिपोर्ट-एंड-रन उपयोगकर्ता हो सकते हैं जो बग को पुन: उत्पन्न करने के लिए पर्याप्त जानकारी पोस्ट नहीं करते हैं।
गिल्स एसओ- बुराई को रोकना '

मुझे गिल्स से पूरी तरह सहमत होना चाहिए। यदि मेरे पास ओपन सोर्स को समर्पित करने के लिए अधिक समय है तो मेरे पास कुछ ऐसी परियोजनाएँ हैं जिन्हें मैं प्रोग्राम करना पसंद करूँगा।
जेवियर रिवेरा

इस तरह बहुत सारे बग हैं, लेकिन अंततः निष्क्रियता के कारण वे बंद हो जाते हैं। लॉन्चपैड पर पैच के साथ ~ 2000 बग हैं। ऑपरेशन क्लीनस्वेप के बारे में जा रहा है और पैच की समीक्षा कर रहा है और उन्हें ऊपर भेज रहा है अगर अच्छा है और बुरा है तो अस्वीकार कर देगा। यदि वे अच्छे हैं और अपस्ट्रीम रिलीज के माध्यम से प्राप्त करने के लिए पूरे रिलीज चक्र का इंतजार नहीं करना चाहिए, तो उन्हें पैक करने की आवश्यकता है। हालांकि कई सालों पुराने हैं। हमने उन्हें प्रस्तुत की गई दर के साथ नहीं रखा है।
मैको

4

भाषा , मेरी मुख्य समस्या यह है कि मैं अभी भी अंग्रेजी के साथ पर्याप्त आश्वस्त नहीं हूं, इसलिए, मैं आसानी से समझ नहीं पा रहा हूं कि अन्य डेवलपर्स मुझे क्या बताने की कोशिश कर रहे हैं


3

मोटो बनने के लिए मुझे क्या करना चाहिए?

Eventhough उबंटू एक बहुत अच्छा समुदाय है (मुझे n00bie सवालों के लिए नहीं लौटाया गया है, फिर भी) मुझे लगता है कि पैकेजिंग प्रक्रिया के बारे में कुछ / अधूरा प्रलेखन है (यहां तक ​​कि डेबियन का नया रखरखाव गाइड भरा हुआ है) यह विषय दायरे से बाहर है इस दस्तावेज़ के "लाइनों)। यदि आप इस तथ्य को लेते हैं और उन लोगों के बारे में सोचते हैं जो पहली भाषा नहीं है, तो अंग्रेजी (मेरी तरह) प्रक्रिया और भी कठिन और काथिक है।

इस बिंदु पर एक सरल, सही अधिकार के साथ, हर चीज़ का दस्तावेज़ीकरण करना हम सभी के लिए आसान होगा, लेकिन जिन लोगों के पास यह लिखने के लिए तकनीकी कौशल हैं कि दस्तावेज़ बहुत व्यस्त हैं।


3

मुझे लगता है कि इसके कई कारण हैं। मुझे भी लगता है कि कारण अक्सर अलग-अलग होते हैं।

इस समय समस्याओं में से एक, पूरे MOTU प्रणाली में परिवर्तन है। मेरा मानना ​​है कि परिवर्तन भ्रामक हो सकते हैं, और तकनीकी तर्ज पर अधिक लागू किए गए हैं और दुर्भाग्य से समुदाय को पूरी तरह से बोर्ड पर नहीं लाया गया है (शायद सिर्फ इसलिए कि यह भ्रामक है)।

मुझे भी लगता है, कुछ मामलों में मोटू बनने की प्रेरणा उतनी स्पष्ट नहीं है जितनी कि हो सकती है। IMHO, एक MOTU होना एक जिम्मेदारी है, न कि विशेषाधिकार। यह शीर्षक के बारे में नहीं है, लेकिन उबंटू समुदाय को इसके साथ आने वाले अधिकारों का उपयोग करने की क्षमता के बारे में है। इसके कारण, यह हो सकता है कि संपूर्ण अनुमोदन प्रक्रिया को संशोधित (या विस्तारित) किया जा सकता है। मोटू आम तौर पर खुद को नामांकित करते हैं, और फिर बोर्ड को लगता है कि क्या वे मोटू बनने के लिए तैयार हैं। हो सकता है कि यह संभव हो, वह सहकर्मी जो यह मानता हो कि कोई व्यक्ति मोटू बनने के लिए तैयार है, वह उस व्यक्ति को नामांकित करने में सक्षम होगा। यह IMHO अधिक तथ्य का प्रतिनिधित्व करेगा, कि नामांकन प्रक्रिया में मदद करने के लिए किया जाता है, न कि एक शीर्षक प्राप्त करने के लिए। मैं समझता हूं कि इसे बनाने का एकमात्र तरीका इसकी समस्याएं भी हैं, इसलिए, मैं इसे केवल एक विकल्प के रूप में देखता हूं।

मुझे यह भी पता है कि केडीई पर अधिक ध्यान केंद्रित करने वाले लोगों के साथ अतीत में कुछ समस्याएं रही हैं। इन समस्याओं को उम्मीद से संबोधित किया गया है, लेकिन शायद यह अच्छा होगा अगर इसे अधिक व्यापक रूप से जाना जाएगा।

जाहिर है, ये सिर्फ कुछ मुद्दे हैं जिन पर मेरा ध्यान है। लोग अलग हैं और अलग-अलग चीजों को देखेंगे, या एक ही चीज से अलग-अलग प्रभावित होंगे। इसलिए, इस मुद्दे को हर कोई रोक नहीं सकता है, और न ही वे इस समस्या का एकमात्र कारण हैं।


प्रायोजकों को उन लोगों को बताना चाहिए जिनके पैकेज वे प्रायोजित करते हैं जब उन्हें लगता है कि वे तैयार हैं, "हे, शायद आपको अब आवेदन करना चाहिए," लेकिन मुझे नहीं पता कि ऐसा कितनी बार होता है। मैंने सुझाव दिया है कि एक व्यक्ति जिसे मैं सलाह दे रहा था, उसे लागू करना है, लेकिन उसने अपना ध्यान विकास के अन्य क्षेत्रों में बदल दिया।
maco

यह तब भी एक अंतर है जब एक प्रायोजक किसी को आवेदन करने के लिए कहता है, या यह व्यक्ति एक प्रायोजक द्वारा नामित होता है।
19

उह? प्रायोजक लोगों को नामांकित नहीं करते हैं, प्रायोजक प्रायोजक द्वारा स्व-नामांकन की वकालत करते हैं।
लैफेरोन

lfaraone: txwikinger सुझाव दे रहा है कि प्रायोजकों को लोगों को नामांकित करने में सक्षम होना चाहिए। एक बार हुआ है। कुछ लोगों ने जाकर सारा हॉब्स के लिए एक विकी पेज बनाया और टीबी को ईमेल किया और प्रशंसापत्र दिए और इसलिए उस समय तक जब समर्थन की स्पष्ट रूपरेखा थी, तो उसने आखिरी कदम उठाने के लिए आईआरसी बैठक में दिखाया।
maco

2
@Ifaraone: मेरा सुझाव है कि कुछ अच्छे लोग स्वयं को नामांकित नहीं करेंगे और इसलिए हम उन्हें खो देते हैं। अंत में, मोटू बनने वाला एक अच्छा व्यक्ति उबंटू के लिए एक जीत है, शायद हमें इस बारे में सोचना चाहिए।
txwikinger

2

मैंने यहां कुछ विचार पोस्ट किए हैं: http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

एक बात जो मैं वास्तव में सामने लाना चाहता हूं, मुझे आश्चर्य है कि कितने डेवलपर्स बिल्ड सिस्टम का उपयोग नहीं करते हैं जो आसानी से पैकेजिंग टूल में प्लग हो जाते हैं। मैं अजगर विकास कर रहा हूं। मेरे दुनिया के केंद्रों में सेटपॉइंट्स हैं और वितरित करते हैं, और हां, मैं कुछ का निर्माण कर सकता हूं जो मैं उन लोगों के साथ बनाता हूं और इसे निर्यात करता हूं, लेकिन क्या अंत तक? मेरे पास पहले से ही कुछ है जो वितरण योग्य है। मुझे आश्चर्य है कि अगर अपने स्वयं के बिल्ड टूल / वितरण विधियों के साथ स्क्रिप्टिंग भाषाओं के उदय से डेबियन पैकेजिंग टूल और इस प्रकार MOTU स्तरों के साथ चीजों को प्राप्त करने में अनुभव और इच्छा की कमी होती है।


2

मेरे लिए यह शायद समय से संबंधित है। वर्तमान में मेरे पास निवेश करने के लिए बहुत समय नहीं है। और मैंने बग ट्रिगिंग के साथ शुरुआत की, लेकिन जल्द ही पता चला कि चीजें थोड़ी अधिक जटिल थीं। और आपको वास्तव में अपने दांतों को उसमें डुबाने की जरूरत है।

फिर बग फिक्सिंग है, जो मुझे पता है कि मुझे मज़ा आएगा। मुझे वहाँ से मदद करने के लिए क्या रख रहा है, यह है कि आपको एक विकास शाखा या कुछ और चलाने की आवश्यकता है। मैंने एक बार सिस्टम मॉनीटर (https://bugzilla.gnome.org/show_bug.cgi?id=611738) में मेरा एक पेपरकट पर काम करना शुरू कर दिया था, इसलिए मैंने आवश्यक स्रोत लाने और वहां पहुंचने के लिए ग्राउंड कंट्रोल का उपयोग करना शुरू कर दिया। बग को ठीक करें। हालांकि, यह निर्भरता के कारण इतना आसान नहीं निकला। मुझे पता है कि मुझे केवल विकास संस्करण पर काम करना चाहिए, और अगर यह तय है तो परीक्षण करें। हालांकि, सिर्फ यह कोशिश करने के लिए कि मुझे कई अन्य सूक्ति पैकेजों के स्रोत को डाउनलोड करने की आवश्यकता है। जो ग्राउंडकंट्रोल के साथ इतना आसान नहीं है। और आपको शायद ऐसा काम मशीन पर करना चाहिए। इसलिए मैं वहीं रुक गया। (फिर से मुझे बहुत अधिक समय लगेगा, बस इसके लिए शुरुआत करने के लिए)

पैकेजिंग के बारे में, मुझे ऐसी किसी भी चीज़ के बारे में जानकारी नहीं है जिसकी पैकेजिंग की ज़रूरत है। मैंने एक बार पैकेजिंग पर एक ट्यूटोरियल किया है, और पाया कि यह छोटे अनुप्रयोगों के लिए बहुत मुश्किल नहीं है। हालांकि कभी भी सामान की एक सूची की तलाश में बाहर नहीं गया, जिसे पैकेजिंग की आवश्यकता हो, क्योंकि मुझे पता है कि शायद एक है ... :)

तो मूल रूप से मेरे लिए यह सिर्फ समय है, मैं बाहर मदद करना चाहता हूं, लेकिन मेरे पास हर दो सप्ताह में कुछ घंटे (2 या कुछ) हैं। और उस छोटी सी अवधि में मुझे लगता है कि इसके साथ शुरुआत करने में असमर्थ हूं।


आपको निर्भरता के स्रोत की आवश्यकता नहीं है, बस नियमित डेब। क्यों काम करने के लिए विकास रिलीज के एक वीएम सेटअप नहीं? फिर आपको अपने सेटअप के साथ मिलाना नहीं है (हालांकि, मैं फरवरी 2007 से लगभग लगातार लगातार डेवेल रिलीज कर रहा हूं ... एक साल से ज्यादा पहले मैंने पैकेजिंग / उबंटू बग्स से संबंधित कुछ भी करना शुरू कर दिया था)। सप्ताह में एक बार बग को ठीक करना 2 घंटे निश्चित रूप से संभव है जब आप अपना पर्यावरण सेटअप करते हैं। पैकेज की चीजों की एक सूची के रूप में: लॉन्चपैड पर एक ज़रूरत-पैकेजिंग टैग है। मौजूदा पैच की पैकेजिंग बहुत उपयोगी है!
मैको

1

जब मैं एक पैकेज बनाता हूं, तो यह आम तौर पर मेरा एक खुजली को खरोंचने के लिए होता है, न कि इसलिए कि कोई और पैकेज चाहता है। मेरे लिए एक पैकेज बनाने के लिए चेक स्थापना काफी अच्छी है, और फिर मेरी खुजली खराब हो गई है, और मुझे इसे मैन्युअल रूप से पैकेज करने के लिए अतिरिक्त दूरी पर जाने के लिए कोई व्यक्तिगत प्रोत्साहन नहीं है, और सभी निर्भरता और सामान का पता लगाएं।

इसलिए मुझे लगता है कि भले ही वितरण के लिए पैकेजिंग आसान हो, लेकिन यह अभी भी अपने लिए पैकेजिंग से परे एक बहुत अधिक काम है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.