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

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

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

इस पेज का मकसद:

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

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

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

रिलीज़

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

कंटिन्यूअस इंटिग्रेशन

bazelbuild/लगातार-इंटिग्रेशन डेटा स्टोर करने की जगह पर, Bazel के सीआई इन्फ़्रास्ट्रक्चर के बारे में ग्रीन टीम की गाइड पढ़ें.

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

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

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

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

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

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

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

सब-टीम को अपने मालिकाना हक वाले लेबल से सभी समस्याओं को हल करने की कोशिश करनी होगी. ऐसा हर हफ़्ते करना चाहिए.

समस्याएं

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 - छोटी-मोटी गड़बड़ियों को ठीक करना या बहुत कम असर डालने वाली चीज़ों को बेहतर बनाना. बैजल के रोडमैप या आने वाले समय में होने वाली किसी रिलीज़ को प्राथमिकता नहीं दी गई है. हालांकि, हम कम्यूनिटी में योगदान देने को बढ़ावा देते हैं.
• P4 - कम प्राथमिकता में खराबी या सुविधा का अनुरोध, जिसके बंद होने की संभावना नहीं है. अगर ज़्यादा उपयोगकर्ताओं पर इसका असर पड़ता है, तो इस डेटा को फिर से प्राथमिकता देने के लिए भी इस सेटिंग को उपलब्ध कराया जा सकता है.
• आइस-बॉक्स
  • ऐसी समस्याएं जिनसे निपटने के लिए हमारे पास न तो समय है और न ही योगदान स्वीकार करने का समय. हम इन समस्याओं को बंद करेंगे, ताकि यह बताया जा सके कि कोई इन पर काम नहीं कर रहा है. हालांकि, हम समय के साथ डेटा की वैधता को मॉनिटर करते रहेंगे. अगर कई लोगों पर इसका असर हुआ हो, तो इन समस्याओं को ठीक किया जा सकेगा. हमेशा की तरह, इन समस्याओं पर टिप्पणी करें या प्रतिक्रियाएं जोड़ें.

टीम लेबल

• team-Android: Android टीम के लिए समस्याएं
  • संपर्क: ahumesky
• team-Bazel: Bazel प्रॉडक्ट/रणनीति से जुड़ी सामान्य समस्याएं
  • संपर्क: sventiffe
• team-Build-Language: BUILD, .bzl API, और Stardoc से जुड़ी समस्याएं.
  • संपर्क: brandjon
• team-Configurability: कॉन्फ़िगरेशन टीम के लिए समस्याएं
  • संपर्क करें: gregestren
• team-Core: मुख्य टीम की समस्याएं
  • संपर्क: haxorz
• team-Documentation: दस्तावेज़ बनाने वाली टीम की समस्याएं
  • संपर्क करें: communikit
• team-ExternalDeps: एक्सटर्नल डिपेंडेंसी हैंडलिंग, Bzlmod, रिमोट डेटा स्टोर करने की जगहें, WORKSPACE फ़ाइल
  • संपर्क: Meeorcloudy
• team-Local-Exec: प्लान लागू करने (लोकल) टीम से जुड़ी समस्याएं
  • संपर्क: meisterT
• team-OSS: Bazel OSS टीम के लिए समस्याएं: इंस्टॉल करने, रिलीज़ करने की प्रक्रिया, Bazel पैकेजिंग, वेबसाइट, दस्तावेज़ का इन्फ़्रास्ट्रक्चर
  • संपर्क: Meeorcloudy
• team-Performance: Bazel की परफ़ॉर्मेंस टीम से जुड़ी समस्याएं
  • संपर्क: meisterT
• team-Remote-Exec: काम करने की अनुमति देने वाली (रिमोट) टीम से जुड़ी समस्याएं
  • संपर्क: coeuvre
• team-Rules-CPP: C++ नियमों से जुड़ी समस्याएं, जिसमें Apple के नेटिव नियम भी शामिल हैं
  • संपर्क: oquenchil
• team-Rules-Java: Java के नियमों से जुड़ी समस्याएं
  • संपर्क करें: comious
• team-Rules-Python: Python के नेटिव नियमों से जुड़ी समस्याएं
  • संपर्क करें: comious
• team-Rules-Server: Bazel में शामिल सर्वर-साइड के नियमों से जुड़ी समस्याएं
  • संपर्क करें: comious
• 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: * लेबल की सुविधा बंद कर दी है.

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