CSR टेल # 8: क्यों भयानक समीक्षा आप के लिए अच्छे हैं!

CSR टेल # 8 मिशिगन में प्रो.बार्ज़न मोज़ाफरी से आता है। बार्जान उन्नत सांख्यिकीय मॉडल का उपयोग करके स्केलेबल डेटाबेस की अगली पीढ़ी को डिजाइन करने वाले एक शोध समूह का नेतृत्व करता है। हाल ही में, उनके VATS लॉक शेड्यूलिंग एल्गोरिथ्म को MySQL और MariaDB द्वारा अपनाया गया था, इसलिए मैंने बारज़ान के साथ चैट किया कि कैसे VATS काम किया जाए। मैंने इस कहानी का उद्योग पक्ष पाने के लिए ओरेकल के उनके एक औद्योगिक सहयोगी सनी बैंस के साथ भी बातचीत की। कुल मिलाकर, यह एक महान सीएसआर टेल के लिए बनाता है! सबसे पहले, बार्जान से सुनने की सुविधा देता है:

यह 2013 की गर्मियों थी। मैंने अभी मिशिगन विश्वविद्यालय में एक कार्यकाल-ट्रैक प्रोफेसर के रूप में शुरू किया था, और मैं यह पता लगाने की कोशिश कर रहा था कि क्या काम करना है। MIT में अपने पोस्टडॉक के दौरान, मैंने कई विभिन्न परियोजनाओं में योगदान दिया, एनालिटिक्स (जैसे, ब्लिंकडीबी) से, लेनदेन और क्लाउड कंप्यूटिंग (जैसे, डीबीएसईआर) से लेकर क्राउडसोर्सिंग तक। इनमें से डीबीएसई अब तक की सबसे कठिन चुनौती थी। DBSeer के साथ लक्ष्य एक डेटाबेस सिस्टम के प्रदर्शन की भविष्यवाणी करना था (इस मामले में, MySQL) ने एक वर्कलोड दिया। लगभग दो वर्षों में मैंने पाठ्यपुस्तक में हर मशीन लर्निंग एल्गोरिदम की कोशिश की। जब हमें संसाधन उपयोग (उदाहरण, डिस्क IO या CPU) की भविष्यवाणी करने में कुछ सफलता मिली थी, तब हमारे परिणाम औसत थे जब यह लेनदेन की वास्तविक विलंबता की भविष्यवाणी करने के लिए आया था।

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

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

हमारे निष्कर्षों के डेटाबेस भाग में बहुत अधिक रोचक कहानी है। VProfiler ने अप्रत्याशितता पैदा करने के लिए दोषियों का एक समूह प्रकट किया। उदाहरण के लिए, हमारे एक निष्कर्ष यह था कि साझा संसाधनों के पीछे MySQL "कतार" में विलंबता विचरण का मुख्य कारण था। इस दृष्टिकोण में, यह बहुत सहज है: जब N लेनदेन समान साझा संसाधन के लिए एक कतार में प्रतीक्षा कर रहे हैं, तो कतार के आगे कतार के अंत में एक की तुलना में बहुत अलग प्रतीक्षा समय का अनुभव करने जा रहा है, और दोनों हैं कतार के बीच में एक से बहुत अलग होने जा रहा है। यही कारण है कि वे काम की एक ही राशि को करने के लिए बहुत अलग अक्षांशों का प्रदर्शन करते हैं।

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

बाद में, हमने लॉक शेड्यूलिंग की सामान्य समस्या तैयार की। हमने एक अलग, उपन्यास एल्गोरिथ्म का पता लगाया, जो औसत विलंबता (और बढ़ते हुए थ्रूपुट) को कम करने के लिए इष्टतम था और वीएलडीबी 2018 में प्रकाशित किया गया था ("लेन-देन डेटाबेस के लिए विरोध-अवगत लॉक शेड्यूलिंग")। हमने इस नए एल्गोरिथम को VATS 3.0 (हमने कभी भी VATS 2.0 प्रकाशित नहीं किया था) जिसे हमने बाद में CATS (कंट्रोवर्सी-अवेयर ट्रांजेक्शन पब्लिकेशन) का नाम दिया।

कंट्रोवर्सी-अवेयर ट्रांजेक्शन शेड्यूलिंग: O1 से t1 पर लॉक को ग्रांटेड करने से टी 2 देने से ज्यादा समानता (अधिक कंसंट्रेशन कम कर देता है)

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

शैक्षणिक दृष्टिकोण से, हालांकि, चीजें बहुत आसानी से नहीं हुईं। यहाँ क्या हुआ की एक समयरेखा है:

अस्वीकरण: सम्मेलन के कुछ नाम / वर्ष अलग हो सकते हैं

  • SIGMOD’16: हमने अपने MySQL परिणाम प्रस्तुत किए।
  • अस्वीकृति: "हमें कैसे पता चलेगा कि यह MySQL के अलावा किसी अन्य चीज़ के लिए काम करता है?"

टिप्पणी: दिलचस्प रूप से पर्याप्त है, आप केवल इस तरह की टिप्पणी प्राप्त करते हैं जब आप अपने विचार को एक वास्तविक प्रणाली पर लागू करते हैं। यदि आप केवल अपने विचार को खरोंच से प्रोटोटाइप करते हैं और एक मॉक-अप डेटाबेस बनाते हैं, तो आमतौर पर कोई यह नहीं पूछेगा कि क्या यह अन्य वास्तविक प्रणालियों पर लागू होता है! इन टिप्पणियों से दुखी, मेरे छात्र ने समीक्षक को गलत साबित करने का फैसला किया ...

  • VLDB'16: हमने पोस्टग्रैट्स और वोल्टबीडी के लिए VProfile को भी लागू किया।
  • अस्वीकृति: "यदि यह समस्या काफी महत्वपूर्ण थी, तो किसी और ने इसे अभी तक पूरा कर लिया होगा!"

टिप्पणी: आज तक, यह अभी भी मेरी पसंदीदा समीक्षाओं में से एक है! एक अनुचित समीक्षा प्राप्त करना कभी भी मज़ेदार नहीं है, लेकिन यह इतना हास्यास्पद था कि यह हमें परेशान नहीं करता - वास्तव में, हमने इसे काफी मनोरंजक पाया। यद्यपि हम चाहते हैं कि हमें समीक्षक से दो प्रश्न पूछने का अवसर मिले:

1) क्या समीक्षक उसी बार के खिलाफ अपने स्वयं के अनुसंधान को मापता है? (हम जानते हैं कि यह एक "वह" था; पाठ 5 देखें)

2) हम इस सिद्धांत को लागू करके अनुसंधान में उन्नति कैसे प्राप्त कर सकते हैं? यदि कुछ पहले से ही किया गया है, तो यह नया और युवा नहीं है, और अगर ऐसा नहीं किया गया है, तो यह सिर्फ महत्वपूर्ण नहीं है और उन्हें प्रकाशित करने का कोई मतलब नहीं होना चाहिए!

  • OSDI’16: फिर भी, मेरे छात्र ने समीक्षक को गलत साबित करने और समस्या को वास्तविक साबित करने के लिए एक बार फिर से निर्णय लिया। इसलिए हमने अपना एल्गोरिदम और परिणाम मारबीडीबी और मायक्यूएल दोनों को भेजे। VATS को MySQL द्वारा डिफ़ॉल्ट शेड्यूलिंग के रूप में लिया गया था और हमने इसका उल्लेख पेपर में किया था।
  • अस्वीकृति: “आपने MySQL, Postgres, और VoltDB पर VProfiler लागू किया है। हमें यह कैसे पता चलेगा कि यह DBMS के अलावा किसी और चीज के लिए काम करता है? ”

टिप्पणी: यह एक उचित चिंता थी। आखिरकार, OSDI एक OS सम्मेलन है। हम वास्तव में हमें मिली समीक्षाओं की गुणवत्ता से बहुत प्रसन्न थे। एक डीबी शोधकर्ता के रूप में, मैं हमेशा ओएस समुदाय को उनके बेहतर समीक्षा प्रणाली के लिए ईर्ष्या करता हूं।

  • SIGMOD'17: हमने VATS और अन्य डेटाबेस निष्कर्ष प्रस्तुत किए।
  • स्वीकार करना! आखिरकार!
  • EuroSys'17: हमने अपने प्रोफाइलर को सामान्यीकृत किया, जो बाद में VProfiler बन गया और डेटाबेस सिस्टम के अलावा Apache वेब सर्वर पर लागू हुआ।
  • स्वीकार करना! वाह!
  • VLDB'18: अंत में, एक बार जब हम लॉक शेड्यूलिंग समस्या को औपचारिक रूप देने में कामयाब हो जाते हैं, तो हम प्रदर्शन के लिए भी हल कर सकते हैं (केवल पूर्वानुमान नहीं)। यह CATS एल्गोरिथम बन गया।
  • स्वीकार करना। हमें वास्तव में VLDB'18 से बहुत अच्छी समीक्षाएं मिलीं। पेपर प्रकाशित होने के बाद हमें पीटर बैलीस से असाधारण प्रतिक्रिया मिली।

तो यहाँ इस लंबे पोस्ट से कुछ सबक हैं:

पाठ 1. भयानक समीक्षाएँ वास्तव में आपके लिए अच्छी हैं। वे आपको और अधिक काम करने के लिए (और आपके छात्र!) को धक्का देते हैं, जो एक बुरा परिणाम नहीं है!

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

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

पाठ 4. प्रत्येक समीक्षक गणितज्ञ नहीं होता है। हमारे पहले के सबमिशन में, हम कुल विचलन के प्रतिशत को रिपोर्ट कर रहे थे जिसे हमने समाप्त कर दिया था, जो कि लगभग 65% था। जाहिर है कि आप 100% से अधिक कुछ भी समाप्त नहीं कर सकते। दुर्भाग्य से, यह सिर्फ गणित के नियमों की एक सीमा है। लेकिन हमारी समीक्षाओं में से एक (मुझे लगता है कि SIGMOD'16 या VLDB'16) की राय थी कि 65% की कमी काफी महत्वपूर्ण नहीं है। इसलिए हमारे अगले सबमिशन में, हमने अपने संशोधित संस्करण के विचरण द्वारा विभाजित मूल MySQL के विचरण के रूप में परिभाषित सुधार अनुपात की रिपोर्टिंग करने के लिए स्विच किया। वही 65% की कमी को अब विचरण की 3x कमी के रूप में रिपोर्ट किया गया था, और समीक्षक (हालांकि शायद अलग-अलग लोग) इस बार अधिक खुश थे।

पाठ 5. अच्छा हो, या गुमनाम हो। यह हमारे पसंदीदा समीक्षक पर लागू होता है: यदि आप एक बुरा समीक्षा लिखने जा रहे हैं, तो लेखकों को अपने स्वयं के तीन पत्रों का हवाला देकर पूछना संभव नहीं है। यह आपकी गुमनामी को बनाए रखने के साथ अच्छी तरह से किराया नहीं करता है f

पाठ 6. वास्तविक प्रणालियों पर काम करना एक दर्द है, लेकिन यह पूरी तरह से इसके लायक है। यदि आप खराब समीक्षा और लंबे समय तक पेपर के साथ तैयार रहना चाहते हैं, तो असली सिस्टम पर काम करना एक बहुत ही फायदेमंद अनुभव है!

इस काम पर औद्योगिक दृष्टिकोण पर स्विच करें। मैंने ओरेकल के सनी बैंस के साथ चैट किया जो MySQL / InnoDB में VATS को अपनाने में महत्वपूर्ण भूमिका निभाई थी। मैं उनके साथ एक प्रश्नोत्तर के रूप में अपनी बातचीत प्रस्तुत करता हूं।

CSRTales: आपने सबसे पहले CATS के काम के बारे में कैसे सीखा?

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

CSRTales: जब आपने इसके बारे में सुना तो आपको CATS के बारे में क्या पसंद आया?

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

CSRTales: पहली बार सुनने से लेकर इसे मर्ज करने तक के काम में कितना समय लगा?

सनी: मुझे लगता है कि लगभग एक साल लग गया। जब से हमने इसे करने का फैसला किया है और जब तक इसे वास्तव में धकेला गया तब तक छह महीने लग गए। हमारी QA प्रक्रिया बहुत कठोर है और मैं हमारे QA को पर्याप्त रूप से धन्यवाद नहीं दे सकता। मूल पैच में कुछ कीड़े थे। हमने इसे फिर से लिखने का फैसला किया। हम नीति के रूप में कॉन्फ़िगरेशन चर की संख्या को भी कम करना चाहते हैं। गैप लॉक के साथ कुछ मुद्दे थे जिन्हें पैच में तय किया जाना था।

CSRTales: आमतौर पर, लिनक्स कर्नेल जैसे ओपन-सोर्स समुदायों में, आपके पैच स्वीकार किए जाने से पहले ही आपके पास विश्वसनीयता होनी चाहिए। मैं यहाँ कुछ ऐसा ही अनुमान लगा रहा हूँ?

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

CSRTales: योगदान वाले पैच को फिर से लिखना आम बात है?

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

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