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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

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

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

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

रिलीज़

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

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

बेज़ेल के सीआई इन्फ़्रास्ट्रक्चर के बारे में जानने के लिए, Green टीम की गाइड bazelbuild/continuous-integration डेटा स्टोर करने की जगह.

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

1. कोई उपयोगकर्ता, समस्या का इस्तेमाल करके समस्या पैदा करता है टेंप्लेट और यह जिनकी समीक्षा नहीं की गई है उनके पूल में प्रवेश करता है समस्याएं.
2. डेवलपर एक्सपीरियंस (DevEx) सबटीम के रोटेशन का सदस्य, समस्या.
   1. अगर समस्या कोई बग नहीं है या सुविधा का अनुरोध है, तो DevEx का सदस्य आम तौर पर, समस्या बंद हो जाती है और उपयोगकर्ता को StackOverflow और इसके लिए bazu-discuss ज़्यादा पारदर्शिता के साथ.
   2. अगर समस्या किसी ऐसे नियम का डेटा स्टोर करने की जगह में है जिसका मालिकाना हक समुदाय, जैसे कि rules_apple पर DevEx के सदस्य इस समस्या को ट्रांसफ़र करेंगे सही डेटा स्टोर करने की जगह में.
   3. अगर समस्या साफ़ नहीं है या जानकारी मौजूद नहीं है, तो DevEx के सदस्य को उपयोगकर्ता को यह समस्या फिर से असाइन कर दें, ताकि वह इससे पहले ज़्यादा जानकारी मांग सके जारी रखें. ऐसा आम तौर पर तब होता है, जब उपयोगकर्ता समस्या टेंप्लेट.
3. समस्या की समीक्षा करने के बाद, DevEx का सदस्य यह तय करता है कि समस्या को हल करना ज़रूरी है या नहीं तुरंत कार्रवाई करना. अगर ऐसा होता है, तो उसे P0 असाइन करना होगा प्राथमिकता लेबल और टीम लीड की सूची से किसी मालिक को.
4. DevEx का सदस्य, untriaged लेबल और सिर्फ़ एक टीम असाइन करता है लेबल का इस्तेमाल किया जा सकता है.
5. DevEx का सदस्य, type: bug जैसा सिर्फ़ एक type: लेबल असाइन करता है या समस्या के टाइप के हिसाब से type: feature request.
6. प्लैटफ़ॉर्म से जुड़ी समस्याओं के लिए, DevEx का सदस्य एक platform: लेबल असाइन करता है, जैसे कि Mac से जुड़ी समस्याओं के लिए platform:apple. इस चरण में, समस्या अनट्रीएज्ड ओपन सोर्स में शामिल हो जाती है समस्याएं.

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

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

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

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

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