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

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

रेस्पिन का अनुरोध करने से पहले, यहां दी गई गाइडलाइन पढ़ें.

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

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

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

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

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

  • डेवलपमेंट ब्रांच पहले: तिमाही रिलीज़ ब्रांच में शामिल किए जाने वाले सभी पैच, 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 के सामान्य कर्नल में पैच सबमिट करने का तरीका देखें .
  • Bug (मौजूदा): ओरिजनल डेवलपमेंट ब्रांच कमिट से, मौजूदा Bug: XYZ टैग नहीं हटाए जाने चाहिए.
  • Bug (रेस्पिन): आपको एक नया Bug: XYZ टैग जोड़ना होगा. इसमें XYZ, मौजूदा रेस्पिन के अनुरोध से जुड़े बग आईडी के बारे में बताता है.
  • ज़रूरत पड़ने पर, UPSTREAM कमिट टैग अपडेट करें: डेवलपमेंट ब्रांच से रिलीज़ ब्रांच में सीएल को चेरी-पिक करते समय और सीएल को UPSTREAM के तौर पर टैग किए जाने पर, इन स्थितियों पर ध्यान दें:
    • अगर सीएल, रिलीज़ ब्रांच पर आसानी से लागू हो जाता है, तो आपको कोई अतिरिक्त कार्रवाई करने की ज़रूरत नहीं है.
    • अगर सीएल आसानी से लागू नहीं होता है, तो कॉन्फ़्लिक्ट ठीक करें, टैग को BACKPORT पर अपडेट करें, और कॉन्फ़्लिक्ट रिज़ॉल्यूशन के तहत की गई कार्रवाई की जानकारी दें. इसके लिए, मेनलाइन Linux से बैकपोर्ट के लिए ज़रूरी शर्तें देखें.

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

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

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

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

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

    • रिलीज़: