একটি রেস্পিনের অনুরোধ করুন

GKI কার্নেলের সর্বজনীন প্রকাশের পর কোনো বাইনারিকে পুনরায় মার্জ করা, পুনর্গঠন করা, পুনরায় পরীক্ষা করা এবং পুনরায় প্রত্যয়ন করার প্রক্রিয়াকে রেস্পিন বলা হয়।

রিস্পিনের অনুরোধ করার আগে, নিম্নলিখিত নির্দেশিকাগুলো লক্ষ্য করুন।

যোগ্যতা এবং জীবনচক্র

  • সময়সীমা: একটি ত্রৈমাসিক বিল্ডের প্রাথমিক পাবলিক রিলিজ চালু হওয়ার পরেই আপনি শুধুমাত্র রিলিজ ব্রাঞ্চগুলিতে রেস্পিনের জন্য অনুরোধ করতে পারবেন। প্রাথমিক পাবলিক রিলিজের পর সর্বোচ্চ ছয় মাসের মধ্যে, শুধুমাত্র একটি নির্দিষ্ট রিলিজ ব্রাঞ্চের জন্য ভেন্ডর-হুক বা অন্যান্য ফিচারের রেস্পিনের অনুরোধ করা যাবে।
  • নিরাপত্তা এবং এলটিএস: ছয় মাস পর, শাখাগুলো শুধুমাত্র অ্যান্ড্রয়েড সিকিউরিটি বুলেটিন (এএসবি)-এ উল্লিখিত নিরাপত্তা প্যাচ বা গুরুতর বাগ ফিক্সের জন্য রেস্পিনের যোগ্য হবে।
  • অপ্রচলিতকরণ: যখন অ্যান্ড্রয়েড সিকিউরিটি বুলেটিন (ASB) দ্বারা সংজ্ঞায়িত LTS প্রয়োজনীয়তার কারণে ব্রাঞ্চটি অসামঞ্জস্যপূর্ণ হয়ে পড়ে, তখন ব্রাঞ্চটিকে অপ্রচলিত ঘোষণা করা হয়। অপ্রচলিত ব্রাঞ্চের জন্য রিস্পিন অনুরোধ গ্রহণ করা হয় না।
    • একটি নির্দিষ্ট GKI রিলিজ ব্রাঞ্চের বাতিল হওয়ার তারিখটি ত্রৈমাসিক GKI রিলিজ বিল্ড নোটের 'রিলিজ' অংশের অধীনে অন্তর্ভুক্ত থাকে। উদাহরণস্বরূপ, সেপ্টেম্বর ২০২৫-এর রিলিজটি মার্চ ২০২৭ পর্যন্ত রেস্পিনের জন্য সমর্থিত থাকবে। এই তারিখটি সেপ্টেম্বর ২০২৫ থেকে শুরু হওয়া রিলিজগুলোর জন্য LTS 2.0 কার্নেল সংস্করণের ১৮ মাসের জীবনকালকে নির্দেশ করে (সেপ্টেম্বর ২০২৫-এর পূর্ববর্তী রিলিজগুলোর জীবনকাল ছিল ১২ মাস)।
  • পরিধি: শুধুমাত্র জরুরি বাগ সংশোধন, সিম্বল তালিকা হালনাগাদ, অথবা বিদ্যমান কোনো ফিচারের ত্রুটি সংশোধনের জন্য প্যাচ প্রয়োগ করতে রেস্পিনের অনুরোধ করুন।

প্যাচ জমা দেওয়ার মানদণ্ড

রিস্পিন অনুরোধ প্রক্রিয়াকরণের জন্য প্রত্যাশিত আদর্শ সমাধান সময় (ESRT) পূরণ করতে, একটি রিলিজ শাখায় জমা দেওয়া সমস্ত প্যাচকে অবশ্যই নিম্নলিখিত প্রযুক্তিগত নিয়মগুলি মেনে চলতে হবে।

সত্যের উৎস এবং বাছাই করা অংশ

  • ডেভেলপমেন্ট ব্রাঞ্চ প্রথমে: ত্রৈমাসিক রিলিজ ব্রাঞ্চে অন্তর্ভুক্ত সমস্ত প্যাচ অবশ্যই মূল GKI ডেভেলপমেন্ট ব্রাঞ্চে আগে থেকেই মার্জ করা থাকতে হবে। উদাহরণস্বরূপ, যদি android15-6.6-2025-08 এর একটি রিস্পিনের জন্য কোনো প্যাচের প্রয়োজন হয়, তবে সেটি অবশ্যই android15-6.6 এ আগে থেকেই মার্জ করা থাকতে হবে।
  • ক্লিন চেরি-পিক: আপনাকে অবশ্যই সরাসরি ডেভেলপমেন্ট ব্রাঞ্চ থেকে প্যাচ চেরি-পিক করতে হবে। অন্য কোনো রিলিজ ব্রাঞ্চ থেকে চেরি-পিক করবেন না (উদাহরণস্বরূপ, 2025-08 থেকে 2025-09 এ পিক করবেন না), কারণ এর ফলে অথর বা কমিট তথ্য ডেভেলপমেন্ট ব্রাঞ্চের ভার্সনের সাথে অসামঞ্জস্যপূর্ণ হতে পারে। অসামঞ্জস্যপূর্ণ তথ্যযুক্ত প্যাচ গ্রহণ করা হবে না।
  • মেটাডেটা সংরক্ষণ করুন: মূল কমিট মেটাডেটা (যেমন, লেখক, মূল টাইমস্ট্যাম্প) সংরক্ষণ করুন। মেটাডেটা সংরক্ষণ করতে git cherry-pick -x ব্যবহার করুন।

কমিট চেইন

  • ক্রমিক শৃঙ্খল: যদি রিস্পিন অনুরোধে একাধিক প্যাচ থাকে, তবে সেগুলোকে কমিটের একটি একক, ক্রমিক শৃঙ্খল হিসেবে আপলোড করুন।
  • ABI এবং KMI স্থাপন: যদি একটি মাল্টি-প্যাচ রিস্পিনে কার্নেল মডিউল ইন্টারফেস (KMI) এবং অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABI) আপডেট অন্তর্ভুক্ত থাকে (উদাহরণস্বরূপ, সিম্বল লিস্ট পরিবর্তন বা XML/STG ফাইল আপডেট), তাহলে এই কমিটগুলিকে কমিট চেইনের একেবারে শেষে রাখুন।
  • রিবেসিং: যদি আপনি চেইনের কোনো প্যারেন্ট কমিট সম্পাদনা করেন, তাহলে বিল্ড ব্যর্থতা এড়ানোর জন্য আপনাকে অবশ্যই সমস্ত চাইল্ড প্যাচকে তার প্যারেন্ট প্যাচের সর্বশেষ রিভিশনের উপর রিবেস করতে হবে।
  • বিরোধ নিষ্পত্তি: যাচাই করুন যে কোনো প্যাচে কোনো বিরোধ চিহ্নিতকারী (conflict markers) উপস্থিত নেই।
  • বিল্ড যাচাইকরণ: সম্পূর্ণ কমিট চেইনটি অবশ্যই সফলভাবে বিল্ড হতে হবে।

প্রয়োজনীয় ট্যাগ

কমিট মেসেজে নিম্নলিখিত ট্যাগগুলো না থাকলে রিস্পিন অনুরোধের অগ্রগতি আটকে থাকে:

  • Change-Id : এটি অবশ্যই ডেভেলপমেন্ট ব্রাঞ্চের পরিবর্তনের Change-Id এর অনুরূপ হতে হবে।
    • ব্যতিক্রম: যদি প্যাচটি কোনো LTS আপডেটের অংশ হিসেবে ডেভেলপমেন্ট ব্রাঞ্চে মার্জ করা হয়ে থাকে, তবে এটি অবশ্যই LTS ভার্সনের একটি চেরি-পিক হতে হবে এবং একটি UPSTREAM প্যাচ হিসেবে ফরম্যাট করা থাকতে হবে। Android Common Kernels-এ আমি কীভাবে প্যাচ জমা দেব তা দেখুন।
  • Bug (বিদ্যমান): মূল ডেভেলপমেন্ট ব্রাঞ্চের কমিট থেকে Bug: XYZ ট্যাগগুলো সরানো যাবে না।
  • Bug (রিস্পিন): আপনাকে অবশ্যই একটি নতুন Bug: XYZ ট্যাগ যোগ করতে হবে, যেখানে XYZ হলো বর্তমান রিস্পিন অনুরোধের সাথে যুক্ত বাগ আইডি।
  • প্রয়োজনে UPSTREAM কমিট ট্যাগ আপডেট করুন: ডেভেলপমেন্ট ব্রাঞ্চ থেকে রিলিজ ব্রাঞ্চে কোনো CL চেরি-পিক করার সময়, এবং CL-টি UPSTREAM হিসেবে ট্যাগ করা থাকলে, নিম্নলিখিত পরিস্থিতিগুলো বিবেচনা করুন:
    • যদি CL-টি রিলিজ ব্রাঞ্চে নির্বিঘ্নে প্রয়োগ করা যায়, তাহলে আপনার কোনো অতিরিক্ত পদক্ষেপ নেওয়ার প্রয়োজন নেই।
    • যদি CL-টি নির্বিঘ্নে প্রয়োগ না হয়, তাহলে দ্বন্দ্বগুলো সমাধান করুন, ট্যাগটি BACKPORT এ আপডেট করুন, এবং দ্বন্দ্ব নিরসনের অংশ হিসেবে কী করা হয়েছে তা নথিভুক্ত করুন; মূল লিনাক্স থেকে ব্যাকপোর্টের জন্য প্রয়োজনীয়তা দেখুন।

অগ্রাধিকার এবং ESRT

GKI টিমকে অগ্রাধিকার নির্ধারণে সাহায্য করার জন্য রিস্পিন অনুরোধটিতে একটি অগ্রাধিকার (জরুরি অবস্থা) নির্ধারণ করুন। এই অগ্রাধিকার GKI টিমকে সময়মতো পার্টনারদের আরও ভালোভাবে সহায়তা করতে সাহায্য করে।

  • গুরুত্বপূর্ণ বা সময়-সংবেদনশীল অনুরোধের ক্ষেত্রে অগ্রাধিকার P0 হিসেবে চিহ্নিত করুন।
  • P0 এবং P1 অনুরোধের ক্ষেত্রে, আপনাকে এর জরুরি অবস্থার কারণও ব্যাখ্যা করতে হবে।

নিম্নলিখিত সারণিতে বাগের অগ্রাধিকার এবং সমাধানের সময়ের (ESRT) একটি সম্পর্ক দেখানো হয়েছে:

অগ্রাধিকার ESRT
পি০ ২ কার্যদিবস
পি১ ৫ কার্যদিবস
পি২ ১০ কার্যদিবস
পি৩ ১৫ কার্যদিবস

SLA নীতিমালা

  • প্রতিটি রিলিজ ব্রাঞ্চের জন্য আলাদাভাবে একটি রেস্পিন অনুরোধ জমা দিন।
  • যদি কোনো রেস্পিন অনুরোধকে 'সংশোধিত' হিসেবে চিহ্নিত করা হয়ে থাকে এবং তাতে আপনার কোনো পরিবর্তন থাকে, তাহলে একটি নতুন রেস্পিন অনুরোধ জমা দিন। অতিরিক্ত চেঞ্জলিস্ট (CL) যোগ করার জন্য অনুরোধটি পুনরায় খুলবেন না।
  • যদি কোনো রিস্পিন অনুরোধের জন্য আপনার উত্তরের প্রয়োজন হয় এবং আপনি তিন কার্যদিবসের মধ্যে উত্তর না দেন, তাহলে অগ্রাধিকার এক স্তর কমিয়ে দেওয়া হয়, উদাহরণস্বরূপ, P0 থেকে P1- এ নামিয়ে আনা হয়।
  • যদি আপনি দুই সপ্তাহের মধ্যে সাড়া না দেন, তাহলে বাগটিকে 'সমাধান করা হবে না (অপ্রচলিত)' হিসেবে চিহ্নিত করা হয়।

পুনরায় স্পিন করার অনুরোধ জমা দিন

নিম্নলিখিত ডায়াগ্রামটি রিস্পিন প্রক্রিয়াটি দেখায়। এই প্রক্রিয়াটি শুরু হয় যখন OEM পার্টনার (আপনি) রিস্পিন অনুরোধ জমা দেন।

জরুরি পুনঃস্পিন প্রক্রিয়া চিত্র ১. জরুরি পুনঃস্পিন প্রক্রিয়া।

পুনরায় স্পিন করার অনুরোধ জমা দিতে:

  1. GKI রিস্পিন অনুরোধ ফর্মটি পূরণ করুন এবং অবিলম্বে আপনার গুগল যোগাযোগ কর্মকর্তার সাথে যোগাযোগ করুন।

    • এই ফর্মটি একটি GKI রিস্পিন অনুরোধ বাগ তৈরি করে।

  2. আপনার প্যাচগুলো প্রস্তুত করুন:

    • প্যাচটি GKI ডেভেলপমেন্ট ব্রাঞ্চে মার্জ করা হয়েছে কিনা তা যাচাই করুন।
    • উপযুক্ত GKI রিলিজ শাখায় প্যাচটি প্রয়োগ করুন।
    • নির্বাচিত প্যাচটি সংশোধন করে তাতে রিস্পিন অনুরোধ আইডি উল্লেখ করে একটি Bug: XYZ ট্যাগ যুক্ত করুন।

    উদাহরণ: android16-6.12 থেকে android16-6.12-2025-12 এ একটি CL চেরি-পিক করতে:

    # 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. বাগটি জমা দিন। অনুরোধ জমা দেওয়ার পর নিম্নলিখিত ঘটনা ঘটে:

    • জমা দেওয়ার পরবর্তী পর্যালোচনা প্রক্রিয়া:

      • গুগল জিকেআই টিম অনুরোধটি পর্যালোচনা করে অনুমোদন করে অথবা আরও তথ্যের প্রয়োজন হলে তা আপনাকে পুনরায় প্রেরণ করে।
      • একটি সমাধানে সম্মত হওয়ার পর, গুগল জিকেআই টিম পরিবর্তনটি কোড রিভিউ করে। এই রিভিউ চলাকালীন ইএসআরটি টাইমার সক্রিয় থাকে। তবে, যদি প্যাচটি প্রত্যাখ্যাত হয় বা এতে পুনর্গঠনের প্রয়োজন হয়, তাহলে ইএসআরটি টাইমারটি রিসেট হয়ে যায়।
      • জিকেআই টিম পরিবর্তনটিকে মার্জ করে, বিল্ড করে, রিগ্রেশনের জন্য পরীক্ষা করে এবং প্রত্যয়ন করে।

    • মুক্তি: