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

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

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

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

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

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

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

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

रिलीज़

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

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

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. इस चरण में, समस्या अनट्रीएज्ड ओपन सोर्स में शामिल हो जाती है समस्याएं.

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

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

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

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

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

सब-टीम को उन लेबल में मौजूद सभी समस्याओं की प्राथमिकता तय करनी चाहिए जिनका मालिकाना हक उनके पास है. ऐसा हर हफ़्ते करना चाहिए.

समस्याएं

1. समस्याओं की सूची को टीम लेबल और untriaged लेबल के हिसाब से फ़िल्टर करें.
2. समस्या की समीक्षा करें.
3. प्राथमिकता के लेवल की पहचान करें और लेबल असाइन करें.
   1. हो सकता है कि DevEx सबटीम ने इस समस्या को पहले ही प्राथमिकता दी हो. ऐसा तब होता है, जब पी0. अगर ज़रूरी हो, तो प्राथमिकताएं फिर से तय करें.
   2. हर समस्या के लिए, सिर्फ़ एक प्राथमिकता लेबल होना चाहिए. अगर कोई समस्या, P0 या P1 है, हमें लगता है कि इस पर सक्रिय रूप से काम किया जा रहा है.
4. untriaged लेबल हटाएं.

ध्यान दें कि आपका baज़लbuild में होना चाहिए संगठन के नाम से सेव किया जा सकता है.

पुल के अनुरोध

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

प्राथमिकता

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

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

टीम लेबल

• team-Android: Android टीम के लिए समस्याएं
  • संपर्क करें: ahumesky
• team-Bazel: Bazel के प्रॉडक्ट/रणनीति से जुड़ी सामान्य समस्याएं
  • संपर्क: sventiffe
• team-Build-Language: BUILD, .bzl एपीआई, और Stardoc से जुड़ी समस्याएं.
  • संपर्क: brandjon
• team-Configurability: कॉन्फ़िगर करने की सुविधा देने वाली टीम के लिए समस्याएं
  • संपर्क: gregstren
• team-Core: मुख्य टीम के लिए समस्याएं
  • संपर्क: haxorz
• team-Documentation: दस्तावेज़ बनाने वाली टीम के लिए समस्याएं
  • संपर्क करें: communikit
• team-ExternalDeps: बाहरी डिपेंडेंसी मैनेज करना, Bzlmod, रिमोट रिपॉज़िटरी, WORKSPACE फ़ाइल
  • संपर्क: meteorcloudy
• team-Local-Exec: एक्ज़ीक्यूशन (लोकल) टीम से जुड़ी समस्याएं
  • संपर्क करें: meisterT
• team-OSS: Basel OSS टीम के लिए समस्याएं: इंस्टॉल करने की प्रोसेस, रिलीज़ की प्रोसेस, Basel पैकेजिंग, वेबसाइट, Docs इन्फ़्रास्ट्रक्चर
  • संपर्क: meeteorcloudy
• team-Performance: Bazel की परफ़ॉर्मेंस टीम से जुड़ी समस्याएं
  • संपर्क: meisterT
• team-Remote-Exec: एक्ज़ीक्यूशन (रिमोट) टीम के लिए समस्याएं
  • संपर्क: coeuvre
• team-Rules-CPP: C++ नियमों से जुड़ी समस्याएं. इनमें, Apple के नेटिव नियम का लॉजिक भी शामिल है
  • संपर्क: oquenchil
• team-Rules-Java: Java के नियमों से जुड़ी समस्याएं
  • संपर्क: comius
• team-Rules-Python: Python के नेटिव नियमों से जुड़ी समस्याएं
  • संपर्क: comius
• team-Rules-Server: Basel में शामिल सर्वर-साइड नियमों से जुड़ी समस्याएं
  • संपर्क: comियस
• team-Starlark-integration: नॉन-एपीआई Baज़ल और Starlark इंटिग्रेशन. इसमें यह जानकारी शामिल है कि Bazel, Starlark इंटरप्रिटर, Stardoc, पहले से मौजूद इंजेक्शन, और वर्ण को कोड में बदलने की सुविधा को कैसे ट्रिगर करता है. इसमें ये शामिल नहीं हैं: BUILD या .bzl भाषा से जुड़ी समस्याएं.
  • संपर्क: brandjon
• team-Starlark-interpreter: Starlark अनुवादक से जुड़ी समस्याएं (java.net.starlark में मौजूद सभी समस्याएं). BUILD और .bzl एपीआई से जुड़ी समस्याएं (जो Starlark के साथ Bazel के इंटिग्रेशन को दिखाती हैं) team-Build-Language में जानी चाहिए.
  • संपर्क: brandjon

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

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