यह गाइड, Bazel ओपन सोर्स प्रोजेक्ट के रखरखाव करने वालों के लिए है.
अगर आपको Bazel में योगदान देना है, तो कृपया Bazel में योगदान देना लेख पढ़ें.
इस पेज का मकसद ये है:
- प्रोजेक्ट में योगदान करने की प्रोसेस के बारे में, रखरखाव करने वालों के लिए भरोसेमंद सोर्स के तौर पर काम करना.
- कम्यूनिटी में योगदान देने वाले लोगों और प्रोजेक्ट को मैनेज करने वाले लोगों के बीच उम्मीदें तय करें.
Bazel के योगदान देने वाले मुख्य ग्रुप में, ओपन सोर्स प्रोजेक्ट के पहलुओं को मैनेज करने के लिए सबटीम बनाई गई हैं. इनके उदाहरण हैं:
- रिलीज़ प्रोसेस: Bazel की रिलीज़ प्रोसेस को मैनेज करें.
- ग्रीन टीम: नियमों और टूल का एक बेहतर नेटवर्क तैयार करना.
- डेवलपर एक्सपीरियंस गार्डनर: ये बाहरी योगदान को बढ़ावा देते हैं. साथ ही, समस्याओं और पुल अनुरोधों की समीक्षा करते हैं. इसके अलावा, ये हमारे डेवलपमेंट वर्कफ़्लो को ज़्यादा ओपन बनाते हैं.
रिलीज़
लगातार इंटिग्रेशन
Bazel के सीआई इन्फ़्रास्ट्रक्चर के बारे में जानने के लिए, Green टीम की गाइड पढ़ें. यह गाइड bazelbuild/continuous-integration रिपॉज़िटरी पर उपलब्ध है.
किसी समस्या की लाइफ़साइकल
- कोई उपयोगकर्ता समस्या का टेंप्लेट का इस्तेमाल करके कोई समस्या बनाता है. इसके बाद, यह बिना समीक्षा की गई खुली समस्याओं के पूल में शामिल हो जाती है.
- डेवलपर एक्सपीरिएंस (DevEx) सबटीम रोटेशन का कोई सदस्य, समस्या की समीक्षा करता है.
- अगर समस्या बग नहीं है या सुविधा के लिए अनुरोध नहीं है, तो DevEx टीम का सदस्य आम तौर पर समस्या को बंद कर देगा. साथ ही, उपयोगकर्ता को StackOverflow और bazel-discuss पर रीडायरेक्ट कर देगा, ताकि सवाल ज़्यादा लोगों को दिख सके.
- अगर समस्या, कम्यूनिटी के मालिकाना हक वाली किसी नियम रिपॉज़िटरी से जुड़ी है, जैसे कि rules_apple, तो DevEx टीम का सदस्य इस समस्या को सही रिपॉज़िटरी में ट्रांसफ़र कर देगा.
- अगर समस्या के बारे में साफ़ तौर पर नहीं बताया गया है या उसमें ज़रूरी जानकारी नहीं दी गई है, तो DevEx टीम का सदस्य, समस्या को वापस उपयोगकर्ता को असाइन कर देगा. ऐसा इसलिए किया जाएगा, ताकि वह समस्या के बारे में ज़्यादा जानकारी दे सके. इसके बाद ही, समस्या को हल करने की प्रोसेस आगे बढ़ाई जाएगी. आम तौर पर, ऐसा तब होता है, जब उपयोगकर्ता समस्या की जानकारी देने वाले टेंप्लेट का पालन नहीं करता.
- समस्या की समीक्षा करने के बाद, DevEx टीम का सदस्य यह तय करता है कि समस्या पर तुरंत ध्यान देने की ज़रूरत है या नहीं. अगर ऐसा होता है, तो वे P0 priority लेबल असाइन करेंगे. साथ ही, टीम लीड की सूची से किसी व्यक्ति को मालिक के तौर पर असाइन करेंगे.
- DevEx टीम का सदस्य, रूटिंग के लिए
untriaged
लेबल और सिर्फ़ एक टीम लेबल असाइन करता है. - DevEx टीम का सदस्य, समस्या के टाइप के हिसाब से सिर्फ़ एक
type:
लेबल असाइन करता है. जैसे,type: bug
याtype: feature request
. - किसी प्लैटफ़ॉर्म से जुड़ी समस्याओं के लिए, DevEx टीम का सदस्य एक
platform:
लेबल असाइन करता है. जैसे, Mac से जुड़ी समस्याओं के लिएplatform:apple
. इस चरण में, समस्या बिना किसी प्राथमिकता के ओपन की गई समस्याओं के पूल में शामिल हो जाती है.
Bazel की हर सबटीम, उन सभी समस्याओं को प्राथमिकता देगी जिनके लेबल उसके पास हैं. ऐसा हर हफ़्ते किया जाना चाहिए. उप-टीम समस्या की समीक्षा और उसका आकलन करेगी. साथ ही, अगर संभव हो, तो समस्या का समाधान करेगी. अगर आपके पास टीम लेबल का मालिकाना हक है, तो ज़्यादा जानकारी के लिए यह सेक्शन देखें.
समस्या हल हो जाने पर, उसे बंद किया जा सकता है.
पुल के अनुरोध की लाइफ़साइकल
- कोई उपयोगकर्ता पुल का अनुरोध बनाता है.
- अगर आप Bazel टीम के सदस्य हैं और अपने क्षेत्र के लिए पीआर भेज रहे हैं, तो आपको अपनी टीम का लेबल असाइन करना होगा और सबसे अच्छे समीक्षक को ढूंढना होगा.
- अगर ऐसा नहीं होता है, तो हर दिन की जाने वाली समीक्षा के दौरान, DevEx टीम का कोई सदस्य एक टीम लेबल असाइन करता है. साथ ही, समस्या को सही टीम को भेजने के लिए, टीम के टेक्निकल लीड (टीएल) को असाइन करता है.
- टीएल के पास यह विकल्प होता है कि वह पीआर की समीक्षा करने के लिए किसी और व्यक्ति को असाइन करे.
- समीक्षा करने के लिए असाइन किया गया व्यक्ति, पीआर की समीक्षा करता है. साथ ही, वह लेखक के साथ तब तक काम करता है, जब तक पीआर को मंज़ूरी नहीं मिल जाती या उसे हटा नहीं दिया जाता.
- अगर पीआर को मंज़ूरी मिल जाती है, तो समीक्षक, Google के इंटरनल वर्शन कंट्रोल सिस्टम में पीआर के कमिट इंपोर्ट करता है, ताकि आगे और टेस्ट किए जा सकें. Bazel, Google में इस्तेमाल किया जाने वाला एक ही बिल्ड सिस्टम है. इसलिए, हमें सभी पीआर कमिट को इंटरनल टेस्ट सुइट के ख़िलाफ़ टेस्ट करना होगा. इस वजह से, हम पीआर को सीधे तौर पर मर्ज नहीं करते हैं.
- अगर इंपोर्ट की गई कमिट, सभी इंटरनल टेस्ट पास कर लेती है, तो कमिट को स्क्वैश कर दिया जाएगा. इसके बाद, इसे वापस GitHub पर एक्सपोर्ट कर दिया जाएगा.
- जब कमिट को मास्टर में मर्ज किया जाता है, तो GitHub पीआर को अपने-आप बंद कर देता है.
मेरी टीम के पास एक लेबल है. मुझे क्या करना चाहिए?
उप-टीमों को, अपने लेबल से जुड़ी सभी समस्याओं को प्राथमिकता के हिसाब से हल करना होगा. बेहतर होगा कि वे ऐसा हर हफ़्ते करें.
समस्याएं
- अपनी टीम के लेबल और
untriaged
लेबल के हिसाब से, समस्याओं की सूची को फ़िल्टर करें. - समस्या की समीक्षा करें.
- प्राथमिकता का लेवल तय करें और लेबल असाइन करें.
- अगर समस्या P0 है, तो हो सकता है कि DevEx की उप-टीम ने पहले ही इसे प्राथमिकता दे दी हो. अगर ज़रूरी हो, तो प्राथमिकताएं बदलें.
- हर समस्या के लिए, सिर्फ़ एक प्राथमिकता का लेबल होना चाहिए. अगर कोई समस्या P0 या P1 है, तो हम मान लेते हैं कि उस पर काम किया जा रहा है.
untriaged
लेबल हटाएं.
ध्यान दें कि लेबल जोड़ने या हटाने के लिए, आपको bazelbuild संगठन में शामिल होना होगा.
पुल के अनुरोध
- अपनी टीम के लेबल के हिसाब से, पुल अनुरोधों की सूची को फ़िल्टर करें.
- पुल के खुले अनुरोधों की समीक्षा करें.
- ज़रूरी नहीं: अगर आपको समीक्षा करने के लिए असाइन किया गया है, लेकिन यह आपके लिए सही नहीं है, तो कोड की समीक्षा करने के लिए, सही समीक्षक को फिर से असाइन करें.
- कोड की समीक्षा पूरी करने के लिए, पुल का अनुरोध बनाने वाले व्यक्ति के साथ मिलकर काम करें.
- पीआर को मंज़ूरी दें.
- पक्का करें कि सभी टेस्ट पास हो गए हों.
- पैच को इंटरनल वर्शन कंट्रोल सिस्टम में इंपोर्ट करें और इंटरनल प्रीसबमिट चलाएं.
- इंटरनल पैच सबमिट करें. अगर पैच सबमिट और एक्सपोर्ट हो जाता है, तो GitHub पीआर को अपने-आप बंद कर देगा.
प्राथमिकता
प्राथमिकता की इन परिभाषाओं का इस्तेमाल, रखरखाव करने वाले लोग समस्याओं को प्राथमिकता के हिसाब से व्यवस्थित करने के लिए करेंगे.
- P0 - मुख्य फ़ंक्शन काम नहीं कर रहा है. इसकी वजह से, Bazel के रिलीज़ कैंडिडेट के अलावा अन्य रिलीज़ का इस्तेमाल नहीं किया जा सकता. इसके अलावा, यह ऐसी सेवा है जो Bazel प्रोजेक्ट के डेवलपमेंट पर गंभीर असर डालती है. इसमें नई रिलीज़ में हुई ऐसी गड़बड़ियां शामिल हैं जिनकी वजह से, बड़ी संख्या में उपयोगकर्ता ऐप्लिकेशन का इस्तेमाल नहीं कर पा रहे हैं. इसके अलावा, इसमें ऐसा बदलाव भी शामिल है जो ऐप्लिकेशन के साथ काम नहीं करता और ऐप्लिकेशन के साथ काम न करने वाले बदलाव की नीति का पालन नहीं करता. इस समस्या को ठीक करने का कोई तरीका नहीं है.
- P1 - गंभीर गड़बड़ी या ऐसी सुविधा जिसे अगली रिलीज़ में ठीक किया जाना चाहिए. इसके अलावा, ऐसी गंभीर समस्या जिसका असर कई लोगों पर पड़ता है. इसमें Bazel प्रोजेक्ट का डेवलपमेंट भी शामिल है. हालांकि, इस समस्या को हल करने का कोई तरीका मौजूद है. आम तौर पर, इसके लिए तुरंत कार्रवाई करने की ज़रूरत नहीं होती. इसकी बहुत ज़्यादा मांग है और इसे चालू तिमाही के रोडमैप में शामिल किया गया है.
- P2 - ऐसा डिफ़ेक्ट या सुविधा जिस पर काम किया जाना चाहिए, लेकिन फ़िलहाल हम इस पर काम नहीं कर रहे हैं. Bazel के रिलीज़ किए गए वर्शन में लाइव समस्या जो किसी ऐसे उपयोगकर्ता के लिए असुविधाजनक है जिसे आने वाली रिलीज़ में ठीक किया जाना चाहिए और/या समस्या को हल करने का आसान तरीका मौजूद है.
- P3 - छोटी गड़बड़ी को ठीक करना या सुधार करना. इससे बहुत कम असर पड़ता है. इसे Bazel के रोडमैप या आने वाली किसी भी रिलीज़ में प्राथमिकता नहीं दी गई है. हालांकि, समुदाय के योगदान का स्वागत है.
- P4 - कम प्राथमिकता वाला ऐसा डिफ़ेक्ट या सुविधा का अनुरोध जिसे शायद ही कभी बंद किया जाता है. अगर ज़्यादा उपयोगकर्ताओं पर असर पड़ता है, तो इसे फिर से प्राथमिकता देने के लिए भी खुला रखा जा सकता है.
- आइस-बॉक्स
- ऐसी समस्याएं जिन्हें ठीक करने के लिए, फ़िलहाल हमारे पास समय नहीं है. साथ ही, हम योगदान स्वीकार नहीं कर सकते. हम इन समस्याओं को बंद कर देंगे, ताकि यह पता चल सके कि इन पर कोई काम नहीं कर रहा है. हालांकि, हम समय-समय पर इनकी पुष्टि करते रहेंगे. अगर ज़्यादा लोगों पर इनका असर पड़ता है और हमारे पास इन्हें ठीक करने के लिए संसाधन उपलब्ध होते हैं, तो हम इन्हें फिर से चालू कर देंगे. हमेशा की तरह, इन समस्याओं के बंद होने के बाद भी, बेझिझक टिप्पणी करें या अपनी प्रतिक्रियाएं दें.
टीम के लेबल
team-Android
: Android टीम के लिए समस्याएं- संपर्क करें: ahumesky
team-Bazel
: Bazel के प्रॉडक्ट/रणनीति से जुड़ी सामान्य समस्याएं- संपर्क करें: sventiffe
team-Build-Language
: BUILD, .bzl एपीआई, और Stardoc से जुड़ी समस्याएं.- संपर्क करें: brandjon
team-Configurability
: कॉन्फ़िगरेशन से जुड़ी टीम के लिए समस्याएं- संपर्क करें: gregestren
team-Core
: कोर टीम के लिए समस्याएं- संपर्क करें: haxorz
team-Documentation
: दस्तावेज़ बनाने वाली टीम के लिए समस्याएं- संपर्क करें: communikit
team-ExternalDeps
: बाहरी डिपेंडेंसी को मैनेज करना, Bzlmod, रिमोट रिपॉज़िटरी, WORKSPACE फ़ाइल- संपर्क करें: meteorcloudy
team-Local-Exec
: लोकल टीम के लिए समस्याएं- संपर्क करें: meisterT
team-OSS
: Bazel OSS टीम के लिए समस्याएं: इंस्टॉलेशन, रिलीज़ प्रोसेस, Bazel पैकेजिंग, वेबसाइट, दस्तावेज़ों का इन्फ़्रास्ट्रक्चर- संपर्क करें: meteorcloudy
team-Performance
: Bazel की परफ़ॉर्मेंस टीम के लिए समस्याएं- संपर्क करें: meisterT
team-Remote-Exec
: Execution (Remote) टीम के लिए समस्याएं- संपर्क करें: coeuvre
team-Rules-CPP
: C++ के नियमों से जुड़ी समस्याएं. इनमें Apple के नेटिव नियम का लॉजिक भी शामिल है- संपर्क करें: oquenchil
team-Rules-Java
: Java के नियमों से जुड़ी समस्याएं- संपर्क करें: comius
team-Rules-Python
: नेटिव Python नियमों से जुड़ी समस्याएं- संपर्क करें: comius
team-Rules-Server
: Bazel के साथ शामिल सर्वर-साइड नियमों से जुड़ी समस्याएं- संपर्क करें: comius
team-Starlark-integration
: नॉन-एपीआई Bazel + Starlark इंटिग्रेशन. इसमें ये शामिल हैं: Bazel, Starlark इंटरप्रेटर, Stardoc, बिल्ट-इन इंजेक्शन, और वर्ण एन्कोडिंग को कैसे ट्रिगर करता है. इसमें BUILD या .bzl फ़ाइलों से जुड़ी भाषा की समस्याएं शामिल नहीं हैं.- संपर्क करें: brandjon
team-Starlark-interpreter
: Starlark इंटरप्रेटर से जुड़ी समस्याएं (java.net.starlark में मौजूद कोई भी समस्या). BUILD और .bzl एपीआई से जुड़ी समस्याएं (जो Starlark के साथ Bazel के इंटिग्रेशन को दिखाती हैं)team-Build-Language
में जाती हैं.- संपर्क करें: brandjon
नई समस्याओं के लिए, हमने category: *
लेबल को हटा दिया है. अब टीम के लेबल का इस्तेमाल किया जाएगा.
लेबल की पूरी सूची यहां देखें.