Linux 7.2: 16.418 Commit dari 2.652 Developer, Rilis Tersibuk Kedua

Linux 7.2 dirilis Linus Torvalds pada 17 Agustus 2026 dengan 16.418 non-merge commit dari 2.652 developer, menurut rekap LWN. Jumlah commit itu menjadikannya rilis tersibuk kedua dalam sejarah kernel setelah 6.7, dan jumlah developernya memecahkan rekor sebelumnya, 2.479 di 7.1. Siklus ini juga menambah hampir 600.000 baris kode.

Berapa besar siklus 7.2 dibanding rilis sebelumnya?

Dengan 16.418 non-merge commit, 7.2 melampaui 7.1 yang sudah tergolong sibuk. Hanya 6.7 yang lebih besar, dan lonjakan di 6.7 sebagian besar disebabkan masuknya riwayat pengembangan bcachefs. Pada 7.2, volume commit lebih tersebar di banyak subsistem, bukan hasil satu penggabungan raksasa.

Torvalds menyebut jumlah perbaikan yang masuk masih lebih besar dari yang ia harapkan. Itu bukan kalimat baru dalam pengumuman rilis kernel, tetapi konteksnya penting: siklus yang panjang dan padat biasanya diikuti siklus stabilisasi yang lebih ketat. Pengguna yang menunggu rilis stabil disarankan mengikuti changelog distribusi masing-masing, bukan hanya nomor versi.

Angka hampir 600.000 baris tambahan juga perlu dibaca dengan benar. Sebagian besar pertumbuhan baris datang dari file header dan kode yang dihasilkan mesin, bukan dari logika kernel yang ditulis tangan. Karena itu, metrik baris berguna untuk melihat beban review, tetapi tidak bisa dipakai sendirian untuk menilai kompleksitas perubahan.

Siapa kontributor terbesar di 7.2?

Uwe Kleine-König memimpin kolom changeset dengan 151 commit, sebagian besar berisi cleanup di subsistem driver. Rosen Penev berada di posisi kedua dengan 146 commit, termasuk daftar panjang perbaikan bug yang ditulis dengan bantuan LLM di berbagai subsistem. Ian Rogers dan Johan Hovold menyusul dengan 138 dan 133 commit.

Di kolom baris yang berubah, pemenangnya berbeda. Matthew Stewart mencatat 83.587 baris atau 8,4 persen dari total, sebagian besar dari file header amdgpu berukuran besar yang dihasilkan mesin. Hawking Zhang menyusul dengan 62.893 baris, juga dari amdgpu. Miguel Ojeda masuk tiga besar dengan 38.979 baris setelah membawa crate Rust zerocopy ke dalam source kernel.

Kontribusi lain yang disebut LWN antara lain driver suara MediaTek mt8196 dari Darren Ye, pekerjaan perf tool dari Ian Rogers dan Arnaldo Carvalho de Melo, serta perbaikan SPI dan USB dari Johan Hovold. Pola ini menunjukkan 7.2 bukan rilis satu tema, melainkan akumulasi pekerjaan rutin di banyak area.

Employer	Changeset	Porsi
Tidak diketahui	2.743	16,7 persen
Intel	1.512	9,2 persen
Google	1.191	7,3 persen
Red Hat	873	5,3 persen
AMD	813	5,0 persen
Qualcomm	767	4,7 persen
NVIDIA	535	3,3 persen
Meta	441	2,7 persen

LWN mengidentifikasi 249 employer yang mendukung pekerjaan 7.2. Kategori tidak diketahui tetap yang terbesar dengan 16,7 persen changeset, diikuti Intel, Google, Red Hat, dan AMD. Menariknya, di kolom baris berubah AMD memimpin jauh dengan 22,4 persen, efek dari header amdgpu yang masif.

Apakah budaya review kernel melemah?

Data 7.2 menunjukkan 48 persen commit membawa tag Reviewed-by dan sedikit di atas 8 persen membawa Tested-by. LWN mencatat tag review menunjukkan tren menurun ringan dalam beberapa rilis terakhir, tetapi apakah itu berarti jumlah review nyata berkurang masih belum jelas.

Ada beberapa penjelasan yang mungkin. Pertama, jumlah commit tumbuh lebih cepat daripada jumlah reviewer aktif, sehingga rasio tag otomatis turun. Kedua, sebagian perubahan, terutama file header yang dihasilkan mesin, memang tidak melewati review mendalam yang sama. Ketiga, pelaporan tag bergantung pada disiplin maintainer, dan tidak semua tag tercatat dengan cara yang sama.

Yang bisa diukur adalah beban reviewer teratas. Konrad Dybcio menambahkan tag review ke 231 perubahan, Dmitry Baryshkov 225, Andy Shevchenko 175, dan Geert Uytterhoeven 171. Keduanya, Dybcio dan Baryshkov, juga berada di puncak daftar 7.1, jadi beban review memang terkonsentrasi di sekelompok orang yang sama.

Kenapa 7.2 jadi rilis tersibuk kedua?

Jawaban singkatnya adalah volume pekerjaan yang tersebar, bukan satu penggabungan besar. Pada 6.7, rekor commit sebagian besar didorong oleh masuknya riwayat pengembangan bcachefs. Pada 7.2, tidak ada satu subsistem yang menyumbang mayoritas commit, sehingga kenaikannya mencerminkan aktivitas rutin di seluruh pohon kernel.

Pola ini terlihat dari daftar kontributor. Pemenang changeset hanya menyumbang 0,9 persen dari total, dan sepuluh kontributor teratas bersama-sama tidak mendominasi. Artinya, ribuan developer lain masing-masing mengirim beberapa commit. Distribusi seperti ini lebih sehat untuk proyek jangka panjang, tetapi juga membuat beban review tersebar ke lebih banyak maintainer.

Dari sisi employer, konsentrasi tetap ada. Intel, Google, Red Hat, AMD, dan Qualcomm adalah penyumbang terbesar yang teridentifikasi. Namun 16,7 persen changeset masuk kategori tidak diketahui, dan 4,5 persen masuk kategori none. Itu berarti sebagian besar pekerjaan tetap datang dari individu atau organisasi yang tidak mudah dipetakan ke perusahaan besar.

Siapa yang paling banyak menguji?

Dan Wheeler memimpin kolom Tested-by dengan 117 tag atau 7,0 persen, terutama dari pekerjaannya menguji patch driver grafis AMD. Di belakangnya ada Luiz Capitulino dengan 54 tag, James Clark dan Sarthak Sharma masing-masing 44, lalu Venkat Rao Bagalkote dengan 32.

Angka ini menunjukkan satu hal yang sering terlewat dalam diskusi kontribusi open source. Menulis kode bukan satu-satunya bentuk kontribusi. Menguji patch orang lain, terutama di hardware yang sulit diakses, punya bobot besar dalam menjaga kualitas rilis. Tanpa penguji seperti ini, patch driver grafis dan perangkat tertentu bisa masuk tanpa verifikasi nyata.

Di sisi review, nama-nama seperti Dybcio, Baryshkov, Shevchenko, dan Uytterhoeven muncul berulang. Mereka menangani sebagian besar review untuk driver dan devicetree, area yang volumenya tinggi dan sering berubah. Konsentrasi ini efisien, tetapi juga menjadi risiko kalau salah satu dari mereka kehabisan waktu.

Apa artinya buat pengguna Linux?

Bagi pengguna biasa, angka statistik ini tidak mengubah pengalaman harian secara langsung. Yang terasa adalah perubahan di driver, dukungan perangkat baru, dan perbaikan bug yang masuk lewat rilis stabil distribusi. 7.2 menjadi basis bagi kernel yang nantinya dipakai distro, jadi isi siklus ini akan sampai ke pengguna dalam beberapa bulan.

Bagi pengguna hardware baru, siklus yang padat biasanya berarti lebih banyak perangkat yang didukung. Kontribusi driver dari AMD, Intel, Qualcomm, dan MediaTek adalah bagian dari itu. Namun dukungan awal sering belum matang, jadi menunggu satu atau dua rilis stabil tetap saran yang masuk akal untuk perangkat produksi.

Bagi developer kernel, statistik ini berguna untuk melihat di mana beban kerja menumpuk. Area dengan sedikit reviewer dan banyak patch adalah tempat di mana bantuan paling dibutuhkan. Kalau ingin berkontribusi, menguji atau me-review patch di subsistem yang kekurangan tangan sering lebih berdampak daripada menambah fitur baru.

Apakah 7.2 punya satu tema besar?

Tidak. Berbeda dari rilis yang identik dengan satu fitur besar, 7.2 lebih merupakan akumulasi pekerjaan di banyak area. LWN menyoroti beberapa kontribusi spesifik, seperti crate Rust zerocopy yang masuk ke source kernel dan driver suara MediaTek mt8196, tetapi tidak ada satu perubahan yang mendominasi seluruh siklus.

Ketidakadaan tema besar bukan masalah. Kernel sudah berumur lebih dari tiga dekade dan mencakup terlalu banyak hardware untuk bergerak dengan satu narasi. Yang lebih penting adalah apakah laju perbaikan bug dan review tetap sehat. Di situlah angka seperti 8 persen Tested-by dan 48 persen Reviewed-by menjadi sinyal yang perlu dipantau antar rilis.

Bagaimana data ini dikumpulkan?

Angka di artikel LWN berasal dari LWN Kernel Source Database, yang mengolah riwayat git kernel dan memetakan penulis commit ke employer berdasarkan domain email dan afiliasi yang diketahui. Metode ini menjelaskan mengapa ada kategori tidak diketahui dan none: sebagian penulis memakai email pribadi atau tidak mencantumkan afiliasi.

Karena sumbernya riwayat git, angka changeset dihitung dari commit non-merge yang masuk ke mainline. Commit merge tidak dihitung agar satu perubahan tidak terhitung berkali-kali. Perubahan baris dihitung dari diff, sehingga file yang dihasilkan mesin tetap menyumbang angka besar meski logikanya sedikit.

Keterbatasan metode ini perlu dipahami. Pertama, tag Tested-by dan Reviewed-by hanya terhitung kalau maintainer mencantumkannya di commit message. Kedua, employer mapping bisa salah kalau penulis berpindah perusahaan atau memakai email yang tidak dikenal. Ketiga, angka changeset tidak mengukur bobot teknis sebuah perubahan: satu commit bisa berisi perbaikan satu baris atau refactor besar.

Karena itu, statistik seperti ini paling berguna untuk melihat tren dan distribusi, bukan untuk menilai kualitas individu. LWN sendiri menyajikan angka dengan konteks, misalnya menjelaskan bahwa puncak baris di 7.2 berasal dari header amdgpu yang dihasilkan mesin.

Untuk perbandingan antar rilis, cara paling konsisten adalah memakai definisi yang sama: commit non-merge di mainline, periode dari merge window sampai rilis, dan pemetaan employer yang diperbarui. Tanpa definisi seragam, angka bisa terlihat naik atau turun hanya karena metode penghitungan berubah.

Sumber utama

Rekap lengkap ada di LWN: Development statistics for the 7.2 kernel. Riwayat rilis dan pengumuman kernel tersedia di kernel.org, sedangkan pohon sumber Torvalds bisa dilihat di git.kernel.org.

FAQ

Kapan Linux 7.2 dirilis?

Linus Torvalds merilis Linux 7.2 pada 17 Agustus 2026. Pengumuman itu mencatat jumlah perbaikan yang masuk masih lebih besar dari yang ia harapkan.

Berapa developer yang berkontribusi di 7.2?

Sebanyak 2.652 developer, memecahkan rekor sebelumnya 2.479 developer di rilis 7.1. Mereka mengirim 16.418 non-merge commit.

Rilis kernel mana yang paling sibuk?

6.7 masih yang paling sibuk, sebagian besar karena masuknya riwayat pengembangan bcachefs. Linux 7.2 berada di posisi kedua dengan volume yang lebih tersebar.

Apakah review kernel benar-benar menurun?

Tag Reviewed-by menunjukkan tren turun ringan, tetapi penyebabnya belum jelas. Bisa karena jumlah commit tumbuh lebih cepat, bisa karena perubahan yang dihasilkan mesin, bisa juga karena pelaporan tag yang tidak konsisten.

Mengapa perubahan baris sangat besar?

Sebagian besar berasal dari file header amdgpu berukuran besar yang dihasilkan mesin. Matthew Stewart dan Hawking Zhang masing-masing menyumbang puluhan ribu baris dari area itu.