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

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

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

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

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

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

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

रिलीज़

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

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

bazelbuild/continuous-integration रिपॉज़िटरी पर, Bazel के CI इन्फ़्रास्ट्रक्चर के बारे में, ग्रीन टीम की गाइड पढ़ें.

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

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: लेबल असाइन करता है, जैसे platform:apple Mac से जुड़ी समस्याओं के लिए.
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 संगठन में शामिल होना होगा.

पुल के अनुरोध

पुल के अनुरोध (पीआर), Bazel में बाहरी योगदान देने वाले लोगों के योगदान का मुख्य तरीका है. ओपन सोर्स प्रोजेक्ट होने के नाते, यह पक्का करना ज़रूरी है कि पीआर की समीक्षा समय पर और बेहतर तरीके से की जाए.

• समीक्षा

  awaiting-review लेबल और अपनी टीम के लेबल वाले, आने वाले पीआर की समीक्षा समय-समय पर करें. यह काम, रोटेशन या नियमित समीक्षा मीटिंग की मदद से किया जा सकता है. हमारी उम्मीद है कि हर पीआर के लिए, सात कामकाजी दिनों के अंदर शुरुआती जवाब मिल जाएगा.

• जवाब

  • अगर पीआर सही है, तो उसे मंज़ूरी दें और awaiting-PR-merge लेबल लागू करें. gTech टीम, पीआर को सीएल के तौर पर इंपोर्ट करेगी.
  • इसके अलावा, अपना सुझाव, शिकायत या राय दें और awaiting-review लेबल की जगह awaiting-user-response लेबल लगाएं. अगर पीआर का लेखक जवाब देता है, तो DevEx सब-टीम, लेबल को समय-समय पर अपडेट करेगी.
  • बड़े बदलावों वाले पीआर के लिए, डिज़ाइन से जुड़ा दस्तावेज़ या किसी समस्या में पहले की गई चर्चा के बारे में पूछें.

• बंद करना

  सीमित संसाधनों की वजह से, उन पीआर को बंद करना ज़रूरी है जो Bazel के मानकों के मुताबिक नहीं हैं या जिनकी समीक्षा या रखरखाव करने की हमारे पास क्षमता नहीं है.

  • अगर पीआर, Bazel के लक्ष्यों के मुताबिक नहीं है, तो उसे वजह बताकर बंद करें.
  • अगर पीआर बहुत बड़ा और मुश्किल है, तो उसे छोटे-छोटे हिस्सों में बांटने का अनुरोध करके बंद करें.
  • अगर पीआर के कोड की क्वालिटी, हमारे मानकों के मुताबिक नहीं है, तो उसे वजह बताकर बंद करें.
  • अगर कोड के रखरखाव की लागत आने वाले समय में बहुत ज़्यादा है, तो उसे वजह बताकर बंद करें.
  • अगर पीआर को उपयोगकर्ता के जवाब का इंतज़ार करते हुए काफ़ी समय हो गया है और योगदान देने वाले व्यक्ति ने जवाब नहीं दिया है, तो पीआर को 30 दिनों के बाद अपने-आप 'पुराना' के तौर पर मार्क कर दिया जाएगा. इसके बाद, उसे अगले 30 दिनों में बंद कर दिया जाएगा.

  पीआर को बंद करते समय, विनम्र रहें और उसे बंद करने की वजह बताएं.

प्राथमिकता

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

• P0 - ऐसी मुख्य गड़बड़ी जिसकी वजह से, Bazel की रिलीज़ (रिलीज़ कैंडिडेट को छोड़कर) का इस्तेमाल नहीं किया जा सकता. इसके अलावा, ऐसी सेवा जो बंद हो गई है और जिसकी वजह से 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: नियम/पहलू लिखने के लिए एपीआई: प्रोवाइडर, रनफ़ाइल, ऐक्शन, आर्टफ़ैक्ट
  • संपर्क करें: pzembrod
• 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 के साथ शामिल, सर्वर-साइड के नियमों के लिए समस्याएं
  • संपर्क करें: pzembrod
• team-Starlark-Integration: नॉन-एपीआई Bazel + Starlark इंटिग्रेशन. इसमें ये शामिल हैं: Bazel, Starlark इंटरप्रेटर को कैसे ट्रिगर करता है, Stardoc, बिल्ट-इन इंजेक्शन, वर्ण एन्कोडिंग. इसमें ये शामिल नहीं हैं: BUILD या .bzl भाषा से जुड़ी समस्याएं.
  • संपर्क करें: brandjon
• team-Starlark-Interpreter: Starlark इंटरप्रेटर के लिए समस्याएं (java.net.starlark में मौजूद कोई भी समस्या). BUILD और .bzl API से जुड़ी समस्याएं (जो Starlark के साथ Bazel के इंटिग्रेशन को दिखाती हैं) team-Build-Language में शामिल होती हैं.
  • संपर्क करें: brandjon

नई समस्याओं के लिए, हमने category: * लेबल को हटा दिया है. अब इनकी जगह, टीम के लेबल इस्तेमाल किए जाते हैं.

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