Meminta putaran ulang

Respin adalah proses penggabungan ulang, pembangunan ulang, pengujian ulang, dan sertifikasi ulang biner setelah rilis publik kernel GKI.

Sebelum meminta putaran ulang, perhatikan panduan berikut.

Kelayakan dan siklus proses

  • Waktu: Anda hanya dapat meminta putaran ulang pada cabang rilis setelah rilis publik awal build kuartalan diluncurkan. Minta permintaan respin untuk vendor-hook atau fitur lain hanya untuk cabang rilis tertentu selama maksimum enam bulan setelah rilis publik awal.
  • Keamanan dan LTS: Setelah enam bulan, cabang memenuhi syarat untuk respin hanya untuk patch keamanan yang dikutip dalam Android Security Bulletin (ASB) atau perbaikan bug penting.
  • Penghentian penggunaan: Jika persyaratan LTS, yang ditentukan oleh Android Security Bulletin (ASB), menyebabkan cabang tidak patuh, cabang tersebut tidak digunakan lagi. Permintaan re-spin untuk cabang yang tidak digunakan lagi tidak diterima.
    • Tanggal penghentian untuk cabang rilis GKI tertentu disertakan dalam catatan build rilis GKI per kuartal di bagian Rilis. Misalnya, rilis September 2025 didukung untuk respin hingga Maret 2027. Tanggal ini mencerminkan masa aktif versi kernel LTS 2.0 selama 18 bulan untuk rilis yang dimulai pada September 2025 (rilis sebelum September 2025 memiliki masa aktif 12 bulan).
  • Cakupan: Minta putaran ulang hanya untuk perbaikan bug mendesak, pembaruan daftar simbol, atau untuk menerapkan patch guna memperbaiki fitur yang ada.

Standar pengiriman patch

Untuk memenuhi Waktu Penyelesaian Standar yang Diharapkan (ESRT) untuk pemrosesan permintaan respin, semua patch yang dikirimkan ke cabang rilis harus mematuhi aturan teknis berikut.

Sumber kebenaran dan pilihan

  • Cabang pengembangan terlebih dahulu: Semua patch yang masuk ke cabang rilis per kuartal harus sudah digabungkan ke cabang pengembangan GKI utama. Misalnya, jika patch diperlukan untuk respin android15-6.6-2025-08, patch tersebut harus sudah digabungkan ke android15-6.6.
  • Pengambilan perbaikan bersih: Anda harus mengambil perbaikan patch langsung dari cabang pengembangan. Jangan memilih-milih dari cabang rilis lain (misalnya, jangan memilih dari 2025-08 ke 2025-09), karena hal ini dapat menyebabkan informasi penulis atau commit yang tidak konsisten dengan versi di cabang pengembangan. Patch dengan informasi yang tidak konsisten tidak akan diterima.
  • Pertahankan metadata: Pertahankan metadata commit asli (misalnya, penulis, stempel waktu asli). Gunakan git cherry-pick -x untuk mempertahankan metadata.

Rantai commit

  • Rantai berurutan: Jika permintaan respin melibatkan beberapa patch, upload patch tersebut sebagai rantai commit berurutan tunggal.
  • Penempatan ABI dan KMI: Jika respin multi-patch mencakup update antarmuka modul kernel (KMI) dan antarmuka biner aplikasi (ABI) (misalnya, perubahan daftar simbol atau update file XML/STG), tempatkan commit ini di paling akhir rantai commit.
  • Mengubah basis: Jika Anda mengedit commit induk dalam rantai, Anda harus mengubah basis semua patch turunan di atas revisi terbaru patch induknya untuk menghindari kegagalan build.
  • Penyelesaian konflik:Pastikan tidak ada penanda konflik dalam patch apa pun.
  • Verifikasi build: Seluruh rangkaian commit harus berhasil di-build.

Tag wajib

Proses permintaan putar ulang diblokir tanpa tag berikut dalam pesan commit:

  • Change-Id: Harus sama dengan Change-Id perubahan cabang pengembangan.
  • Bug (yang ada): Tag Bug: XYZ yang ada dari commit cabang pengembangan asli tidak boleh dihapus.
  • Bug (respin): Anda harus menambahkan tag Bug: XYZ baru, dengan XYZ sesuai dengan ID Bug yang terkait dengan permintaan respin saat ini.
  • Perbarui tag commit UPSTREAM jika perlu: Saat memilih CL dari cabang pengembangan ke cabang rilis, dan CL diberi tag sebagai UPSTREAM, pertimbangkan skenario berikut:
    • Jika CL diterapkan dengan baik ke cabang rilis, Anda tidak perlu melakukan tindakan tambahan apa pun.
    • Jika CL tidak diterapkan dengan baik, perbaiki konflik, perbarui tag ke BACKPORT, dan dokumentasikan apa yang telah dilakukan sebagai bagian dari penyelesaian konflik, lihat Persyaratan untuk backport dari Linux utama.

Prioritas dan ESRT

Tetapkan prioritas (urgensi) untuk permintaan putaran ulang guna membantu tim GKI memprioritaskan. Prioritas ini membantu tim GKI memberikan bantuan yang lebih baik kepada partner secara tepat waktu.

  • Untuk permintaan penting atau mendesak, tandai prioritas sebagai P0.
  • Untuk permintaan P0 dan P1, Anda juga harus menjelaskan urgensinya.

Tabel berikut memberikan pemetaan prioritas bug dan waktu penyelesaian (ESRT):

PrioritasESRT
P02 hari kerja
P15 hari kerja
P210 hari kerja
P315 hari kerja

Kebijakan SLA

  • Kirimkan permintaan putaran ulang terpisah untuk setiap cabang rilis.
  • Jika Anda memiliki perubahan pada permintaan putar ulang yang ditandai sebagai telah diperbaiki, kirimkan permintaan putar ulang baru. Jangan membuka kembali permintaan untuk menambahkan daftar perubahan (CL) tambahan.
  • Jika permintaan putaran ulang memerlukan respons Anda, dan Anda tidak merespons dalam waktu tiga hari kerja, prioritas akan diturunkan satu tingkat, misalnya, P0 diturunkan menjadi P1.
  • Jika Anda tidak merespons selama dua minggu, bug akan ditandai sebagai Tidak Akan Diperbaiki (Tidak Berlaku).

Mengirim permintaan putaran ulang

Diagram berikut menunjukkan proses respin. Proses dimulai saat partner OEM (Anda) mengirimkan permintaan respin.

Proses respin darurat Gambar 1.Proses respin darurat.

Untuk mengirim permintaan putaran ulang:

  1. Isi formulir permintaan respin GKI dan segera hubungi kontak (POC) Google Anda.

    • Formulir ini membuat bug permintaan respin GKI.

  2. Siapkan patch Anda:

    • Pastikan patch digabungkan ke cabang pengembangan GKI.
    • Terapkan patch ke cabang rilis GKI yang sesuai.
    • Ubah patch yang dipilih untuk menyertakan tag Bug: XYZ yang mengutip ID permintaan respin.

    Contoh: Untuk memilih CL dari android16-6.12 ke 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. Kirimkan bug. Berikut yang terjadi setelah Anda mengirimkan permintaan:

    • Proses Peninjauan setelah pengajuan dilakukan:

      • Tim GKI Google akan meninjau permintaan dan menyetujuinya atau menetapkannya kembali kepada Anda jika diperlukan informasi lebih lanjut.
      • Setelah perbaikan disepakati, tim GKI Google akan meninjau kode perubahan tersebut. Timer ESRT aktif selama peninjauan ini. Namun, jika patch ditolak atau memerlukan pengerjaan ulang, timer ESRT akan direset.
      • Tim GKI menggabungkan, membuat, menguji regresi, dan mensertifikasi perubahan.

    • Rilis: