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

রেস্পিন হল GKI কার্নেল সর্বজনীনভাবে রিলিজ করার পরে বাইনারি আবার মার্জ, রিবিল্ড, রিটেস্ট ও রি-সার্টিফাই করার প্রসেস।

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

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

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

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

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

Source of truth এবং চেরি-পিক

  • প্রথমে ডেভেলপমেন্ট ব্রাঞ্চ: ত্রৈমাসিক রিলিজ ব্রাঞ্চে যাওয়া সব প্যাচ আগে থেকেই মূল 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 (রেস্পিন): আপনাকে অবশ্যই একটি নতুন 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) রিলিজ বিল্ড পৃষ্ঠায় পোস্ট করা হয়।