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

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 - कम प्राथमिकता वाली गड़बड़ी या सुविधा का अनुरोध, जिसके बंद होने की संभावना कम है. अगर ज़्यादा उपयोगकर्ताओं को समस्या हो रही है, तो इसे प्राथमिकता फिर से तय करने के लिए भी ओपन रखा जा सकता है.

टीम लेबल

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

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