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

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

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

अगर आपको बेज़ल में योगदान देना है, तो कृपया इसमें योगदान देना है इसके बजाय, Basel का इस्तेमाल करें.

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

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

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

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

रिलीज़

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

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

बेज़ेल के सीआई इन्फ़्रास्ट्रक्चर के बारे में जानने के लिए, Green टीम की गाइड bazelbuild/continuous-integration डेटा स्टोर करने की जगह.

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

1. जब कोई उपयोगकर्ता, इनमें से किसी एक को चुनकर समस्या पैदा करता है समस्या से जुड़े टेंप्लेट और यह जिनकी समीक्षा नहीं की गई है उनके पूल में प्रवेश करता है समस्याएं.
2. डेवलपर एक्सपीरियंस (DevEx) सब-टीम के रोटेशन में शामिल कोई सदस्य, समस्या की समीक्षा करता है.
   1. अगर समस्या बग नहीं है या सुविधा का अनुरोध नहीं है, तो आम तौर पर DevEx सदस्य, समस्या को बंद कर देगा. साथ ही, उपयोगकर्ता को StackOverflow और bazel-discuss पर रीडायरेक्ट कर देगा, ताकि सवाल ज़्यादा से ज़्यादा लोगों को दिख सके.
   2. अगर समस्या, कम्यूनिटी के मालिकाना हक वाले नियमों के किसी डेटाबेस में है, जैसे कि rules_apple, तो DevEx सदस्य इस समस्या को सही डेटाबेस में ट्रांसफ़र कर देगा.
   3. अगर समस्या की जानकारी साफ़ तौर पर नहीं दी गई है या उसमें कोई जानकारी छूट गई है, तो DevEx टीम का सदस्य, उपयोगकर्ता को समस्या को फिर से असाइन कर देगा. इसके बाद, उपयोगकर्ता को समस्या के बारे में ज़्यादा जानकारी देनी होगी. ऐसा आम तौर पर तब होता है, जब उपयोगकर्ता सही विकल्प नहीं चुनता समस्या टेंप्लेट {: .external} या अधूरी जानकारी देता है.
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 लेबल असाइन करता है. इस चरण में, समस्या उन समस्याओं के पूल में शामिल हो जाती है जिन्हें प्राथमिकता नहीं दी गई है.

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

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

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

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

टीम लेबल

• team-Android: Android टीम के लिए समस्याएं
  • संपर्क करें: ahumesky
• team-Bazel: Bazel के प्रॉडक्ट/रणनीति से जुड़ी सामान्य समस्याएं
  • संपर्क: sventiffe
• team-CLI: Console का यूज़र इंटरफ़ेस (यूआई)
  • संपर्क: meisterT
• team-Configurability: कॉन्फ़िगर करने की सुविधा देने वाली टीम के लिए समस्याएं. इसमें ये शामिल हैं: मुख्य बिल्ड कॉन्फ़िगरेशन और ट्रांज़िशन सिस्टम. इसमें ये शामिल नहीं हैं: नए या मौजूदा फ़्लैग में किए गए बदलाव
  • संपर्क करें: gregestren
• team-Core: Skyframe, बेज़ल क्वेरी, BEP, विकल्प पार्स करने की सुविधा, baज़ेनrc
  • संपर्क: haxorz
• team-Documentation: दस्तावेज़ देने वाली टीम के लिए समस्याएं
  • संपर्क: philomathing
• team-ExternalDeps: एक्सटर्नल डिपेंडेंसी मैनेज करना, Bzlmod, रिमोट डेटा स्टोर करने की जगहें, वर्कस्पेस फ़ाइल
  • संपर्क: meeteorcloudy
• team-Loading-API: फ़ाइल और मैक्रो प्रोसेसिंग: लेबल, पैकेज(), विज़िबिलिटी, ग्लोब
  • संपर्क: 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 के नेटिव नियम का लॉजिक भी शामिल है
  • संपर्क: oquenchil
• team-Rules-Java: Java के नियमों से जुड़ी समस्याएं
  • संपर्क: hvadehra
• team-Rules-Python: Python के नेटिव नियमों से जुड़ी समस्याएं
  • संपर्क करें: rickeylev
• team-Rules-Server: Bazel के साथ शामिल सर्वर साइड नियमों से जुड़ी समस्याएं
  • संपर्क: comियस
• team-Starlark-Integration: नॉन-एपीआई Bazel + Starlark इंटिग्रेशन. इसमें ये शामिल हैं: Baज़र, Starlark अनुवादक, Stardoc, बिल्ट-इन इंजेक्शन, कैरेक्टर एन्कोडिंग को कैसे ट्रिगर करता है. इसमें बिल्ड या .bzl भाषा से जुड़ी समस्याएं शामिल नहीं हैं.
  • संपर्क: brandjon
• team-Starlark-Interpreter: Starlark इंटरप्रिटर से जुड़ी समस्याएं (java.net.starlark में मौजूद कोई भी समस्या). BUILD और .bzl API की समस्याएं (जो Starlark के साथ Basel का इंटिग्रेशन दिखाती हैं) team-Build-Language में आती हैं.
  • संपर्क: brandjon

नई समस्याओं के लिए, हमने टीम लेबल के पक्ष में category: * लेबल को बंद कर दिया है.

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