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

समस्या की शिकायत करें सोर्स देखें

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

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

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

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

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

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

रिलीज़

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

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

baZbuild/लगातार-इंटिग्रेशन डेटा स्टोर करने की जगह के बारे में, Baze के सीआई इन्फ़्रास्ट्रक्चर के बारे में ग्रीन टीम की गाइड पढ़ें.

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

1. इस इमेज में दिखाया गया है कि जब उपयोगकर्ता समस्या टेंप्लेट का इस्तेमाल करके कोई समस्या बनाता है, तो वह जिन समस्याओं की समीक्षा नहीं हुई है उनकी सूची में शामिल हो जाता है.
2. डेवलपर एक्सपीरियंस (DevEx) सबटीम के रोटेशन का सदस्य, समस्या की समीक्षा करता है.
   1. अगर समस्या कोई गड़बड़ी नहीं है या किसी सुविधा का अनुरोध है, तो DevEx के सदस्य आम तौर पर समस्या को बंद कर देते हैं. साथ ही, लोगों को उस सवाल की ज़्यादा जानकारी देखने के लिए, उन्हें StackOverflow और baZZ-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. अगर आप बेज़ल टीम के सदस्य हैं और अपने इलाके में पीआर भेज रहे हैं, तो अपनी टीम को लेबल असाइन करने और सबसे अच्छे समीक्षक को खोजने की ज़िम्मेदारी आपकी है.
3. अगर ऐसा नहीं है, तो रोज़ाना की प्राथमिकता के दौरान, DevEx के सदस्य को रूटिंग के लिए एक टीम लेबल और टीम के टेक्निकल लीड (टीएल) को असाइन किया जाता है.
   1. विज्ञापन देने वाले लोग या कंपनियां, पीआर की समीक्षा करने के लिए किसी दूसरे व्यक्ति को असाइन कर सकती हैं.
4. समीक्षक, पीआर की समीक्षा करता है और लेखक के साथ तब तक काम करता है, जब तक उसे अनुमति नहीं दी जाती या हटाया नहीं जाता.
5. अगर मंज़ूरी मिल जाती है, तो समीक्षक पीआर की प्रतिबद्धताओं को आगे की जांचों के लिए, Google के इंटरनल वर्शन कंट्रोल सिस्टम में इंपोर्ट करता है. Basel का बिल्ड सिस्टम ही Google के अंदर इस्तेमाल किया जाता है. इसलिए, हमें इंटरनल टेस्ट सुइट के साथ पीआर की नीतियों की जांच करने की ज़रूरत है. इसी वजह से हम पीआर को सीधे तौर पर मर्ज नहीं करते.
6. अगर इंपोर्ट की गई फ़ाइल, सभी इंटरनल टेस्ट में पास हो जाती है, तो उस तय किए गए हिस्से को स्क्वॉश कर दिया जाएगा और उसे GitHub में वापस एक्सपोर्ट कर दिया जाएगा.
7. जब कमिट को मास्टर में मर्ज किया जाता है, तो GitHub अपने-आप पीआर को बंद कर देता है.

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

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

समस्याएंं

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

ध्यान दें कि लेबल जोड़ने या हटाने के लिए यह ज़रूरी है कि आप bazubuild संगठन में हों.

पुल के अनुरोध

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

प्राथमिकता

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

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

टीम लेबल

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

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

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