Bazel का रखरखाव करने वालों के लिए गाइड

यह Bazel ओपन सोर्स प्रोजेक्ट के रखरखाव करने वालों के लिए एक गाइड है.

अगर आपको Bazel में योगदान देना है, तो कृपया Bazel में योगदान देना लेख पढ़ें.

इस पेज का मकसद ये है:

1. प्रोजेक्ट में योगदान करने की प्रोसेस के बारे में, रखरखाव करने वालों के लिए भरोसेमंद सोर्स के तौर पर काम करना.
2. कम्यूनिटी में योगदान देने वाले लोगों और प्रोजेक्ट को मैनेज करने वाले लोगों के बीच उम्मीदें तय करें.

Bazel के योगदान देने वाले मुख्य ग्रुप में, ओपन सोर्स प्रोजेक्ट के पहलुओं को मैनेज करने के लिए सबटीम बनाई गई हैं. इनके उदाहरण हैं:

• रिलीज़ प्रोसेस: Bazel की रिलीज़ प्रोसेस को मैनेज करें.
• ग्रीन टीम: नियमों और टूल का एक बेहतर नेटवर्क तैयार करना.
• डेवलपर एक्सपीरियंस गार्डनर: बाहरी योगदान को बढ़ावा देना, समस्याओं और पुल अनुरोधों की समीक्षा करना, और डेवलपमेंट के हमारे वर्कफ़्लो को ज़्यादा ओपन बनाना.

रिलीज़

• रिलीज़ प्लेबुक
• डाउनस्ट्रीम प्रोजेक्ट में लोकल बदलावों की जांच करना

लगातार इंटिग्रेशन करना

Bazel के सीआई इन्फ़्रास्ट्रक्चर के बारे में Green टीम की गाइड पढ़ें. यह गाइड, bazelbuild/continuous-integration रिपॉज़िटरी पर उपलब्ध है.

किसी समस्या की लाइफ़साइकल

1. कोई उपयोगकर्ता, समस्या का टेंप्लेट का इस्तेमाल करके कोई समस्या बनाता है. इसके बाद, यह समीक्षा न की गई खुली समस्याओं के पूल में शामिल हो जाती है.
2. डेवलपर एक्सपीरिएंस (DevEx) सबटीम रोटेशन का कोई सदस्य, समस्या की समीक्षा करता है.
   1. अगर समस्या बग नहीं है या सुविधा के लिए अनुरोध है, तो DevEx टीम का सदस्य आम तौर पर समस्या को बंद कर देता है और उपयोगकर्ता को StackOverflow और bazel-discuss पर रीडायरेक्ट कर देता है, ताकि सवाल ज़्यादा लोगों को दिख सके.
   2. अगर समस्या, कम्यूनिटी के मालिकाना हक वाली किसी नियम रिपॉज़िटरी से जुड़ी है, जैसे कि rules_apple, तो DevEx टीम का सदस्य इस समस्या को सही रिपॉज़िटरी में ट्रांसफ़र कर देगा.
   3. अगर समस्या के बारे में साफ़ तौर पर नहीं बताया गया है या उसमें ज़रूरी जानकारी नहीं दी गई है, तो DevEx टीम का सदस्य, समस्या को वापस उपयोगकर्ता को असाइन कर देगा. ऐसा इसलिए किया जाएगा, ताकि वह समस्या के बारे में ज़्यादा जानकारी दे सके. इसके बाद ही, समस्या को हल करने की प्रोसेस आगे बढ़ाई जाएगी. आम तौर पर, ऐसा तब होता है, जब उपयोगकर्ता समस्या की जानकारी देने वाले टेंप्लेट का पालन नहीं करता.
3. समस्या की समीक्षा करने के बाद, DevEx टीम का सदस्य यह तय करता है कि समस्या पर तुरंत ध्यान देने की ज़रूरत है या नहीं. अगर ऐसा होता है, तो वे P0 priority लेबल असाइन करेंगे. साथ ही, टीम लीड की सूची से किसी व्यक्ति को मालिक के तौर पर असाइन करेंगे.
4. DevEx टीम का सदस्य, untriaged लेबल असाइन करता है. साथ ही, रूटिंग के लिए सिर्फ़ एक team label असाइन करता है.
5. DevEx टीम का सदस्य, समस्या के टाइप के हिसाब से सिर्फ़ एक type: लेबल असाइन करता है. जैसे, type: bug या type: feature request.
6. किसी प्लैटफ़ॉर्म से जुड़ी समस्याओं के लिए, DevEx टीम का सदस्य एक platform: लेबल असाइन करता है. जैसे, Mac से जुड़ी समस्याओं के लिए platform:apple. इस चरण में, समस्या बिना किसी प्राथमिकता के खुली समस्याओं के पूल में शामिल हो जाती है.

Bazel की हर सबटीम, उन सभी समस्याओं को प्राथमिकता देगी जिनके लेबल उसके पास हैं. ऐसा हर हफ़्ते किया जाना चाहिए. उप-टीम इस समस्या की समीक्षा करेगी और इसका आकलन करेगी. साथ ही, अगर संभव हो, तो इसका समाधान उपलब्ध कराएगी. अगर आपके पास टीम लेबल का मालिकाना हक है, तो ज़्यादा जानकारी के लिए यह सेक्शन देखें.

समस्या हल हो जाने पर, उसे बंद किया जा सकता है.

पुल के अनुरोध की लाइफ़साइकल

1. कोई उपयोगकर्ता पुल का अनुरोध बनाता है.
2. अगर आप Bazel टीम के सदस्य हैं और अपने क्षेत्र के लिए पीआर भेज रहे हैं, तो आपको अपनी टीम का लेबल असाइन करना होगा और सबसे अच्छे समीक्षक को ढूंढना होगा.
3. इसके अलावा, हर दिन की जाने वाली समीक्षा के दौरान, DevEx टीम का कोई सदस्य एक टीम लेबल असाइन करता है. साथ ही, रूटिंग के लिए टीम के टेक्निकल लीड (टीएल) को असाइन करता है.
   1. टीएल के पास यह विकल्प होता है कि वह पीआर की समीक्षा करने के लिए किसी और व्यक्ति को असाइन करे.
4. समीक्षा करने के लिए असाइन किया गया व्यक्ति, पीआर की समीक्षा करता है. साथ ही, वह लेखक के साथ तब तक काम करता है, जब तक पीआर को मंज़ूरी नहीं मिल जाती या उसे हटा नहीं दिया जाता.
5. अगर पीआर को मंज़ूरी मिल जाती है, तो समीक्षक, Google के इंटरनल वर्शन कंट्रोल सिस्टम में पीआर के कमिट इंपोर्ट करता है, ताकि आगे और टेस्ट किए जा सकें. Bazel, Google में इंटरनल तौर पर इस्तेमाल किया जाने वाला एक ही बिल्ड सिस्टम है. इसलिए, हमें सभी पीआर कमिट की जांच, इंटरनल टेस्ट सुइट के हिसाब से करनी होगी. इस वजह से, हम पीआर को सीधे तौर पर मर्ज नहीं करते हैं.
6. अगर इंपोर्ट किया गया कमिट, सभी इंटरनल टेस्ट पास कर लेता है, तो कमिट को स्क्वैश कर दिया जाएगा. इसके बाद, इसे वापस GitHub पर एक्सपोर्ट कर दिया जाएगा.
7. जब कमिट को मास्टर में मर्ज किया जाता है, तो GitHub पीआर को अपने-आप बंद कर देता है.

मेरी टीम के पास एक लेबल का मालिकाना हक है. मुझे क्या करना चाहिए?

उप-टीमों को अपने लेबल से जुड़ी सभी समस्याओं को प्राथमिकता के हिसाब से हल करना होगा. हमारा सुझाव है कि वे ऐसा हर हफ़्ते करें.

समस्याएं

1. अपनी टीम के लेबल और untriaged लेबल के हिसाब से, समस्याओं की सूची को फ़िल्टर करें.
2. समस्या की समीक्षा करें.
3. प्राथमिकता का लेवल तय करें और लेबल असाइन करें.
   1. अगर समस्या P0 है, तो हो सकता है कि DevEx की उप-टीम ने पहले ही इसे प्राथमिकता दे दी हो. अगर ज़रूरी हो, तो प्राथमिकताएं बदलें.
   2. हर समस्या के लिए, सिर्फ़ एक प्राथमिकता का लेबल होना चाहिए. अगर कोई समस्या P0 या P1 है, तो हम मान लेते हैं कि उस पर काम किया जा रहा है.
4. untriaged लेबल हटाएं.

ध्यान दें कि लेबल जोड़ने या हटाने के लिए, आपको bazelbuild संगठन में शामिल होना होगा.

पुल के अनुरोध

1. अपनी टीम के लेबल के हिसाब से, पुल अनुरोधों की सूची को फ़िल्टर करें.
2. पुल के खुले अनुरोधों की समीक्षा करें.
   1. ज़रूरी नहीं: अगर आपको समीक्षा करने के लिए असाइन किया गया है, लेकिन यह आपके लिए सही नहीं है, तो कोड की समीक्षा करने के लिए, किसी दूसरे समीक्षक को असाइन करें.
3. कोड की समीक्षा पूरी करने के लिए, पुल का अनुरोध बनाने वाले व्यक्ति के साथ मिलकर काम करें.
4. पीआर को मंज़ूरी दें.
5. पक्का करें कि सभी टेस्ट पास हो गए हों.
6. पैच को इंटरनल वर्शन कंट्रोल सिस्टम में इंपोर्ट करें और इंटरनल प्रीसबमिट चलाएं.
7. इंटरनल पैच सबमिट करें. अगर पैच सबमिट और एक्सपोर्ट हो जाता है, तो 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: * लेबल को टीम के लेबल के पक्ष में बंद कर दिया है.

लेबल की पूरी सूची यहां देखें.