আবার স্পিন করার অনুরোধ করা

GKI কার্নেল পাবলিক রিলিজ করার পরে, কোনও বাইনারি আবার মার্জ করা, আবার তৈরি করা, আবার পরীক্ষা করা এবং আবার সার্টিফাই করার প্রসেসকে রিস্পিন বলা হয়।

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

যোগ্যতা ও লাইফসাইকেল

  • সময়: ত্রৈমাসিক বিল্ডের প্রাথমিক পাবলিক রিলিজ লঞ্চ হওয়ার পরে আপনি শুধুমাত্র রিলিজ ব্রাঞ্চে রেস্পিনের অনুরোধ করতে পারবেন। প্রাথমিক পাবলিক রিলিজের পরে সর্বাধিক ছয় মাস পর্যন্ত কোনও নির্দিষ্ট রিলিজ ব্রাঞ্চের জন্য ভেন্ডর-হুক বা অন্যান্য ফিচারের জন্য আবার জমা দেওয়ার অনুরোধ করুন।
  • নিরাপত্তা ও LTS: ছয় মাস পরে, Android Security Bulletin (ASB)-এ উল্লেখ করা নিরাপত্তা প্যাচ বা গুরুতর সমস্যার সমাধানের জন্য ব্রাঞ্চগুলি রিস্পিন করার উপযুক্ত হয়। তবে এটি শুধুমাত্র এই দু'টি ক্ষেত্রেই প্রযোজ্য।
  • পুরনো হয়ে যাওয়া: Android Security Bulletin (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 ফাইল আপডেট) থাকলে, এই কমিটগুলি কমিট চেনের একেবারে শেষে রাখুন।
  • রিবেসিং: চেনে কোনও প্যারেন্ট কমিট এডিট করলে, বিল্ড ফেল হওয়া এড়াতে, আপনাকে অবশ্যই এর প্যারেন্ট প্যাচের লেটেস্ট রিভিশনের উপরে সব চাইল্ড প্যাচ রিবেস করতে হবে।
  • বিরোধ সমাধান: কোনও প্যাচে বিরোধের মার্কার নেই তা যাচাই করুন।
  • বিল্ড যাচাইকরণ: সম্পূর্ণ কমিট চেইন অবশ্যই সফলভাবে বিল্ড করতে হবে।

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

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

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

অগ্রাধিকার ও ESRT

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

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

নিম্নলিখিত সারণীতে বাগের প্রায়রিটি ও সমাধানের সময় (ESRT) ম্যাপ করা আছে:

অগ্রাধিকারESRT
P0২ ব্যবসায়িক দিবস
P1৫ কর্মদিবস
P2১০ ব্যবসায়িক দিন
P3১৫ কর্মদিবস

SLA নীতি

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

আবার স্পিন করার অনুরোধ জমা দিন

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

জরুরি রেস্পিন প্রসেস ছবি ১.জরুরি রেস্পিন প্রসেস।

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

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

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

    • জমা দেওয়ার পরে পর্যালোচনা করার প্রসেস:

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

    • রিলিজ:

      • ci.android.com-এ বাইনারি রিলিজ করা হয়েছে।
      • ESRT সময়সীমা শেষ হয়ে যায় এবং Google GKI টিম অনুরোধটিকে সমাধান করা হয়েছে হিসেবে চিহ্নিত করে এবং রিস্পিন বিল্ডের রেফারেন্স দেয়।
      • এছাড়াও, রেস্পিন বিল্ড Generic Kernel Image (GKI) রিলিজ বিল্ড পৃষ্ঠায় পোস্ট করা হয়।