درخواست تجدید نظر

ریسپین (Respin) فرآیند ادغام مجدد، بازسازی، آزمایش مجدد و تأیید مجدد یک فایل باینری پس از انتشار عمومی هسته GKI است.

قبل از درخواست تمدید، به نکات زیر توجه کنید.

واجد شرایط بودن و چرخه عمر

  • زمان‌بندی: شما می‌توانید درخواست respins را فقط در شاخه‌های انتشار پس از انتشار عمومی اولیه یک نسخه سه‌ماهه ارائه دهید. درخواست‌های respin برای vendor-hooks یا سایر ویژگی‌ها را فقط برای یک شاخه انتشار مشخص، حداکثر تا شش ماه پس از انتشار عمومی اولیه، درخواست کنید.
  • امنیت و LTS: پس از شش ماه، شعب فقط برای وصله‌های امنیتی ذکر شده در بولتن امنیتی اندروید (ASB) یا رفع اشکالات بحرانی واجد شرایط لغو اشتراک هستند.
  • منسوخ شدن: وقتی الزامات LTS، که توسط بولتن امنیتی اندروید (ASB) تعریف شده است، باعث عدم انطباق شاخه شود، شاخه منسوخ می‌شود. درخواست‌های Respin برای شاخه‌های منسوخ شده پذیرفته نمی‌شوند.
    • تاریخ انقضا برای یک شاخه انتشار GKI مشخص، در یادداشت‌های ساخت انتشار فصلی GKI در بخش «انتشارات» درج شده است. برای مثال، انتشار سپتامبر ۲۰۲۵ تا مارس ۲۰۲۷ برای به‌روزرسانی‌های مجدد پشتیبانی می‌شود. این تاریخ نشان دهنده طول عمر ۱۸ ماهه نسخه هسته LTS 2.0 برای انتشارهایی است که از سپتامبر ۲۰۲۵ شروع می‌شوند (انتشارهای قبل از سپتامبر ۲۰۲۵ طول عمر ۱۲ ماهه داشتند).
  • محدوده: فقط برای رفع اشکالات فوری، به‌روزرسانی‌های فهرست نمادها یا اعمال وصله برای رفع مشکل یک ویژگی موجود، درخواست تعویق کنید.

استانداردهای ارسال پچ

برای برآورده کردن زمان استاندارد مورد انتظار برای حل مشکل (ESRT) برای پردازش درخواست respin، تمام وصله‌های ارسالی به شاخه انتشار باید از قوانین فنی زیر پیروی کنند.

منبع حقیقت و گزیده‌های ناب

  • شاخه توسعه ابتدا: تمام پچ‌هایی که به شاخه انتشار سه‌ماهه می‌روند باید از قبل در شاخه توسعه اصلی GKI ادغام شده باشند. برای مثال، اگر پچی برای respin android15-6.6-2025-08 مورد نیاز است، باید از قبل در android15-6.6 ادغام شده باشد.
  • انتخاب دقیق: شما باید پچ‌ها را مستقیماً از شاخه توسعه انتخاب کنید. از شاخه‌های انتشار دیگر انتخاب نکنید (برای مثال، از 2025-08 تا 2025-09 انتخاب نکنید)، زیرا این کار می‌تواند منجر به اطلاعات نویسنده یا کامیت شود که با نسخه موجود در شاخه توسعه مغایرت دارد. پچ‌هایی با اطلاعات مغایر پذیرفته نخواهند شد.
  • حفظ فراداده: فراداده‌های کامیت اصلی (مثلاً نام نویسنده، تاریخ انتشار اصلی) را حفظ کنید. برای حفظ فراداده‌ها git cherry-pick -x استفاده کنید.

زنجیره کامیت

  • زنجیره‌ی متوالی: اگر درخواست respin شامل چندین پچ است، آنها را به صورت یک زنجیره‌ی متوالی از کامیت‌ها آپلود کنید.
  • قرار دادن ABI و KMI: اگر یک به‌روزرسانی چند-پچ شامل به‌روزرسانی‌های رابط ماژول هسته (KMI) و رابط دودویی برنامه (ABI) باشد (برای مثال، تغییرات فهرست نمادها یا به‌روزرسانی‌های فایل XML/STG)، این کامیت‌ها را در انتهای زنجیره کامیت قرار دهید.
  • ریبیس کردن: اگر یک کامیت والد را در زنجیره ویرایش کنید، باید تمام پچ‌های فرزند را روی آخرین نسخه پچ والد آن ریبیس کنید تا از خرابی در ساخت جلوگیری شود.
  • حل تعارض: تأیید کنید که هیچ نشانگر تعارضی در هیچ وصله‌ای وجود ندارد.
  • تأیید ساخت: کل زنجیره کامیت باید با موفقیت ساخته شود.

برچسب‌های مورد نیاز

پیشرفت درخواست respin بدون تگ‌های زیر در پیام کامیت مسدود می‌شود:

  • Change-Id : باید با Change-Id تغییر شاخه توسعه (development branch) یکسان باشد.
  • Bug (موجود): Bug: XYZ از کامیت شاخه توسعه اصلی نباید حذف شوند.
  • Bug (respin): شما باید یک برچسب جدید Bug: XYZ اضافه کنید، که در آن XYZ مربوط به شناسه اشکال مرتبط با درخواست respin فعلی است.
  • در صورت لزوم، برچسب کامیت UPSTREAM را به‌روزرسانی کنید: هنگام انتخاب یک CL از شاخه توسعه به شاخه انتشار، و CL با برچسب UPSTREAM مشخص شده است، سناریوهای زیر را در نظر بگیرید:
    • اگر CL به طور کامل در شاخه release اعمال شود، نیازی به انجام هیچ اقدام اضافی ندارید.
    • اگر CL به طور کامل اعمال نمی‌شود، تداخل‌ها را برطرف کنید، برچسب را به BACKPORT به‌روزرسانی کنید و آنچه را که به عنوان بخشی از حل تداخل انجام شده است، مستند کنید. به الزامات مربوط به backports از mainline Linux مراجعه کنید.

اولویت و ESRT

برای کمک به تیم GKI در اولویت‌بندی، یک اولویت (فوریت) به درخواست respin اختصاص دهید. این اولویت به تیم GKI کمک می‌کند تا به موقع و بهتر به شرکا کمک کند.

  • برای درخواست‌های حیاتی یا حساس به زمان، اولویت را با P0 علامت‌گذاری کنید.
  • برای درخواست‌های P0 و P1 ، باید فوریت را نیز توجیه کنید.

جدول زیر، نگاشتی از اولویت اشکال و زمان لازم برای رفع آن (ESRT) را ارائه می‌دهد:

اولویت ESRT
پ0 ۲ روز کاری
پی۱ ۵ روز کاری
پی۲ ۱۰ روز کاری
پ3 ۱۵ روز کاری

سیاست‌های SLA

  • برای هر شاخه انتشار، یک درخواست respin جداگانه ارسال کنید.
  • اگر تغییراتی در درخواست respin دارید که به عنوان رفع‌شده علامت‌گذاری شده است، یک درخواست respin جدید ارسال کنید. درخواست اضافه کردن لیست تغییرات (CL) اضافی را دوباره باز نکنید.
  • اگر درخواست respin نیاز به پاسخ شما داشته باشد و شما ظرف سه روز کاری پاسخ ندهید، اولویت یک سطح کاهش می‌یابد، برای مثال، P0 به P1 تنزل می‌یابد.
  • اگر به مدت دو هفته پاسخی ندهید، اشکال به صورت «رفع نخواهد شد (منسوخ شده)» علامت‌گذاری می‌شود.

ارسال درخواست ریسپین

نمودار زیر فرآیند respin را نشان می‌دهد. این فرآیند زمانی آغاز می‌شود که شریک OEM (شما) درخواست respin را ارسال می‌کند.

فرآیند ریسیدن اضطراری شکل ۱. فرآیند ریسیدن اضطراری.

برای ارسال درخواست respin:

  1. فرم درخواست تغییر رمز عبور GKI را پر کنید و فوراً با نماینده گوگل خود تماس بگیرید.

    • این فرم یک باگ درخواست respin مربوط به GKI ایجاد می‌کند.

  2. پچ‌هایتان را آماده کنید:

    • تأیید کنید که پچ در شاخه توسعه GKI ادغام شده است.
    • وصله را به شاخه انتشار GKI مناسب اعمال کنید.
    • وصله منتخب را اصلاح کنید تا شامل برچسب Bug: XYZ با ذکر شناسه درخواست respin باشد.

    مثال: برای انتخاب یک CL از android16-6.12 تا android16-6.12-2025-12 به صورت Cherry-pick:

    # 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 درخواست را بررسی کرده و آن را تأیید می‌کند یا در صورت نیاز به اطلاعات بیشتر، آن را به شما ارجاع می‌دهد.
      • پس از توافق بر سر یک اصلاحیه، تیم کد گوگل GKI تغییر را بررسی می‌کند. تایمر ESRT در طول این بررسی فعال است. با این حال، اگر اصلاحیه رد شود یا نیاز به کار مجدد داشته باشد، تایمر ESRT دوباره تنظیم می‌شود.
      • تیم GKI ادغام، ساخت، آزمایش رگرسیون و تأیید تغییر را انجام می‌دهد.

    • انتشار: