फिर से स्पिन करने का अनुरोध करना

GKI कर्नल को सार्वजनिक तौर पर रिलीज़ करने के बाद, बाइनरी को फिर से मर्ज करने, फिर से बनाने, फिर से टेस्ट करने, और फिर से सर्टिफ़ाई करने की प्रोसेस को रीस्पिन कहते हैं.

फिर से स्पिन करने का अनुरोध करने से पहले, इन दिशा-निर्देशों को ध्यान में रखें.

ज़रूरी शर्तें और लाइफ़साइकल

  • समय: तिमाही बिल्ड की शुरुआती सार्वजनिक रिलीज़ लॉन्च होने के बाद, सिर्फ़ रिलीज़ ब्रांच पर फिर से स्पिन करने का अनुरोध किया जा सकता है. वेंडर-हुक या अन्य सुविधाओं के लिए, फिर से स्पिन करने का अनुरोध सिर्फ़ किसी रिलीज़ ब्रांच के लिए किया जा सकता है. यह अनुरोध, सार्वजनिक तौर पर रिलीज़ होने के बाद ज़्यादा से ज़्यादा छह महीने तक किया जा सकता है.
  • सुरक्षा और एलटीएस: छह महीने के बाद, शाखाओं को सिर्फ़ Android सुरक्षा बुलेटिन (एएसबी) में बताए गए सिक्योरिटी पैच या गंभीर गड़बड़ियों को ठीक करने के लिए फिर से स्पिन किया जा सकता है.
  • इस्तेमाल पर रोक: जब Android सिक्योरिटी बुलेटिन (एएसबी) की ओर से तय की गई एलटीएस की ज़रूरी शर्तों को पूरा न करने की वजह से, ब्रांच को ज़रूरी शर्तों का पालन न करने वाली ब्रांच के तौर पर मार्क किया जाता है, तो उस ब्रांच के इस्तेमाल पर रोक लगा दी जाती है. अब इस्तेमाल में नहीं होने वाली ब्रांच के लिए, फिर से स्पिन करने के अनुरोध स्वीकार नहीं किए जाते.
    • किसी GKI रिलीज़ ब्रांच के बंद होने की तारीख, रिलीज़ सेक्शन में हर तीन महीने में जारी होने वाले GKI रिलीज़ के लिए तैयार बिल्ड के नोट में शामिल होती है. उदाहरण के लिए, सितंबर 2025 में रिलीज़ किए गए वर्शन के लिए, मार्च 2027 तक रीस्पिन की सुविधा उपलब्ध है. यह तारीख, सितंबर 2025 से रिलीज़ होने वाले वर्शन के लिए, एलटीएस 2.0 कर्नेल वर्शन की 18 महीने की लाइफ़टाइम को दिखाती है. सितंबर 2025 से पहले रिलीज़ हुए वर्शन की लाइफ़टाइम 12 महीने थी.
  • दायरा: सिर्फ़ ज़रूरी गड़बड़ियों को ठीक करने, सिंबल की सूची अपडेट करने या किसी मौजूदा सुविधा को ठीक करने के लिए पैच लागू करने के लिए, फिर से स्पिन करने का अनुरोध करें.
  • 16 केबी वाले जीकेआई रिलीज़: 16 केबी वाले जीकेआई ब्रांच (android15-6.6, android16-6.12, और android17-6.18) के लिए, मांग पर रीस्पिन करने की सुविधा उपलब्ध है. इसके लिए, रीस्पिन करने का अनुरोध करने वाला वही फ़ॉर्म, पैच सबमिट करने के स्टैंडर्ड, और ज़रूरी शर्तें लागू होती हैं जो 4 केबी वाले बिल्ड के लिए लागू होती हैं. आपको 4 केबी और 16 केबी वाले कर्नेल को एक साथ अपडेट करने की ज़रूरत नहीं है. हालांकि, हमारा सुझाव है कि आप ऐसा करें.

पैच सबमिट करने के स्टैंडर्ड

रीस्पिन के अनुरोध को प्रोसेस करने के लिए, समस्या हल करने में लगने वाले अनुमानित समय (ईएसआरटी) को पूरा करना ज़रूरी है. इसके लिए, रिलीज़ ब्रांच में सबमिट किए गए सभी पैच को इन तकनीकी नियमों का पालन करना होगा.

सही और पूरी जानकारी का सोर्स और चेरी-पिक

  • डेवलपमेंट ब्रांच पहले: हर तिमाही में रिलीज़ होने वाली ब्रांच में जाने वाले सभी पैच, पहले से ही मुख्य GKI डेवलपमेंट ब्रांच में मर्ज होने चाहिए. उदाहरण के लिए, अगर android15-6.6-2025-08 के रीस्पिन के लिए पैच की ज़रूरत है, तो उसे पहले से ही android15-6.6 में मर्ज किया जाना चाहिए.
  • क्लीन चेरी-पिक: आपको सीधे डेवलपमेंट ब्रांच से पैच चेरी-पिक करने होंगे. अन्य रिलीज़ ब्रांच से चेरी-पिक न करें. उदाहरण के लिए, 2025-08 से 2025-09 तक न चुनें. ऐसा करने से, लेखक या कमिट की जानकारी, डेवलपमेंट ब्रांच के वर्शन से मेल नहीं खा सकती. जिन पैच में जानकारी मेल नहीं खाती उन्हें स्वीकार नहीं किया जाएगा.
  • मेटाडेटा को सुरक्षित रखना: ओरिजनल कमिट मेटाडेटा को सुरक्षित रखें. उदाहरण के लिए, लेखक, ओरिजनल टाइमस्टैंप. मेटाडेटा को सुरक्षित रखने के लिए, git cherry-pick -x का इस्तेमाल करें.

कमिट चेन

  • क्रम में चलने वाली चेन: अगर फिर से स्पिन करने के अनुरोध में कई पैच शामिल हैं, तो उन्हें कमिट की एक, क्रम में चलने वाली चेन के तौर पर अपलोड करें.
  • एबीआई और केएमआई प्लेसमेंट: अगर एक से ज़्यादा पैच वाले रीस्पिन में कर्नल मॉड्यूल इंटरफ़ेस (केएमआई) और ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) अपडेट शामिल हैं (उदाहरण के लिए, सिंबल लिस्ट में बदलाव या XML/STG फ़ाइल अपडेट), तो इन कमिट को कमिट चेन के आखिर में रखें.
  • रीबेस करना: अगर चेन में किसी पैरंट कमिट में बदलाव किया जाता है, तो आपको सभी चाइल्ड पैच को उसके पैरंट पैच के नए वर्शन के ऊपर रीबेस करना होगा. इससे बिल्ड फ़ेल होने से बचा जा सकता है.
  • कॉन्फ़्लिक्ट रिज़ॉल्यूशन: पुष्टि करें कि किसी भी पैच में कोई कॉन्फ़्लिक्ट मार्कर मौजूद न हो.
  • बिल्ड की पुष्टि: पूरी कमिट चेन को सही तरीके से बिल्ड करना ज़रूरी है.

ज़रूरी टैग

कमिट मैसेज में ये टैग शामिल न होने पर, फिर से स्पिन करने के अनुरोध की प्रोसेस को ब्लॉक कर दिया जाता है:

  • Change-Id: यह डेवलपमेंट ब्रांच में किए गए बदलाव के Change-Id से मेल खाना चाहिए.
    • अपवाद: अगर पैच को एलटीएस अपडेट के हिस्से के तौर पर डेवलपमेंट ब्रांच में मर्ज किया गया है, तो यह एलटीएस वर्शन का चेरी-पिक होना चाहिए. साथ ही, इसे UPSTREAM पैच के तौर पर फ़ॉर्मैट किया जाना चाहिए. देखें कि मैं Android Common Kernels में पैच कैसे सबमिट करूं.
  • Bug (मौजूदा): ओरिजनल डेवलपमेंट ब्रांच कमिट के मौजूदा Bug: XYZ टैग नहीं हटाए जाने चाहिए.
  • Bug (respin): आपको एक नया Bug: XYZ टैग जोड़ना होगा. इसमें XYZ, मौजूदा रीस्पिन अनुरोध से जुड़े बग आईडी को दिखाता है.
  • अगर ज़रूरी हो, तो UPSTREAM कमिट टैग को अपडेट करें: डेवलपमेंट ब्रांच से रिलीज़ ब्रांच में सीएल को चेरी-पिक करते समय, अगर सीएल को UPSTREAM के तौर पर टैग किया गया है, तो इन स्थितियों पर ध्यान दें:
    • अगर CL को रिलीज़ ब्रांच पर आसानी से लागू किया जा सकता है, तो आपको कोई अन्य कार्रवाई करने की ज़रूरत नहीं है.
    • अगर सीएल सही तरीके से लागू नहीं होता है, तो गड़बड़ियों को ठीक करें. साथ ही, टैग को BACKPORT पर अपडेट करें और गड़बड़ी को ठीक करने के लिए किए गए बदलावों को दस्तावेज़ में शामिल करें. इसके लिए, Linux के मुख्य वर्शन से बैकपोर्ट करने की ज़रूरी शर्तें देखें.

प्राथमिकता और ईएसआरटी

रीस्पिन के अनुरोध को प्राथमिकता (ज़रूरत) असाइन करें, ताकि GKI टीम को प्राथमिकता तय करने में मदद मिल सके. इस प्राथमिकता से, GKI टीम को पार्टनर की समय पर और बेहतर तरीके से मदद करने में मदद मिलती है.

  • ज़रूरी या समय के हिसाब से संवेदनशील अनुरोधों के लिए, प्राथमिकता को P0 के तौर पर मार्क करें.
  • P0 और P1 अनुरोधों के लिए, आपको यह भी बताना होगा कि समस्या कितनी गंभीर है.

यहां दी गई टेबल में, गड़बड़ी की प्राथमिकता और उसे ठीक करने में लगने वाले समय (ईएसआरटी) की मैपिंग दी गई है:

प्राथमिकताESRT
P02 व्यावसायिक दिन
P15 कामकाजी दिन
P210 कामकाजी दिन
P315 कार्यदिवस

एसएलए से जुड़ी नीतियां

  • हर रिलीज़ ब्रांच के लिए, अलग से रीस्पिन का अनुरोध सबमिट करें.
  • अगर आपको फिर से स्पिन करने के अनुरोध में बदलाव करना है और उसे ठीक कर दिया गया है, तो फिर से स्पिन करने का नया अनुरोध सबमिट करें. अतिरिक्त चेंजलिस्ट (सीएल) जोड़ने के लिए, अनुरोध को फिर से न खोलें.
  • अगर रीस्पिन के अनुरोध के लिए आपके जवाब की ज़रूरत है और आपने तीन कामकाजी दिनों के अंदर जवाब नहीं दिया, तो प्राथमिकता को एक लेवल कम कर दिया जाता है. उदाहरण के लिए, P0 को डाउनग्रेड करके P1 कर दिया जाता है.
  • अगर आपने दो हफ़्तों तक कोई जवाब नहीं दिया, तो बग को ठीक नहीं किया जाएगा (अब इस्तेमाल में नहीं है) के तौर पर मार्क कर दिया जाएगा.

फिर से स्पिन करने का अनुरोध सबमिट करना

इस डायग्राम में, फिर से स्पिन करने की प्रोसेस दिखाई गई है. यह प्रोसेस तब शुरू होती है, जब ओईएम पार्टनर (आप) फिर से स्पिन करने का अनुरोध सबमिट करता है.

इमरजेंसी रीस्पिन प्रोसेस पहली इमेज.आपातकालीन स्थिति में फिर से स्पिन करने की प्रोसेस.

फिर से स्पिन करने का अनुरोध सबमिट करने के लिए:

  1. GKI को फिर से स्पिन करने का अनुरोध करने वाला फ़ॉर्म भरें और Google की तरफ़ से बातचीत करने वाले व्यक्ति से तुरंत संपर्क करें.

    • इस फ़ॉर्म से, GKI के रीस्पिन के अनुरोध से जुड़ी गड़बड़ी की शिकायत की जाती है.

  2. अपने पैच तैयार करें:

    • पुष्टि करें कि पैच को जीकेआई डेवलपमेंट ब्रांच में मर्ज कर दिया गया है.
    • पैच को GKI की सही रिलीज़ ब्रांच पर लागू करें.
    • चुने गए पैच में बदलाव करें, ताकि उसमें Bug: XYZ टैग शामिल किया जा सके. इसमें, फिर से स्पिन करने के अनुरोध का आईडी शामिल करें.

    उदाहरण: android16-6.12 से android16-6.12-2025-12 में किसी सीएल को चेरी-पिक करने के लिए:

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. गड़बड़ी की शिकायत सबमिट करें. अनुरोध सबमिट करने के बाद, ये चीज़ें होती हैं:

    • आवेदन सबमिट करने के बाद, समीक्षा की प्रोसेस:

      • Google GKI टीम, अनुरोध की समीक्षा करती है. अगर उसे ज़्यादा जानकारी की ज़रूरत नहीं होती है, तो वह अनुरोध को स्वीकार कर लेती है. अगर उसे ज़्यादा जानकारी की ज़रूरत होती है, तो वह अनुरोध को वापस आपको असाइन कर देती है.
      • समस्या ठीक करने के लिए सहमति मिलने के बाद, Google GKI टीम बदलाव का कोड रिव्यू करती है. इस समीक्षा के दौरान, ESRT टाइमर चालू रहता है. हालांकि, अगर पैच को अस्वीकार कर दिया जाता है या उसमें बदलाव करने की ज़रूरत होती है, तो ईएसआरटी टाइमर रीसेट हो जाता है.
      • GKI टीम, बदलाव को मर्ज करती है, उसे बनाती है, रिग्रेशन के लिए उसकी जांच करती है, और उसे सर्टिफ़िकेट देती है.

    • रिलीज़:

      • बाइनरी को ci.android.com पर रिलीज़ किया जाता है.
      • ईएसआरटी की समयसीमा खत्म हो जाती है. इसके बाद, Google की GKI टीम, अनुरोध को 'ठीक किया गया' के तौर पर मार्क करती है और रेस्पिन बिल्ड का रेफ़रंस देती है.
      • रीस्पिन बिल्ड को जेनेरिक कर्नल इमेज (जीकेआई) रिलीज़ बिल्ड पेज पर भी पोस्ट किया जाता है.