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

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

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

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

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

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

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

रिलीज़

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

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

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: लेबल.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: 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: नियम/पहलू लिखने के लिए एपीआई: प्रोवाइडर, रनफ़ाइल, कार्रवाइयां, आर्टफ़ैक्ट
  • संपर्क करें: 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: * लेबल को बंद कर दिया है.

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