हम सीआई द्वारा संचालित विकास से कैसे बचें…?

Question

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

यह परियोजना एक "कोर" ढांचे से बना है, लगभग आधे-एक-मीलियन-या-कोड की पंक्तियों में, "प्लगइन्स" का एक गुच्छा जो कंसोर्टियम और कई बाहरी प्लगइन्स द्वारा बनाए रखा जाता है, जिनमें से अधिकांश हम ' टी भी के बारे में पता

वर्तमान में, हमारे CI कोर, और बनाए गए प्लगइन्स का निर्माण करते हैं।

हमारे सामने एक बड़ा मुद्दा यह है कि अधिकांश योगदानकर्ता (और विशेष रूप से सामयिक लोग) 90% बनाए गए प्लगइन्स का निर्माण नहीं कर रहे हैं, इसलिए जब वे कोर में परिवर्तनशील बदलावों का प्रस्ताव देते हैं (जो कि इन दिनों काफी नियमित आधार पर होता है), उन्होंने जाँच की कि GitHub पर पुल अनुरोध करने से पहले कोड उनकी मशीन पर संकलित है।

कोड काम करता है, वे खुश हैं, और फिर सीआई ने इमारत का निर्माण किया और समस्याएं शुरू हुईं: संकलन एक कंसोर्टियम-बनाए गए प्लगइन में विफल रहा, कि योगदानकर्ता ने उसकी मशीन पर निर्माण नहीं किया।

उस प्लगइन में उदाहरण के लिए CUDA जैसे थर्ड-पार्टी लाइब्रेरियों पर निर्भरता हो सकती है , और उपयोगकर्ता नहीं चाहता है, पता नहीं कैसे या हार्डवेयर कारणों से नहीं कर सकता है, उस टूटे हुए प्लगइन को संकलित करें।

तो फिर - या तो हो-विलय कर दिया कभी नहीं करने के लिए की अधर में लटकी पीआर रहता विज्ञापन aeternam पीआरएस - या योगदानकर्ता टूट प्लगइन का स्रोत नाम बदल चर greps, कोड, उसका / उसकी शाखा पर धक्का, के लिए प्रतीक्षा करता है बदल जाता है संकलन को समाप्त करने के लिए CI, आमतौर पर अधिक त्रुटियां प्राप्त करता है, और जब तक सीआई खुश नहीं होता है, तब तक प्रक्रिया को दोहराता है - या कंसोर्टियम में पहले से ही ओवरबुक किए गए स्थायी में से एक हाथ देता है और अपनी मशीन पर पीआर को ठीक करने की कोशिश करता है।

उन विकल्पों में से कोई भी व्यवहार्य नहीं है, लेकिन हम यह नहीं जानते कि इसे अलग तरीके से कैसे किया जाए। क्या आप कभी भी अपनी परियोजनाओं की एक समान स्थिति से सामना कर चुके हैं? और यदि हां, तो आपने इस समस्या को कैसे हैंडल किया? क्या कोई उपाय है जो मैं यहाँ नहीं देख रहा हूँ?

Comments

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

— डॉक्टर ब्राउन

मार्टिन फाउलर की "पब्लिक बनाम प्रकाशित इंटरफेसेस" एक उपयोगी रीड हो सकती है।

— Schwern

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

— डॉक्टर ब्राउन

मैं प्रश्न को फिर से लिखूंगा, क्योंकि यह वास्तव में भ्रामक है। की तरह कुछ मैं पीआरएस कैसे प्रबंधित कर सकते हैं जब वे हमारे वर्तमान सीआई को तोड़ने? मुझे लगता है कि बेहतर अपनी स्थिति पर कब्जा।

— bracco23

आपकी निर्माण / परीक्षण प्रक्रिया कितनी कठिन / जटिल है? यह सिर्फ एक कमांड चलाने या सिंगल बटन पर क्लिक करने की बात होनी चाहिए। उस समय, उपयोगकर्ताओं को पीआर सबमिट करने से पहले अपने लिए सभी परीक्षण चलाने की अपेक्षा करना उचित होगा।

— अलेक्जेंडर

Answer 1

CI संचालित विकास ठीक है! यह परीक्षण नहीं चलाने और टूटे हुए कोड सहित बहुत बेहतर है! हालांकि, इसमें शामिल सभी चीजों को आसान बनाने के लिए कुछ चीजें हैं:

• अपेक्षाएँ निर्धारित करें: योगदान प्रलेखन है जो बताता है कि CI अक्सर अतिरिक्त मुद्दों को पाता है, और ये कि एक मर्ज से पहले तय करना होगा। शायद यह समझाएं कि छोटे, स्थानीय परिवर्तन अच्छी तरह से काम करने की संभावना रखते हैं - इसलिए कई पीआरएस में बड़े बदलाव को विभाजित करना समझदार हो सकता है।

• स्थानीय परीक्षण को प्रोत्साहित करें : अपने सिस्टम के लिए एक परीक्षण वातावरण स्थापित करना आसान बनाएं। एक स्क्रिप्ट जो पुष्टि करती है कि सभी निर्भरताएं स्थापित की गई हैं? एक डॉकटर कंटेनर जो जाने के लिए तैयार है? एक आभासी मशीन छवि? क्या आपके परीक्षण धावक में ऐसे तंत्र हैं जो अधिक महत्वपूर्ण परीक्षणों को प्राथमिकता देने की अनुमति देते हैं?

• अपने लिए CI का उपयोग करने का तरीका बताएं: हताशा का हिस्सा यह है कि यह प्रतिक्रिया केवल पीआर सबमिट करने के बाद आती है। यदि योगदानकर्ता अपने स्वयं के रिपॉजिटरी के लिए CI की स्थापना करते हैं, तो उन्हें पहले की प्रतिक्रिया मिलेगी - और अन्य लोगों के लिए कम सीआई सूचनाओं का उत्पादन करेगा।

• सभी पीआरओं को हल करें, किसी भी तरह से: यदि कुछ को विलय नहीं किया जा सकता है क्योंकि यह टूट गया है, और यदि कोई समस्या ठीक होने की दिशा में प्रगति नहीं हुई है, तो इसे बंद करें। इन परित्यक्त खुले पीआरएस बस सब कुछ अव्यवस्थित करते हैं, और कोई भी प्रतिक्रिया सिर्फ मुद्दे की अनदेखी करने से बेहतर है। यह बहुत अच्छी तरह से वाक्यांश करना संभव है, और यह स्पष्ट करें कि निश्चित रूप से जब आप समस्याओं को ठीक कर लेंगे तो आप विलय करने में प्रसन्न होंगे। (यह भी देखें: जेसी फ्रैजेल द्वारा बंद करने की कला , बनाए रखने के लिए सर्वश्रेष्ठ अभ्यास: सीखने के लिए ना कहना )

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

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

Comments

"ये खुला खुला

— पीआर

Answer 2

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

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

Comments

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

— candied_orange

@ लैगर्कैन अच्छी तरह से परिभाषित तकनीकी से अधिक नीतिगत मुद्दा है। वहाँ सॉफ्टवेयर है कि तुम्हारी तरह, बस एक उन्नयन में पिछले व्यवहार को छोड़ रहे हैं। Perl5 Perl6 के साथ संगत नहीं है, Python2.7 Python3.4 आदि के साथ पूरी तरह से संगत नहीं है, फिर ऐसे सॉफ़्टवेयर हैं जो कुछ भी होता है वह अभी भी पुराने कोड का समर्थन करता है। आप अभी भी आधुनिक ब्राउज़र में नेटस्केप नेविगेटर 4 के लिए लिखे गए लगभग सभी जावास्क्रिप्ट कोड चला सकते हैं। Tcl प्रोग्रामिंग भाषा मूल संस्करण आदि के लिए बैकवर्ड संगत तरीका है ...

— slebetman

@ लैगार्केन: कंसोर्टियम का गठन सही दिशा में एक कदम था, और अगर कोर सदस्य इन इंटरफेस को बाहर निकालने पर अपनी ऊर्जा केंद्रित करते हैं, तो आप भविष्य के पीएचडी और इंटर्न की शक्ति को कम कर सकते हैं ताकि आपकी परियोजना को मजबूत बनाने में मदद मिल सके। :)

— कैसाब्लांका

@ फैटी: यह ऐप्पल के लिए काम करता है क्योंकि वे सफल उपभोक्ता-सामना वाले उत्पादों का निर्माण करते हैं और डेवलपर्स को इसके साथ खेलने के लिए मजबूर किया जाता है यदि वे इसका हिस्सा बनना चाहते हैं। यह संभावना नहीं है कि उन डेवलपर्स वास्तव में परिवर्तन को तोड़ना पसंद करते हैं, और यह निश्चित रूप से एक ओपन-सोर्स प्रोजेक्ट के लिए एक अच्छा मॉडल नहीं है।

— कैसाब्लांका

@ मैकस्बांका दोनों मैकओएस और विंडोजओएस वंशावली बेहद सफल हैं। (संभवतः, मानव अस्तित्व में सरासर डॉलर की शर्तों में दो सबसे बड़े उत्पाद।) दशकों से उनके पास बिल्कुल विपरीत दृष्टिकोण थे। जाहिरा तौर पर दोनों सफल रहे थे!

— फेटी

Answer 3

ईमानदार होने के लिए, मुझे नहीं लगता कि आप इसे बेहतर तरीके से संभाल सकते हैं - यदि परिवर्तन से आपकी परियोजना के बनाए हुए भागों को तोड़ने में परिणाम होता है तो सीआई को विफल होना चाहिए।

क्या आपके प्रोजेक्ट में contributing.mdउनके योगदान की तैयारी के साथ नए और सामयिक योगदानकर्ताओं की मदद के लिए एक समान है? क्या आपके पास एक स्पष्ट सूची है, कौन से प्लग इन कोर का हिस्सा हैं और संगत रहने की आवश्यकता है?

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

Comments

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

— lagarkane

Answer 4

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

इसलिए मुझे लगता है कि यह वह जगह है जहां ओपन सोर्स प्रोजेक्ट्स की ढीली शैली नीचे गिर सकती है; अधिकांश केंद्र-संगठित परियोजनाएं कोर रिफैक्टरिंग से सावधान हैं, खासकर जब यह एपीआई सीमा पार करता है। यदि वे एक एपीआई सीमा को रिफैक्टर करते हैं, तो यह आमतौर पर एक "बड़ा धमाका" होता है, जहां सभी बदलाव एक बार एपीआई प्रमुख संस्करण में वृद्धि के साथ निर्धारित होते हैं, और पुराने एपीआई को बनाए रखा जाता है।

मैं एक नियम का प्रस्ताव करता हूं "सभी एपीआई परिवर्तनों को अग्रिम में नियोजित किया जाना चाहिए": यदि कोई पीआर आता है तो एपीआई से एक पिछड़े असंगत परिवर्तन करता है, किसी ऐसे व्यक्ति से जो अनुरक्षकों के संपर्क में पहले से उनके दृष्टिकोण से सहमत नहीं हुआ है, यह बस बंद हो जाता है और जमाकर्ता शासन में बताया जाता है।

आपको प्लगइन एपीआई के स्पष्ट संस्करण की भी आवश्यकता होगी। यह आपको v2 विकसित करने की अनुमति देता है, जबकि सभी v1 प्लगइन्स का निर्माण और काम करना जारी रहता है।

मैं थोड़ा और सवाल करूंगा कि इतने सारे कोर रिफैक्टरिंग और एपीआई परिवर्तन क्यों किए जा रहे हैं। क्या वे वास्तव में आवश्यक हैं या सिर्फ लोग परियोजना पर अपना व्यक्तिगत स्वाद लगा रहे हैं?

Answer 5

लगता है कि सीआई प्रक्रिया को तंग करने की जरूरत है, अधिक व्यापक और अधिक योगदानकर्ताओं के लिए दृश्यमान होने से पहले वे एक पीआर बढ़ाते हैं। एक उदाहरण के रूप में, BitBucket में एक पाइपलाइन सुविधा है जो इसे अनुमति देती है, जहां आप इसे एक फाइल देते हैं जो CI निर्माण प्रक्रिया को परिभाषित करता है, और यदि यह विफल रहता है, तो शाखा को विलय होने से रोका जाता है।

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

डिजाइन के मुद्दों को ठीक करने के लिए अच्छा होगा, लेकिन इस समस्या के लिए रूढ़िवादी हैं।

Answer 6

कोड काम करता है, वे खुश हैं, और फिर सीआई ने इमारत का निर्माण किया और समस्याएं शुरू हुईं: संकलन एक कंसोर्टियम-बनाए गए प्लगइन में विफल रहा, कि योगदानकर्ता ने उसकी मशीन पर निर्माण नहीं किया।

उस प्लगइन में उदाहरण के लिए CUDA जैसे थर्ड-पार्टी लाइब्रेरियों पर निर्भरता हो सकती है, और उपयोगकर्ता नहीं चाहता है, यह नहीं जानता कि हार्डवेयर कारणों से कैसे, या बस नहीं कर सकते हैं, उस टूटे हुए प्लगइन को संकलित करें।

आपका समाधान सरल है: योगदान में बाधा कम करें ।

(1) एडिट-कंपाइल-टेस्ट साइकिल और (2) सुचारू पर्यावरण अंतर के लिए सबसे आसान तरीका बिल्ड सर्वर प्रदान करना है :

• संकलन को गति देने के लिए 24, 48 या 96 कोर, 2GB रैम / कोर, SSD: बीफ़ मशीनें चुनें।
• सुनिश्चित करें कि उनके पास सही हार्डवेयर है: FPGA, ग्राफिक कार्ड, जो भी आवश्यक हो।
• पूर्व-स्थापित सभी आवश्यक सॉफ़्टवेयर पुस्तकालयों के साथ एक डॉकर छवि बनाएं।

और फिर उन बिल्ड सर्वर को योगदानकर्ताओं के लिए खोलें। वे एक ताज़ा डॉकर छवि में दूरस्थ रूप से लॉगिन करने में सक्षम होना चाहिए, और इस मशीन पर दूरस्थ रूप से संपादित-संकलन-परीक्षण करें।

फिर:

• उनके पास बनाए गए प्लगइन्स के निर्माण / परीक्षण के लिए कोई बहाना नहीं है: उनके पास सब कुछ उपलब्ध है।
• उन्हें सीआई-चालित पीआर के साथ लंबी प्रतिक्रिया के लिए इंतजार नहीं करना पड़ता है: उनके पास वृद्धिशील संकलन है, और डीबग करने की क्षमता है (अनुमान के बजाय)।

सामान्य तौर पर, बिल्ड सर्वरों को कई योगदानकर्ताओं के बीच साझा किया जा सकता है, हालांकि जब विशेष हार्डवेयर बाह्य उपकरणों को शामिल किया जाता है, तो यह योगदानकर्ता के लिए आवश्यक हो सकता है कि वे स्वयं द्वारा परिधीय का उपयोग करें।

---

स्रोत: FPGAs का उपयोग करते हुए सॉफ्टवेयर पर काम करना, जानवरों की कीमत को देखते हुए, और जिस मॉडल की हमें ज़रूरत है, आपको FPGA के प्रत्येक मॉडल को प्रत्येक डेवलपर की मशीन पर स्थापित नहीं किया गया है।

Answer 7

यदि किसी अनुबंध को बदले बिना कोर में योगदान निर्भर सॉफ्टवेयर को तोड़ सकता है, तो यह सुझाव देता है कि:

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

या तो समस्या को हल करना आसान होना चाहिए, लेकिन आप उल्लेख करते हैं कि कोर टीम में ऐसा करने की क्षमता नहीं हो सकती है। एक विकल्प यह होगा कि समस्या के समाधान के लिए समुदाय से मदद मांगी जाए।

Answer 8

लगता है कि किसी और ने इसे संभावित समाधान के रूप में नहीं उठाया है।

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

कोर विकसित करते समय, डेवलपर्स को इन संगतता परीक्षणों को चलाने के लिए प्रोत्साहित करें। यदि वे असफल होते हैं तो जांच नहीं करते हैं।

यह 100% संगतता सुनिश्चित नहीं करेगा लेकिन यह बहुत अधिक मुद्दों और जल्दी पकड़ लेगा।

एक माध्यमिक लाभ यह है कि ये रिकॉर्डिंग उजागर कर सकती हैं कि कौन से इंटरफेस सक्रिय रूप से उपयोग किए जाते हैं, और कौन सी सुविधाओं का सक्रिय रूप से उपयोग किया जा रहा है।

Answer 9

मुझे स्थिति को समझने में परेशानी हो रही है क्योंकि ऐसा प्रतीत होता है: सीआई केवल एक शाखा बनाता है?

क्या कोई कारण है कि आप CI के साथ एक से अधिक शाखा नहीं बना सकते हैं?

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

फिर आपको बस उस शाखा के लिए एक सफल CI बिल्ड की आवश्यकता होती है ताकि उस शाखा के पुल अनुरोध को स्वीकार किया जा सके।

Comments

यह समस्या का योग है।

— फेटी

प्रश्न कहता है "या योगदानकर्ता [...] कोड को बदलता है, उसकी शाखा पर धकेलता है, सीआई के संकलन का इंतजार करता है, आमतौर पर अधिक त्रुटियां मिलती हैं, और जब तक सीआई खुश नहीं होता है, तब तक प्रक्रिया दोहराती है" - इसलिए मुझे लगता है कि यह पहले से ही मामला है, लेकिन समस्या यह है कि इस तरह के लंबे संपादन-डिबग चक्र के साथ विकसित करने के लिए कुछ दर्दनाक है।

— npostavs

@npostavs धन्यवाद, मुझे लगता है कि मैं पहली बार या दो मैं इसे पढ़ने से चूक गया। फिर भी ... मुझे लगता है मुझे समस्या नहीं लगती। बहुत सारी निर्भरताएं हैं, उन्हें तोड़ा नहीं जा सकता है, इसलिए एक योगदानकर्ता को उन सभी के साथ संगत रहने की आवश्यकता है। यह बड़े सॉफ्टवेयर की प्रकृति है। निश्चित रूप से निर्माण को तेज करने के लिए काम किया जा सकता है, शायद, लेकिन अन्यथा, क्या शॉर्टकट हो सकता है?

— Kyralessa