PostgreSQL
 sql >> डेटाबेस >  >> RDS >> PostgreSQL

PostgreSQL कमिटफेस्ट का प्रबंधन

यदि आप पिछले कुछ वर्षों से PostgreSQL विकास का अनुसरण कर रहे हैं, तो आपने शायद commitfest Manager शब्द सुना होगा कभी कभी। आप शायद पहले से ही जानते हैं कि कमिटफेस्ट क्या है, लेकिन एक प्रबंधक क्यों है? चूंकि मैंने पिछले जनवरी में एक का प्रबंधन करने में काफी समय बिताया है, इसलिए मैं समझाता हूं।

कमिटफ़ेस्ट के दौरान पैच लागू किया गया

इसके मूल में, PostgreSQL कमिटफेस्ट केवल पैच का एक संग्रह है जो PostgreSQL कोड बेस में एकीकरण की प्रतीक्षा कर रहा है। कमिटफेस्ट का कार्य सिद्धांत यह है कि प्रत्येक पैच जिसे pgsql-hackers को भेजा गया है समय पर समीक्षा की जानी चाहिए; एक बार समीक्षा करने और पर्याप्त बार संशोधित करने के बाद, पैच एक कमिटर द्वारा PostgreSQL में स्थायी समावेश के लिए उम्मीदवार है।

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

अब तक बहुत अच्छा।

हमें प्रबंधक की आवश्यकता क्यों है?

कमिटफ़ेस्ट प्रबंधित करना

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

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

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

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

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

दूसरी ओर, पैच लेखक कभी-कभी अपने पैच को बिना अपडेट के रहने के लिए छोड़ देते हैं। एक संभावित उत्तर उन्हें "प्रतिक्रिया के साथ लौटा" बस बंद करना है, लेकिन अधिकांश समय यह एक लेखक को एक अद्यतन संस्करण सबमिट करने के लिए प्रेरित करने लायक है।

कमिटफेस्ट मैनेजर खुद की समीक्षा करने में भी काफी समय बिता सकते हैं, और अगर उनके पास कुछ विशेषाधिकार हैं, तो वे पैच कर सकते हैं।

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

जनवरी 2016 का कमिटफ़ेस्ट

यह चार्ट जनवरी 2016 के कमिटफेस्ट को दिखाता है। डेटा मेरे द्वारा भेजे गए साप्ताहिक स्थिति ईमेल से है:प्रारंभ, सप्ताह 1, सप्ताह 2, सप्ताह 3, सप्ताह 4, समापन।

आप देख सकते हैं कि हमने "समीक्षा की आवश्यकता है" या "कमिटर के लिए तैयार" स्थिति में 85 के साथ शुरुआत की, जिसका अर्थ है कि वे लेखक के अलावा किसी और के कार्य करने की प्रतीक्षा कर रहे थे। एक हफ्ते बाद हम उन स्थितियों पर 71 पैच तक कम हो गए:इसका मतलब है कि एक सप्ताह में 14 पैच संसाधित किए गए, जो कि बुरा नहीं है, क्योंकि अगर यह जारी रहता है, तो उस दर का मतलब है कि पूरी पैच कतार केवल 5 और हफ्तों में खत्म हो जाएगी।

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

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

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

भविष्य के कमिटफेस्ट प्रबंधकों को सलाह

मुझे लगता है कि साप्ताहिक स्थिति अपडेट होने से अच्छे परिणाम मिलते हैं:यह सभी को यह आभास देता है कि कुछ हो रहा है (जो कि यह है), समीक्षकों और कमिटर्स दोनों को अपना काम करने के लिए प्रेरित करता है।

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

कमिटफेस्ट को कैसे प्रबंधित किया गया, इस बारे में आपकी कोई राय की सराहना की जाएगी; कृपया मुझे ईमेल करें यदि आप इसे टिप्पणी के रूप में सार्वजनिक रूप से पोस्ट नहीं करना चाहते हैं। अगर आपको लगता है कि मेरे द्वारा की गई चीजें अप्रभावी थीं, या यदि आपके पास अन्य विचार हैं कि क्या करना है, तो मैं सुनने को तैयार हूं। मैं भविष्य में अन्य प्रतिबद्धताओं का प्रबंधन कर सकता हूं, संसाधनों की अनुमति है।

अंत में, आगामी मार्च 2016 के कमिटफेस्ट के लिए खुद को तैयार करें। यह 9.6 के लिए अंतिम कमिटफेस्ट होने जा रहा है और मुझे यकीन है कि सभी के लिए करने के लिए बहुत कुछ होगा। हैप्पी पैच समीक्षा!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. PostgreSQL में एक यूनिक्स टाइमस्टैम्प को दिनांक/समय मान में कैसे बदलें

  2. PostgreSQL डेटाबेस में सभी ट्रिगर्स को सूचीबद्ध करने के 2 तरीके

  3. psql क्वेरी परिणाम में टेबल बॉर्डर स्टाइल को कैसे बदलें

  4. एक ताजा रेल परियोजना में SQLite से PostgreSQL में बदलें

  5. त्रुटि:डोकर में अल्पाइन पर psycopg2 स्थापित करते समय pg_config निष्पादन योग्य नहीं मिला