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

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

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

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

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

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

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

रिलीज़

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

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

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

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

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

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 के प्रॉडक्ट/रणनीति से जुड़ी सामान्य समस्याएं
  • संपर्क करें: meisterT
• team-CLI: Console UI
  • संपर्क करें: meisterT
• team-Configurability: कॉन्फ़िगरेशन टीम के लिए समस्याएं. इसमें ये शामिल हैं: कोर बिल्ड कॉन्फ़िगरेशन और ट्रांज़िशन सिस्टम. इसमें ये शामिल नहीं हैं: नए या मौजूदा फ़्लैग में किए गए बदलाव
  • संपर्क करें: gregestren
• team-Core: Skyframe, bazel query, BEP, options parsing, bazelrc
  • संपर्क करें: haxorz
• team-Documentation: दस्तावेज़ से जुड़ी टीम के लिए समस्याएं
• team-ExternalDeps: बाहरी डिपेंडेंसी को मैनेज करना, Bzlmod, रिमोट रिपॉज़िटरी, WORKSPACE फ़ाइल
  • संपर्क करें: meteorcloudy
• team-Loading-API: BUILD फ़ाइल और मैक्रो प्रोसेसिंग: लेबल, package(), visibility, glob
  • संपर्क करें: brandjon
• team-Local-Exec: लोकल टीम के लिए समस्याएं
  • संपर्क करें: meisterT
• team-OSS: Bazel OSS टीम के लिए समस्याएं: इंस्टॉलेशन, रिलीज़ प्रोसेस, Bazel पैकेजिंग, वेबसाइट, दस्तावेज़ों का इन्फ़्रास्ट्रक्चर
  • संपर्क करें: meteorcloudy
• team-Performance: Bazel की परफ़ॉर्मेंस टीम के लिए समस्याएं
  • संपर्क करें: meisterT
• team-Remote-Exec: Execution (Remote) टीम के लिए समस्याएं
  • संपर्क करें: coeuvre
• team-Rules-API: नियम/पहलू लिखने के लिए एपीआई: प्रोवाइडर, रनफ़ाइल, कार्रवाइयां, आर्टफ़ैक्ट
  • संपर्क करें: comius
• team-Rules-CPP / team-Rules-ObjC: C++/Objective-C नियमों से जुड़ी समस्याएं. इनमें Apple के मूल नियम का लॉजिक भी शामिल है
  • संपर्क करें: pzembrod
• team-Rules-Java: Java के नियमों से जुड़ी समस्याएं
  • संपर्क करें: hvadehra
• team-Rules-Python: नेटिव Python नियमों से जुड़ी समस्याएं
  • संपर्क करें: rickeylev
• 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: * लेबल को हटा दिया है. अब टीम के लेबल का इस्तेमाल किया जाएगा.

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