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

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

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

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

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

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

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

रिलीज़

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

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

Bazel के सीआई इन्फ़्रास्ट्रक्चर के बारे में Green टीम की गाइड पढ़ें. यह गाइड, 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 लेबल असाइन करता है. साथ ही, रूटिंग के लिए सिर्फ़ एक team label असाइन करता है.
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 संगठन में शामिल होना होगा.

पुल के अनुरोध

पुल अनुरोध (पीआर), बाहरी योगदानकर्ताओं के लिए Bazel में योगदान करने का मुख्य तरीका है. ओपन सोर्स प्रोजेक्ट होने के नाते, यह पक्का करना ज़रूरी है कि पीआर की समीक्षा समय पर और असरदार तरीके से की जाए.

• ट्रायज

  awaiting-review लेबल और अपनी टीम के लेबल वाले पीआर की नियमित रूप से समीक्षा करें. ऐसा रोटेशन या नियमित रूप से होने वाली ट्राइएज मीटिंग के ज़रिए किया जा सकता है. हमारा मानना है कि हर पीआर को सात कामकाजी दिनों के अंदर शुरुआती जवाब मिल जाना चाहिए.

• जवाब

  • अगर पीआर सही लगता है, तो उसे स्वीकार करें और awaiting-PR-merge लेबल लागू करें. gTech टीम, पीआर को सीएल के तौर पर इंपोर्ट करेगी.
  • अगर ऐसा नहीं है, तो अपना सुझाव/राय दें या शिकायत करें. इसके बाद, awaiting-review लेबल की जगह awaiting-user-response लेबल का इस्तेमाल करें. अगर पीआर के लेखक का जवाब मिलता है, तो DevEx की सबटीम लेबल को नियमित तौर पर अपडेट करेगी.
  • बड़े बदलावों वाले पीआर के लिए, डिज़ाइन दस्तावेज़ या किसी समस्या पर पहले हुई चर्चा के बारे में पूछें.

• बंद होना

  संसाधन सीमित होने की वजह से, उन पीआर को बंद करना ज़रूरी है जो Bazel के मानकों के मुताबिक नहीं हैं या जिनकी समीक्षा करने या उन्हें बनाए रखने की हमारे पास क्षमता नहीं है.

  • अगर पीआर, Bazel के लक्ष्यों के मुताबिक नहीं है, तो उसे बंद कर दें और इसकी वजह बताएं.
  • अगर पीआर बहुत बड़ा और मुश्किल है, तो उसे बंद कर दें. साथ ही, उसे छोटे-छोटे हिस्सों में बांटने का अनुरोध करें.
  • अगर पीआर कोड की क्वालिटी हमारे मानकों के मुताबिक नहीं है, तो इसकी वजह बताते हुए इसे बंद करें.
  • अगर कोड को बनाए रखने की लागत बहुत ज़्यादा है, तो इसे बंद करें और इसकी वजह बताएं.
  • अगर पीआर को उपयोगकर्ता के जवाब का इंतज़ार करते हुए काफ़ी समय हो गया है और योगदान देने वाले व्यक्ति ने जवाब नहीं दिया है, तो 30 दिनों के बाद पीआर को अपने-आप 'पुराना' के तौर पर मार्क कर दिया जाएगा. इसके 30 दिनों बाद, इसे बंद कर दिया जाएगा.

  पीआर बंद करते समय, विनम्रता से पेश आएं और बंद करने की वजह बताएं.

प्राथमिकता

प्राथमिकता की इन परिभाषाओं का इस्तेमाल, रखरखाव करने वाले लोग समस्याओं को प्राथमिकता के हिसाब से व्यवस्थित करने के लिए करेंगे.

• P0 - मुख्य फ़ंक्शन काम नहीं कर रहा है. इसकी वजह से, Bazel के रिलीज़ कैंडिडेट के अलावा अन्य रिलीज़ का इस्तेमाल नहीं किया जा सकता. इसके अलावा, यह ऐसी सेवा है जो Bazel प्रोजेक्ट के डेवलपमेंट पर गंभीर असर डालती है. इसमें नई रिलीज़ में हुई ऐसी गड़बड़ियां शामिल हैं जिनकी वजह से, बड़ी संख्या में उपयोगकर्ता ऐप्लिकेशन का इस्तेमाल नहीं कर पा रहे हैं. इसके अलावा, इसमें ऐसा बदलाव भी शामिल है जो बदलाव से जुड़ी नीति का पालन नहीं करता है. इस समस्या को ठीक करने का कोई तरीका नहीं है.
• P1 - गंभीर गड़बड़ी या ऐसी सुविधा जिसे अगली रिलीज़ में ठीक किया जाना चाहिए. इसके अलावा, ऐसी गंभीर समस्या जिसका असर कई लोगों पर पड़ता है. इसमें Bazel प्रोजेक्ट का डेवलपमेंट भी शामिल है. हालांकि, इस समस्या को हल करने का कोई तरीका मौजूद है. आम तौर पर, इसके लिए तुरंत कार्रवाई करने की ज़रूरत नहीं होती. इसकी बहुत ज़्यादा मांग है और इसे चालू तिमाही के रोडमैप में शामिल किया गया है.
• P2 - यह एक ऐसा डिफ़ेक्ट या सुविधा है जिसे ठीक किया जाना चाहिए, लेकिन फ़िलहाल हम इस पर काम नहीं कर रहे हैं. Bazel के रिलीज़ किए गए वर्शन में लाइव समस्या है. इससे उपयोगकर्ता को परेशानी हो रही है. इस समस्या को आने वाली रिलीज़ में ठीक किया जाना चाहिए और/या इसका आसान समाधान उपलब्ध है.
• P3 - छोटी गड़बड़ी को ठीक करना या सुधार करना ज़रूरी है. इससे बहुत कम असर पड़ता है. इसे Bazel के रोडमैप या किसी भी आने वाली रिलीज़ में प्राथमिकता नहीं दी गई है. हालांकि, कम्यूनिटी के योगदान को बढ़ावा दिया जाता है.
• P4 - कम प्राथमिकता वाला ऐसा डिफ़ेक्ट या सुविधा का अनुरोध जिसे शायद ही कभी बंद किया जाता है. अगर ज़्यादा उपयोगकर्ताओं पर असर पड़ता है, तो इसे फिर से प्राथमिकता देने के लिए भी खुला रखा जा सकता है.

टीम के लेबल

• team-Android: Android टीम के लिए समस्याएं
  • संपर्क करें: ahumesky
• team-Bazel: Bazel के प्रॉडक्ट/रणनीति से जुड़ी सामान्य समस्याएं
  • संपर्क करें: meisterT
• team-CLI: कंसोल यूज़र इंटरफ़ेस
  • संपर्क करें: 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: नियम/पहलू लिखने के लिए एपीआई: प्रोवाइडर, रनफ़ाइल, कार्रवाइयां, आर्टफ़ैक्ट
  • संपर्क करें: pzembrod
• 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 के साथ शामिल सर्वर-साइड नियमों से जुड़ी समस्याएं
  • संपर्क करें: pzembrod
• 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: * लेबल को टीम के लेबल के पक्ष में बंद कर दिया है.

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