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

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

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

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

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

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

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

भरोसेमंद सोर्स और चुनिंदा जानकारी

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

कमिट चेन

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

ज़रूरी टैग

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

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

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

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

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

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

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

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

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

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

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

इमरजेंसी रीस्पिन प्रोसेस पहली इमेज.इमरजेंसी रीस्पिन प्रोसेस.

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

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

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

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

    • पुष्टि करें कि पैच को GKI डेवलपमेंट ब्रांच में मर्ज कर दिया गया है.
    • पैच को 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 टीम, बदलाव को मर्ज करती है, उसे बनाती है, रिग्रेशन के लिए उसकी जाँच करती है, और उसे सर्टिफ़िकेट देती है.

    • रिलीज़: