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

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

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

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

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

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

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

रिलीज़

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

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

Bazel के सीआई इन्फ़्रास्ट्रक्चर के बारे में जानने के लिए, ग्रीन टीम की गाइड पढ़ें. यह गाइड, bazelbuild/continuous-integration रिपॉज़िटरी पर उपलब्ध है.

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

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

टीम के लेबल

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

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