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

किसी समस्या की शिकायत करनाopen_in_new सोर्स देखनाopen_in_new Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

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

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

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

रिलीज़

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

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

bazelbuild/continuous-integration रिपॉज़िटरी पर, 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.
7. अगर समस्या कम प्राथमिकता वाली है और समुदाय के किसी नए योगदानकर्ता के पास इसे हल करने की क्षमता है, तो DevEx सदस्य good first issue लेबल असाइन करता है. इस चरण में, समस्या उन समस्याओं के पूल में शामिल हो जाती है जिन्हें प्राथमिकता नहीं दी गई है.

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

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

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

1. कोई उपयोगकर्ता, पुल का अनुरोध बनाता है.
2. अगर आप Bazel टीम के सदस्य हैं और अपने क्षेत्र के लिए पीआर भेज रहे हैं, तो अपनी टीम का लेबल असाइन करने और सबसे अच्छा समीक्षक ढूंढने की ज़िम्मेदारी आपकी है.
3. अगर ऐसा नहीं होता है, तो हर दिन की समस्याओं को हल करने के दौरान, DevEx का कोई सदस्य रूटिंग के लिए एक टीम लेबल और टीम के तकनीकी लीड (टीएल) को असाइन करता है.
   1. टीएल, पीआर की समीक्षा करने के लिए किसी दूसरे व्यक्ति को असाइन कर सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है.
4. असाइन किया गया समीक्षक, पीआर की समीक्षा करता है और लेखक के साथ तब तक काम करता है, जब तक उसे अनुमति नहीं मिल जाती या उसे हटा नहीं दिया जाता.
5. अगर समीक्षा करने वाला व्यक्ति स्वीकार करता है, तो वह आगे की जांच के लिए, पीआर के कमिट को Google के इंटरनल वर्शन कंट्रोल सिस्टम में imports करता है. 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 - कम प्राथमिकता वाला गड़बड़ी का अनुरोध या ऐसी सुविधा का अनुरोध जिसे पूरा होने की संभावना कम है. अगर ज़्यादा उपयोगकर्ताओं पर असर पड़ता है, तो इसे फिर से प्राथमिकता देने के लिए भी खुला रखा जा सकता है.
• ice-box
  • ऐसी समस्याएं जिनसे निपटने के लिए फ़िलहाल हमारे पास समय नहीं है. साथ ही, जिनके लिए योगदान स्वीकार करने का समय भी नहीं है. हम इन समस्याओं को बंद कर देंगे, ताकि यह पता चल सके कि इन पर कोई काम नहीं किया जा रहा है. हालांकि, हम समय-समय पर इनकी पुष्टि करते रहेंगे. साथ ही, अगर इनसे ज़्यादा लोगों पर असर पड़ता है और हमारे पास इन समस्याओं को हल करने के संसाधन होते हैं, तो हम इन्हें फिर से चालू कर देंगे. हमेशा की तरह, इन समस्याओं के बंद होने के बाद भी, इन पर टिप्पणी करें या प्रतिक्रिया दें.

टीम लेबल

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

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