Temurin-build: प्रस्ताव: जहां व्यावहारिक हो पीआर प्रवर्तकों को अपने स्वयं के पीआर का विलय करने दें

@sxa इस बदलाव से पूरी तरह खुश है, मैं एक बॉट का सुझाव ready-to-merge जोड़ता है और लेखक को पिंग करता है

अनुमोदन और बॉट सुझाव दोनों के लिए @gdams ने मेरे मुंह से शब्द निकाले। इसके लिए मेरी ओर से +1

सहमत - हमारे TZ के साथ भी समझ में आता है।

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

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

मुझे अधिक शोर नहीं चाहिए (GitHub पहले से ही मुझे स्वीकृतियों के बारे में सूचित करता है)

इससे आप किस अतिरिक्त शोर की उम्मीद कर रहे हैं? क्या यह टैग जोड़ने वाले बॉट के संबंध में है या आप कुछ और सोच रहे हैं?

अगर मैं जिम्मेदार हूं कि सब कुछ सुचारू रूप से चलता है, तो मुझे समय आरक्षित रखना होगा और शायद घंटों इंतजार करना होगा

मुझे वह मिलता है, लेकिन मेरा काउंटर पॉइंट यह है कि यह मेरे द्वारा डिबग करने के लिए खर्च किए गए घंटे की तुलना में बहुत बेहतर विकल्प है कि अचानक कुछ गलत क्यों हो जाता है, जो एक लगातार समस्या है जो मैं और @-एंड्रयू-एम-लियोनार्ड अपरिहार्य अंत से निपट रहा हूं , यही कारण है कि मैं वास्तव में नहीं सोचता कि लेखक को सक्रिय रूप से यह निर्णय लेना चाहिए - मुझे यकीन है कि कई लेखक अपने पीआर से किसी भी नतीजे से निपटने के बजाय किसी और से निपटेंगे :-)

इसके अलावा, हमें इसे लागू करने के लिए टूलिंग की आवश्यकता है

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

हम कैसे जानते हैं कि किस भंडार में वह नियम है और कौन सा नहीं है?

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

मेरा मानना ​​​​है कि, यह मुद्दा कम से कम उस मामले को संबोधित करने का प्रयास है जहां समीक्षकों ने उत्प्रेरक की टिप्पणियों या अनुरोधों को अच्छी तरह से नहीं पढ़ा है ("कृपया xxxx सत्यापित होने तक प्रतीक्षा करें ...", "इस परिवर्तन को सह होने की आवश्यकता है -x और y परिवर्तनों के साथ समन्वयित...", "मैं विशेष रूप से Z से इस परिवर्तन की समीक्षा करने के लिए कह रहा हूं...")। जब इन अनुरोधों को समीक्षकों द्वारा अनदेखा कर दिया जाता है जो फिर विलय करने के लिए आगे बढ़ते हैं, तो यह अच्छी बात नहीं है।

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

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

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

@sxa की टिप्पणियों के संबंध में:

इससे आप किस अतिरिक्त शोर की उम्मीद कर रहे हैं? क्या यह टैग जोड़ने वाले बॉट के संबंध में है या आप कुछ और सोच रहे हैं?

जॉर्ज और मॉर्गन एक बॉट चाहते हैं जो लेखक को पिंग करता है।

मुझे वह मिलता है, लेकिन मेरा काउंटर पॉइंट यह है कि यह उस घंटे की तुलना में एक बेहतर विकल्प है जिसे मैंने डिबग करने की कोशिश में खर्च किया है कि अचानक कुछ गलत क्यों है

यह अच्छा नहीं है। लेकिन यहां दिया गया समाधान भी भयानक है। हमारे पास पहले से ही एक योगदानकर्ता समस्या है और अब हम इसे उसी तरह से बदतर बनाना चाहते हैं जैसे ओपनजेडीके ने योगदान करने में और अधिक कठिन बनाकर किया था (स्कारा इसके कुछ हिस्सों को पूर्ववत करने का प्रयास कर रहा है)। आपके द्वारा वर्णित समस्या openjdk-build के भयानक आकार में होने के कारण होती है। और हम इसके ऊपर पीआर को ढेर कर देते हैं जो तैयार नहीं होते हैं। और वे तैयार नहीं हैं क्योंकि हम योगदानकर्ताओं के लिए यह अनुमान लगाना असंभव बना देते हैं कि उनके पीआर अच्छे आकार में हैं या नहीं। मैं यहां नया नहीं हूं और शायद ही कभी इसे ठीक कर पाता हूं।

इसका शीर्षक कहता है "पीआर प्रवर्तकों को दें" यानी मैं समीक्षकों को प्रोत्साहित करना चाहता हूं कि वे किसी चीज़ पर त्वरित नज़र डालने के बाद "डिफ़ॉल्ट रूप से विलय" न करें।

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

मैं इस बारे में उत्सुक हूं कि आपको क्यों लगता है कि यह नए योगदानकर्ताओं को हतोत्साहित कर सकता है?

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

@smlambert की टिप्पणी के संबंध में:

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

लेकिन: यह मुश्किल है। हमें मैन्युअल रूप से चेकलिस्ट (खराब उदाहरण: 8u-dev और 11u-dev) के माध्यम से जाने के बिना लोगों को सही काम करने में मदद करनी चाहिए। स्कारा बॉट सही दिशा में जा रहा है, हालांकि यह बहुत शोर है।

मुझे टूलिंग द्वारा समर्थित स्व-मर्ज लेबल विचार पसंद है जो इसे लागू करता है। मुझे विशेष रूप से यह पसंद है कि हम विभिन्न तरीकों पर चर्चा कर रहे हैं जिन्हें हम एक परियोजना और वैश्विक टीम के रूप में सुधारना चाहते हैं। 👍

जॉर्ज और मॉर्गन एक बॉट चाहते हैं जो लेखक को पिंग करता है।

यह पहले से मौजूद है । मैं बस इसे और अधिक उपयोगी जानकारी के साथ विस्तारित करने का सुझाव देता हूं (कृपया परीक्षण चलाने के लिए किसी को पिंग करें)। https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59 शोर को और अधिक उपयोगी बनाकर ऐसा करने का इरादा रखता है। यह आपके द्वारा उठाए गए बेबीसिटिंग पॉइंट में भी मदद कर सकता है

मैं बस इसे और अधिक उपयोगी जानकारी के साथ विस्तारित करने का सुझाव देता हूं (कृपया परीक्षण चलाने के लिए किसी को पिंग करें)।

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

छोटा साइड नोट फिर से: https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59। एक नवागंतुक खुद विचारों के साथ आने में सक्षम होने की संभावना नहीं है। उन्हें एक स्पष्ट उद्देश्य और चरण-दर-चरण मार्गदर्शिका की आवश्यकता है कि क्या करना है ("उस एपीआई से जानकारी प्राप्त करें, इसे प्रदर्शित करें, ...")। जैसा कि यह खड़ा है, टिकट एक अनुभवी 😉 के लिए है

क्या हम इस उद्देश्य के लिए "ड्राफ़्ट" का उपयोग कर सकते हैं, अर्थात। हम यह सुनिश्चित करना चाहते हैं कि यह विलय के लिए तैयार है, इसलिए उस बिंदु तक यह मसौदा है ...

क्या हम इस उद्देश्य के लिए "ड्राफ़्ट" का उपयोग कर सकते हैं, अर्थात। हम यह सुनिश्चित करना चाहते हैं कि यह विलय के लिए तैयार है, इसलिए उस बिंदु तक यह मसौदा है ...

इसके साथ मेरी समस्या मूल विवरण में बताई गई है: "[ड्राफ्ट] उन लोगों को "समीक्षा के लिए तैयार नहीं" जैसा लग सकता है जो अन्यथा समीक्षा कर सकते हैं। मुझे लगता है कि मसौदे के बीच एक महत्वपूर्ण अंतर है (मैं अभी भी सक्रिय रूप से सामान बदल रहा हूं) और समीक्षा के लिए तैयार हूं (प्रतिक्रिया की तलाश है लेकिन इसका मतलब यह नहीं है कि मुझे पूरा विश्वास है कि विलय होने पर यह काम करेगा)

(इसे बहुत जल्दी लिख रहा हूं क्योंकि मुझे अभी एक बैठक में शामिल होना है - यदि दृष्टिकोण स्पष्ट नहीं है तो क्षमा करें)

लेकिन यहां दिया गया समाधान भी भयानक है।
योगदान करना अधिक कठिन बना रहा है

मुझे लगता है कि इसे "भयानक" कहना थोड़ा कठोर है। इसका उद्देश्य एक ऐसी समस्या का समाधान करना है जिसे मैं इस समय नियमित रूप से देखता हूं।

इसलिए डिफ़ॉल्ट रूप से यह मेरे पीआर को परियोजना में लाने के लिए समीक्षक का काम होना चाहिए क्योंकि तब "यह मैं नहीं था"।

यह निश्चित रूप से समीक्षकों का काम होना चाहिए कि वे योगदान को प्रोत्साहित करें और उन्हें किसी भी मुद्दे को ठीक करने में मदद करें, और नए के मामले में (कुछ तोड़ने के विचार से भयभीत, भयभीत पढ़ें) योगदानकर्ता यह कुछ भी नहीं बदलेगा (वे खुद को विलय नहीं कर सकते हैं) आखिरकार) इसलिए मैं स्पष्ट नहीं हूं कि चिंता क्या है। अतिरिक्त लेबल जोड़ना (या तो self-merge या ready-to-merge व्यक्तिगत रूप से मेरे लिए एक अतिरिक्त ओवरहेड लगता है, लेकिन अगर लोग यही चाहते हैं तो मैं उनके साथ ठीक रहूंगा। मैं बस नहीं चाहता ऐसी स्थिति में जारी रखें जहां पीआर प्रवर्तकों के पास विलय के बाद कोई जिम्मेदारी नहीं है (विशेष रूप से वर्तमान समूह के सदस्यों के भीतर - मैं ठीक हूं यदि किसी नए योगदानकर्ता को उनके द्वारा डाली गई किसी समस्या का सामना करना पड़ता है - उस स्थिति में समीक्षक को उम्मीद करनी चाहिए अगर यह अंदर जाता है और विफल रहता है तो उन्हें डीबग करने में सहायता करें - यह सीखने के अनुभव का हिस्सा है और बिना किसी परवाह के होगा)

अगर मैं कहीं नया हूं तो मैं चाहता हूं कि कोई मेरे योगदान के माध्यम से मेरा पालन-पोषण करे।

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

मुझे लगता है कि इसे "भयानक" कहना थोड़ा कठोर है। इसका उद्देश्य एक ऐसी समस्या का समाधान करना है जिसे मैं इस समय नियमित रूप से देखता हूं।

आपने मेरे माथे पर यह लेबल नहीं देखा है जिसमें लिखा है "मजबूत राय से सावधान रहें"? मुस्कराहट:

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

हमें कम समस्याएं चाहिए, ज्यादा नहीं। जैसे ही हम एक त्वरित जीत के साथ दर्द को दूर करते हैं, हमारे पास यह भूलने की प्रवृत्ति होती है कि यह अस्तित्व में भी है। उदाहरण: 2d9445348c70ec565874fb92f4c09971f71a5d23 के साथ, macOS पर पीआर परीक्षण को टिप्पणी करके अक्षम कर दिया गया था। a82104c77a79d707d533415163cf00dac33678d4 के साथ, हमने उस हिस्से को खो दिया जिस पर टिप्पणी की गई थी। अब कौन याद करता है कि हमारे पास macOS PR परीक्षण था, कि इसे अक्षम कर दिया गया था और हमें इसे वापस लाना चाहिए? इसमें कोई मसला भी नहीं है।

टीएससी को उन मुद्दों पर ध्यान केंद्रित करना चाहिए जैसे लॉर्ड ऑफ द रिंग्स में सौरोन की आंख।

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

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

आपने मेरे माथे पर यह लेबल नहीं देखा है जिसमें लिखा है "मजबूत राय से सावधान रहें"? मुसकान

याद किया लेकिन तब मैंने हाल ही में आपके साथ एक वीडियो कॉल नहीं किया था ;-) मैकोस पीआर परीक्षक पर अच्छा उदाहरण हालांकि ...

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

मुझे उम्मीद है कि इस परियोजना में ऐसा नहीं होगा और अगर ऐसा होता है तो मुझे उम्मीद है कि हम इसे संभाल सकते हैं। मैं अभी भी व्यक्तिगत रूप से इस पर जोखिम लेने को तैयार हूं। अभी के लिए, इतनी छोटी टीम के साथ (जो समस्या का हिस्सा है ... और ओपनजेडके के लिए कोई समस्या नहीं है) मुझे लगता है कि अनुमोदनकर्ता (यह बहुत ज्यादा है @karianna @andrew-m-leonard @ M-Davies और खुद जो उन्हें इस रेपो के लिए करते हैं) सभी जानते हैं कि कौन चीजों को विलय करने में सक्षम है और कौन ऐसा नहीं है, मुझे उम्मीद है कि वे अंधेरे में गैर-कम्यूटर्स नहीं छोड़ेंगे और बहुत अधिक ओवरहेड नहीं होगा। मुझे खुशी होगी अगर हम टीम को उस बिंदु तक ले जाने में सक्षम थे जहां इस नीति की अब आवश्यकता नहीं थी। मुझे सच में लगता है कि यह कोशिश करने लायक है और अगर हमें ऐसी समस्याएं दिखाई देती हैं तो हम फिर से जा सकते हैं। मैं सिर्फ "कुछ नहीं करना चाहता"