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

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

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

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

इस पेज का मकसद है:

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

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

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

रिलीज़

कंटिन्यूअस इंटिग्रेशन

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

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

  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: लेबल असाइन करता है, जैसे कि Mac से जुड़ी समस्याओं के लिए platform:apple.
  7. अगर समस्या कम प्राथमिकता है और उस पर समुदाय में योगदान देने वाला कोई नया व्यक्ति काम कर सकता है, तो DevEx सदस्य good first issue लेबल असाइन करता है. इस चरण में, यह समस्या उन खुली समस्याओं में शामिल हो जाती है जिन्हें बिना तय किए रखा गया है.

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

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

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

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

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

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

समस्याएं

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

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

पुल के अनुरोध

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

प्राथमिकता

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

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

टीम लेबल

  • team-Android: Android टीम की समस्याएं
  • team-Bazel: Bazel प्रॉडक्ट/रणनीति से जुड़ी सामान्य समस्याएं
  • team-CLI: कंसोल का यूज़र इंटरफ़ेस (यूआई)
  • team-Configurability: कॉन्फ़िगरेशन टीम के लिए समस्याएं. इसमें शामिल हैं: कोर बिल्ड कॉन्फ़िगरेशन और ट्रांज़िशन सिस्टम. इसमें शामिल नहीं है: नए या मौजूदा फ़्लैग में बदलाव
  • team-Core: Skyframe, bazel query, BEP, विकल्प पार्सिंग, bazelrc
    • संपर्क करें: haxorz
  • team-Documentation: दस्तावेज़ बनाने वाली टीम से जुड़ी समस्याएं
  • team-ExternalDeps: एक्सटर्नल डिपेंडेंसी हैंडलिंग, Bzlmod, रिमोट डेटा स्टोर करने की जगह, WORKSPACE फ़ाइल
  • team-Loading-API: फ़ाइल और मैक्रो प्रोसेसिंग बनाएं: लेबल, Package(), विज़िबिलिटी, ग्लोब
    • संपर्क करें: brandjon
  • team-Local-Exec: एक्ज़ीक्यूशन (लोकल) टीम से जुड़ी समस्याएं
  • team-OSS: Bazel OSS टीम के लिए समस्याएं: इंस्टॉलेशन, रिलीज़ की प्रक्रिया, Bazel की पैकेजिंग, वेबसाइट, दस्तावेज़ का इन्फ़्रास्ट्रक्चर
  • team-Performance: Bazel की परफ़ॉर्मेंस टीम के लिए समस्याएं
  • team-Remote-Exec: एक्ज़ीक्यूशन (रिमोट) टीम से जुड़ी समस्याएं
  • team-Rules-API: नियम/अनुमान लिखने के लिए एपीआई: प्रोवाइडर, रनफ़ाइल, ऐक्शन, आर्टफ़ैक्ट
  • team-Rules-CPP / team-Rules-ObjC: C++/Objective-C नियमों से जुड़ी समस्याएं. इनमें Apple के नेटिव नियम वाले लॉजिक से जुड़ी समस्याएं भी शामिल हैं
  • team-Rules-Java: Java के नियमों से जुड़ी समस्याएं
  • team-Rules-Python: Python के नेटिव नियमों से जुड़ी समस्याएं
  • team-Rules-Server: Bazel में शामिल सर्वर-साइड के नियमों से जुड़ी समस्याएं
  • 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: * लेबल हटा दिए हैं.

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