Meminta putaran ulang

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

Sebelum meminta respin, perhatikan panduan berikut.

Kelayakan dan siklus proses

• Waktu: Anda hanya dapat meminta respin di cabang rilis setelah rilis publik awal build triwulanan diluncurkan. Kirim permintaan respin untuk vendor-hooks atau fitur lainnya hanya untuk cabang rilis tertentu selama maksimal enam bulan setelah rilis publik awal.
• Keamanan dan LTS: Setelah enam bulan, cabang hanya 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 respin untuk cabang yang tidak digunakan lagi tidak diterima.
  • Tanggal penghentian penggunaan untuk cabang rilis GKI tertentu disertakan dalam catatan build rilis GKI triwulanan 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 respin hanya untuk perbaikan bug mendesak, update 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 tepercaya dan cherry-pick

• Cabang pengembangan terlebih dahulu: Semua patch yang masuk ke cabang rilis triwulanan 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.
• Cherry-pick bersih: Anda harus melakukan cherry-pick patch langsung dari cabang pengembangan. Jangan melakukan cherry-pick dari cabang rilis lainnya (misalnya, jangan memilih dari 2025-08 ke 2025-09), karena hal ini dapat menghasilkan 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 menyertakan update antarmuka modul kernel (KMI) dan antarmuka biner aplikasi (ABI) (misalnya, perubahan daftar simbol atau update file XML/STG), tempatkan commit ini di bagian paling akhir rantai commit.
• Rebasing: Jika Anda mengedit commit induk dalam rantai, Anda harus melakukan rebase semua patch turunan di atas revisi terbaru patch induknya untuk menghindari kegagalan build.
• Penyelesaian konflik: Pastikan tidak ada penanda konflik di patch mana pun.
• Verifikasi build: Seluruh rantai commit harus berhasil di-build.

Tag wajib

Progres permintaan respin diblokir tanpa tag berikut dalam pesan commit:

• Change-Id: Harus sama dengan Change-Id perubahan cabang pengembangan.
  • Pengecualian: Jika patch digabungkan ke cabang pengembangan sebagai bagian dari update LTS, patch tersebut harus merupakan cherry-pick dari versi LTS dan diformat sebagai patch UPSTREAM. Lihat Cara mengirimkan patch ke Kernel Umum Android.
• 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 diperlukan: Saat melakukan cherry-pick CL dari cabang pengembangan ke cabang rilis, dan CL ditandai sebagai UPSTREAM, pertimbangkan skenario berikut:
  • Jika CL diterapkan dengan bersih ke cabang rilis, Anda tidak perlu melakukan tindakan tambahan apa pun.
  • Jika CL tidak diterapkan dengan bersih, perbaiki konflik, perbarui tag ke BACKPORT, dan dokumentasikan apa yang dilakukan sebagai bagian dari penyelesaian konflik. Lihat Persyaratan untuk backport dari Linux utama.

Prioritas dan ESRT

Tetapkan prioritas (urgensi) ke permintaan respin untuk membantu tim GKI memprioritaskan. Prioritas ini membantu tim GKI membantu partner dengan lebih baik dan tepat waktu.

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

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

Prioritas	ESRT
P0	2 hari kerja
P1	5 hari kerja
P2	10 hari kerja
P3	15 hari kerja

Kebijakan SLA

• Kirim permintaan respin terpisah untuk setiap cabang rilis.
• Jika Anda memiliki perubahan pada permintaan respin yang ditandai sebagai diperbaiki, kirim permintaan respin baru. Jangan buka kembali permintaan untuk menambahkan daftar perubahan (CL) tambahan.
• Jika permintaan respin 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 Digunakan Lagi).

Mengirim permintaan respin

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

Gambar 1.Proses respin darurat.

Untuk mengirim permintaan respin:

1. Isi formulir permintaan respin GKI dan segera hubungi kontak 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 di-cherry-pick untuk menyertakan tag Bug: XYZ yang mengutip ID permintaan respin.

   Contoh: Untuk melakukan cherry-pick 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. Kirim bug. Hal berikut terjadi setelah Anda mengirimkan permintaan:

   • Proses Peninjauan setelah pengiriman terjadi:

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

   • Rilis:

     • Biner dirilis ke ci.android.com.
     • Jangka waktu ESRT berakhir dan tim GKI Google menandai permintaan sebagai diperbaiki dan mereferensikan build respin.
     • Build respin juga diposting di halaman build rilis Generic Kernel Image (GKI).