Apakah Claude Menambah Bug di rsync?

• Rilis yang dibantu Claude hanya ada dua, rsync v3.4.2 dan v3.4.3, dan tidak ada bukti bahwa keduanya memiliki bug yang luar biasa banyak dibanding rilis historis jika diukur dengan bug berbobot keparahan per 10 commit
• sev/10c adalah metrik utama yang menormalkan skor keparahan bug ke rentang 0–1, menjumlahkannya per rilis, lalu membaginya dengan jumlah commit dan mengonversinya menjadi nilai per 10 commit
• v3.4.2 memiliki 50 commit, 9 commit Claude, 0 bug, dan 0.00 sev/10c, sedangkan v3.4.3 memiliki 34 commit, 28 commit Claude, 17 bug, dan 3.29 sev/10c; keduanya berada di sisi berlawanan dari IQR dan tidak satu pun merupakan outlier
• Nilai p dari uji permutasi eksak adalah 46%, nilai p dari uji eksak Fisher adalah 74%, dan rasio odds adalah 1.06, sehingga hampir tidak ada sinyal bahwa rilis Claude lebih buruk daripada dua rilis acak atau lebih mungkin berada di atas median
• v3.4.1 adalah rilis sebelum adopsi Claude, tetapi tetap menjadi nilai terburuk di seluruh data dengan 59 bug, 9 commit, dan 39.39 sev/10c; inti kontroversi rsync adalah mengaitkan satu regresi tunggal dengan Claude tanpa mempertimbangkan distribusi historis

---

Latar belakang dan pertanyaan

• Pada akhir Mei 2026, kontroversi rsync dimulai dari sebuah postingan Mastodon yang menghubungkan regresi v3.4.3 dengan commit Claude di rilis tersebut, lalu menyebar ke Hacker News dan issue GitHub "Please Do Not Vibe Fuck Up This Software"; issue itu mengumpulkan lebih dari 300 komentar
• Klaim inti yang berulang adalah bahwa pengembangan yang dibantu Claude memasukkan bug ke alat yang sebelumnya stabil, dan pertanyaan datanya adalah apakah rilis yang dibantu Claude memiliki bug jauh lebih banyak daripada rilis historis
• Di Lobsters, ada permintaan untuk melihat jumlah regresi per rilis dalam bentuk grafik waktu, dan fokus analisisnya adalah satu pertanyaan: “Apakah rilis yang dibantu Claude memiliki bug yang luar biasa banyak?”

Cakupan data dan reproduksibilitas

• Data mencakup 36 rilis dari v2.4.6 hingga v3.4.3 pada RsyncProject/rsync yang memiliki data bug, dan hanya ada dua rilis dengan commit Claude: v3.4.2 dan v3.4.3
• Pemilihan metrik, metodologi, dan sumber data dilakukan langsung oleh manusia, dengan masukan dari pasangan penulis yang bergelar magister statistika
• Pengumpulan data, pemuatan ke DuckDB, pembuatan view, dan skrip analisis statistik ditulis oleh GLM 5.1, tetapi semua angka, statistik, kartu, dan grafik dimasukkan otomatis oleh skrip Python yang menjalankan analisis statistik
• Repositori reproduksi alexispurslane/rsync-analysis dapat menjalankan seluruh pipeline dari awal sampai akhir

Metrik dan cara atribusi bug

• Metrik intinya adalah bug berbobot keparahan per 10 commit, yaitu sev/10c, dengan rumus sev/10c = (Σ severity/100 ÷ total_commits) × 10
• Commit diurutkan berdasarkan committer date pada branch utama, dan rentang tiap rilis diambil dari tag sebelumnya hingga tag tersebut; tag pre dan rc dikecualikan sebagai batas dan diserap ke rilis final
• Sumber bug berasal dari tiga tempat: issue GitHub, Bugzilla rsync, dan mailing list rsync; untuk issue GitHub dan bug dari mailing list, bug diatribusikan ke rilis terbaru yang sudah dirilis tepat sebelum waktu pelaporan
• Entri Bugzilla memiliki field “Version” yang menyatakan rilis tempat bug dilaporkan, sehingga diatribusikan ke rilis tersebut
• Alasan memilih analisis tingkat rilis adalah karena kritiknya sendiri berbentuk “seluruh rilis yang memiliki commit Claude menjadi lebih banyak bug”, dan sebagian besar bug tidak secara eksplisit menyebut berasal dari commit mana

Cara penilaian keparahan

• Semua laporan bug dinilai oleh Qwen 3 35B dengan skor keparahan 0–100, menggunakan prompt yang memberinya peran senior reliability engineer dari sudut pandang dampak ke pengguna nyata
• Skor 90–100 mencakup korupsi data senyap, kehilangan data, eksekusi kode jarak jauh, atau kerentanan keamanan dengan akses tidak sah; 70–89 mencakup crash, hang, kegagalan backup, dan kegagalan build; 50–69 mencakup regresi fungsional yang bisa diakali
• Untuk Bugzilla dan mailing list, karena hanya ada judul tanpa isi, model menilai berdasarkan judul saja, dan bila informasinya tidak cukup, ia diarahkan agar cenderung ke rentang tengah 40–60
• Output dibatasi ke integer severity saja melalui JSON schema dari structured output, dan temperature dikunci di 0 agar input yang sama menghasilkan skor yang sama
• Issue yang mendapat skor 0, seperti permintaan fitur, spam, protes nonteknis terkait AI, atau kiriman kosong, dikeluarkan dari jumlah bug dasar

Hasil statistik untuk rilis Claude

• v3.4.2 memiliki 9 commit Claude dari total 50 commit, 0 bug nyata, 0.00 sev/10c, dan berada di persentil 0
• v3.4.3 memiliki 28 commit Claude dari total 34 commit, 17 bug, 3.29 sev/10c, dan berada di persentil 77
• IQR historis adalah 0.29–2.59 sev/10c; v3.4.2 berada tepat di bawah IQR, sedangkan v3.4.3 tepat di atasnya, sehingga kedua rilis itu menjepit distribusi tengah dari sisi yang berlawanan
• Uji permutasi eksak menghasilkan nilai p 46%, karena dari 595 kombinasi yang mungkin untuk dua rilis, ada 272 yang memiliki rata-rata grup Claude sebesar 1.65 sev/10c atau lebih tinggi
• Uji eksak Fisher memeriksa apakah rilis Claude lebih sering berada di atas median 0.74 sev/10c, dan menghasilkan nilai p 74% serta rasio odds 1.06

Jumlah commit dan skala perubahan

• Rata-rata rilis Claude memiliki 42 commit, sedangkan rilis tanpa Claude memiliki rata-rata 185 commit, dan peluang dua rilis acak memiliki jumlah commit setidaknya sebanyak itu adalah 88%
• Berdasarkan GitHub compare API, rata-rata baris perubahan pada rilis Claude adalah 3.756 baris, sedangkan rilis tanpa Claude 696 baris, dan peluang dua rilis acak memiliki jumlah baris perubahan setidaknya sebanyak itu adalah 5%
• Jumlah bug berbobot keparahan rata-rata pada rilis Claude adalah 5,6, sedangkan pada rilis tanpa Claude adalah 14,9, dan peluang dua rilis acak memiliki jumlah bug berbobot keparahan setidaknya sebanyak itu adalah 77%
• Kesimpulannya, rilis Claude memang memiliki jauh lebih banyak baris perubahan, tetapi tidak memiliki lebih banyak commit atau lebih banyak bug berbobot keparahan

Sistem versi dan outlier yang sudah ada sebelumnya

• Rata-rata rilis v2.x adalah 1.11 sev/10c, sedangkan rata-rata rilis v3.x adalah 4.23 sev/10c, sehingga v3.x menunjukkan tingkat bug yang lebih tinggi
• Bahkan jika hanya membandingkan v3.x, rilis Claude tetap berada di kelompok tengah atau lebih baik; agar Claude terlihat seperti outlier, perbandingan harus dilakukan dengan era lama yang lebih tenang, sehingga perubahan yang sudah terjadi sebelum Claude justru dibebankan ke Claude
• Wald–Wolfowitz runs test pada 35 rilis tanpa Claude menghasilkan 13 run teramati, nilai harapan acak 18,5 run, z=-1.88, p=0.060, yang tidak cukup kuat untuk menolak keacakan pada ambang 0,05
• v3.4.1 adalah rilis sebelum Claude diadopsi, tetapi mencatat tingkat bug tertinggi di seluruh data dengan 59 bug, 9 commit, dan 39.39 sev/10c
• v3.4.1 adalah rilis hotfix yang keluar sehari setelah v3.4.0, dan menunjukkan tingkat bug tertinggi yang melampaui semua rilis lain dengan selisih dua digit, pada masa ketika belum ada AI yang bisa disalahkan

Interpretasi dan keterbatasan

• Interpretasi yang sesuai dengan data adalah bahwa “dua rilis Claude saat ini tidak dapat dibedakan secara statistik dari rilis historis”
• v3.4.3 memang cukup tinggi pada 3.29 sev/10c dan berada di persentil 77, tetapi bukan nilai ekstrem, karena ada 8 rilis historis dengan skor lebih tinggi
• Klaim bahwa “Claude jelas membuat keadaan lebih buruk” tidak didukung oleh distribusi rilis, uji permutasi, maupun uji Fisher
• Sebaliknya, data ini juga tidak mendukung kesimpulan bahwa “commit Claude secara umum tidak akan membuat keadaan lebih buruk di masa depan”; datanya hanya menunjukkan bahwa dua rilis saat ini masih berada dalam rentang yang biasa
• Metrik ini punya keterbatasan sebagai alat yang kasar karena tidak mengendalikan kompleksitas commit atau intensitas pekerjaan keamanan

Faktor perancu yang dibahas

• Seorang pengguna di Hacker News berpendapat bahwa perbaikan keamanan untuk merespons CVE tampaknya mengungkap kesalahan pengkodean yang sudah ada dalam kode sejak 2007
• Seorang pengguna di Lobsters mengusulkan rantai kausal “LLM → kenaikan issue keamanan yang diketahui → perlu lebih banyak perubahan daripada biasanya → lebih banyak regresi daripada biasanya”
• Andrew Tridgell menjelaskan bahwa banjir laporan CVE buatan AI menuntut perubahan yang cepat dan luas pada permukaan serangan rsync
• Jika faktor perancu ini juga diperhitungkan, maka masalahnya tampak lebih dekat ke meningkatnya pekerjaan keamanan dan volume perubahan yang mengikutinya, bukan ke Claude itu sendiri

[GN⁺]

Opini di Lobste.rs

• Menurut saya, tiap orang boleh memutuskan sendiri apakah akan terus memakai proyek FOSS yang ke depannya dikembangkan dengan vibe coding. Namun, kemarahan yang ditunjukkan komunitas setelah maintainer beralih ke alat vibe coding cukup mengejutkan, dan data empiris dalam tulisan itu setidaknya membantu memberi konteks yang lebih baik terhadap perubahan praktik tersebut
  Apakah kepercayaan akan tetap terjaga atau justru makin runtuh setelah maintainer mengadopsi cara coding ini, baru akan terlihat seiring waktu

  • Saya penasaran, dari orang-orang yang marah soal peralihan ini, berapa banyak yang benar-benar berkontribusi secara berarti ke rsync atau menyumbang dana

• Analisis ini persis seperti yang saya harapkan, bahkan lebih. Saya terutama suka bagian “semua metrik, metodologi, dan sumber data saya pilih sendiri setelah berkonsultasi dengan istri saya yang bergelar master statistika dari Penn State University”, dan keterlibatan ahli statistik sungguhan serta cara penyajiannya yang mudah dibaca sangat bagus
  Katanya dipakai satu metrik tunggal, yaitu “jumlah bug per 10 commit”, padahal ini kesempatan yang terlewat untuk memakai prefiks SI dan menyebutnya decibugs per commit

  • Setuju. Ini bukan tulisan saya, tetapi saya suka karena ada orang yang melampaui perdebatan panas pro-kontra dan menunjukkan dampaknya pada kualitas kode dengan data

• Keberhasilan proyek open source terlalu dipengaruhi persepsi sampai-sampai orang membeli bintang GitHub dengan uang. Sayangnya, masalah persepsi kali ini sudah lepas kendali dan menjadi sebuah talking point, dan data apa pun akan sulit mengubahnya
  Ke depannya, kalimat seperti “maintainer rsync memakai LLM lalu semuanya rusak” akan dipakai skeptikus AI bersama talking point seperti “pusat data membuang 500 ribu galon air bersih per hari” dan “riset METR mengatakan LLM menurunkan produktivitas”
  Saya tidak sedang bilang apakah saya seorang skeptikus AI atau bukan, hanya bahwa perdebatan soal topik ini biasanya berjalan seperti itu

  • Kenapa itu disebut “talking point”, bukankah itu cuma fakta?
  • Saya tidak yakin penulis berusaha meyakinkan seseorang dengan data. Saya melihat tulisan ini sebagai upaya memberi konteks berbasis data pada perdebatan sengit soal adopsi alat oleh rsync
    Namun memang benar bahwa unsur-unsur nonkuantitatif lain sepenuhnya tidak dibahas dalam tulisan itu, dan mungkin itu sengaja karena kebisingan dari pihak evangelis maupun skeptis sudah lebih dari cukup

• Sangat penting, dan juga sesuai dugaan, bahwa rilis terburuk dalam sejarah rsync terjadi sebelum Claude diadopsi, dengan 39,39 bug per 10 commit
  Jika proses seperti pengujian dan quality assurance antara pengguna dan pengembang tidak mampu menjamin ketepatan perangkat lunak, maka bug tetap akan dirilis baik ada LLM maupun tidak. LLM bisa merugikan proses ini, tapi juga bisa membantu

  • Setuju. Tulisan terbaru cURL tampaknya menunjukkan contoh dari sisi sebaliknya
    Berkat praktik rekayasa perangkat lunak yang kuat dan sudah mapan selama bertahun-tahun, nilai penggunaan alat AI serupa untuk menemukan bug secara keseluruhan menjadi lebih rendah
  • Saya punya beberapa kekhawatiran soal masa depan rsync. Masalah terbesarnya adalah rsync pada dasarnya sudah menjadi proyek yang selesai selama beberapa tahun, tetapi setelah memakai AI mereka mencabut kode pengujian lama dan menggantinya dengan test suite Python, serta tidak menjalankan pengujian lama secara paralel untuk memverifikasi ketepatan selama periode yang cukup lama
    Menurut standar saya, itu tidak bertanggung jawab. Terutama karena tujuan utama rsync adalah memindahkan data berharga, dan integritas data tersebut mutlak penting

• Saya berharap retorika seperti “seperti khas pengguna anti-AI, pada akhirnya ini meningkat menjadi fantasi kekerasan” dihindari. Itu bukan cuma menggeneralisasi sebagian orang yang tidak disetujui penulis, tetapi juga membuat pembaca yang sejak awal tidak setuju jadi semakin antipati, sehingga justru orang-orang yang paling perlu membaca tulisan itu malah tidak membacanya
  Terlepas dari itu, saya tidak terlalu peduli apakah bug-nya lebih banyak atau lebih sedikit dibanding versi sebelumnya. Yang penting bagi saya adalah bahwa ini dikembangkan dengan cara yang tidak sejalan dengan pandangan saya tentang bagaimana perangkat lunak seharusnya dibuat. Jika tidak ada pemahaman dasar bahwa ada masalah selain efisiensi, saya tidak berharap bisa meyakinkan orang bahwa posisi ini masuk akal
  Untungnya, kalau saya tidak mau, saya tidak perlu memakai versi rsync ini, dan saya akan memilih alternatif yang bercabang dari sebelum penggunaan LLM

  • Tulisan ini terlalu penuh amarah, jadi saya tidak bisa membacanya lama-lama dan akhirnya menyerah. Akan lebih baik kalau penulis berusaha adil, atau setidaknya terlihat begitu
    Mengulang meme yang sebenarnya sudah lama dibantah—yaitu bahwa laporan bug pertama adalah issue tempat orang-orang berbondong-bondong masuk—juga tidak membantu. Laporan bug pertama yang sebenarnya adalah yang lain

• Menurut saya, tulisan yang sekarang ini jujur lebih baik. Hanya saja, bagian “metrik ini tidak bisa mengendalikan kompleksitas commit, sensitivitas keamanan, atau tingkat keparahan bug. Ini alat tumpul yang tidak bisa membedakan perbaikan typo satu baris dengan patch CVE” itu, dari posisi saya yang ada di kubu LLM itu buruk, justru meleset dari kritik utamanya
  Kritik yang saya dan orang lain ajukan adalah bahwa AI mendorong orang membanjiri repositori dengan commit yang lebih besar, lebih sulit dipahami, dan menambah kompleksitas. Para pendukung LLM juga sering mengatakan hal serupa, lalu menggeser tiang gawang dari praktik “membaca PR” yang sudah teruji puluhan tahun menjadi “LLM seharusnya bisa menguji semuanya”. Tetapi masalah bahwa kompleksitas kode adalah utang teknis tidak hilang
  Dalam kasus ini, tingkat keparahan bug-nya sangat tinggi. Karena workflow backup benar-benar rusak. rsync dipakai luas untuk backup, dan orang sudah lama mempercayainya sebagai alat yang “teruji di medan tempur”, sampai-sampai hampir tak terpikir bahwa update patch bisa merusak skrip backup
  Bisa saja dibilang bahwa LLM membuat software yang bug-nya hanya karena kebetulan, atau bahwa maintainer perlu mengubah alur kerja LLM dan meningkatkan cakupan pengujian. Memang maintainer juga mengatakan begitu. Tetapi inti kemarahannya adalah bahwa alat ini merusak kepercayaan tersebut
  Bahkan sekarang ada jenis baru programmer LLM yang berkata mereka “sama sekali tidak membaca kode”. Alasannya, membaca kode terlalu memakan waktu dan lebih rumit dipahami dibanding kode programmer biasa. Membaca kode itu berarti mempelajari model mental orang lain, tetapi alat LLM tidak bisa memberikan satu model mental yang konsisten
  Terpisah dari itu, aksesibilitas situs juga perlu dicek. Penglihatan saya cukup bagus dan saya masih di akhir usia 20-an, tetapi teks abu-abu terang di atas latar krem/kuning benar-benar menyakitkan untuk dibaca

  • Bagian yang dikutip ini membingungkan. Metrik yang dipakai di tulisan itu tampaknya memberi bobot tingkat keparahan pada jumlah bug per 10 commit; apakah penulisnya sedang bertentangan dengan dirinya sendiri? Atau saya yang salah baca?
  • Bagi orang-orang yang bilang workflow-nya rusak, saya rasa ini kesempatan bagus untuk belajar apa itu perangkat lunak open source dan lisensi GPL, serta jaminan apa yang sebenarnya diberikan
    Saya rasa orang tidak akan menemukan bug itu sendiri. Dugaan saya, lebih dari 90% pengguna rsync masih memakai versi lama yang belum memiliki bug itu. Saya juga termasuk salah satunya

    $ uname -a  
    Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64
    
    $ port info rsync  
    rsync @3.4.1 (net)  
    [...]  
    

    Kalau soal kenapa ini menarik perhatian, tidak perlu jadi Steven Pinker untuk paham bahwa cukup banyak komunitas sedang berada dalam kebingungan sekarang. Fakta bahwa LLM lebih baik daripada manusia dalam pemrograman bukanlah hal yang mudah diterima
    Orang-orang yang menaruh identitas dan harga diri mereka pada kemampuan atau profesi pemrograman kini menghadapi dua krisis sekaligus: ketidakpastian soal nafkah/nilai pasar masa depan, dan krisis identitas
    Ketakutan, ketidakpastian, dan keraguan sulit ditangani, dan perusahaan LLM sedang berusaha sekuat tenaga memperbesar efek itu demi menaikkan harga saham. Jika pasar terkoreksi tajam setelah Oktober, saya kira alat penguat seperti ini juga bisa melemah
    Dari seluruh programmer di dunia, hanya sebagian sangat kecil—yaitu mereka yang memandang kode sebagai bentuk seni—yang mungkin akan memakai LLM untuk berlatih dan meningkatkan keterampilan

• Tulisan ini banyak mengutip komentar yang menyebut regresi, tetapi analisisnya sendiri tidak mengukur regresi, melainkan hanya laporan bug. Ia mengaitkan bug ke rilis saat bug itu dilaporkan, bukan ke rilis saat bug itu diperkenalkan, dan mengukur tingkat keparahan rilis berdasarkan jumlah commit sambil mengabaikan faktor-faktor yang jelas seperti durasi rilis atau adopsi distribusi
  Saya tidak paham bagaimana ini bisa masuk akal

• Secara pribadi saya menghindari proyek yang memakai LLM. Bukan karena ada alasan praktis yang kuat, melainkan karena rasanya sangat menjijikkan, mirip seperti ketika seseorang memakai kata-kata seperti “kek” atau “fren” dan saya langsung menganggap itu sinyal bahwa saya tidak ingin berinteraksi lagi, bahkan tanpa alasan khusus
  Penjelasan yang sekarang muncul untuk membenci penggunaan LLM terasa seperti rasionalisasi yang ditempel belakangan. Kekhawatiran saat ini soal etika, kualitas, dan sebagainya memang valid, tetapi meskipun masalah-masalah itu diselesaikan, saya rasa orang seperti saya yang cenderung anti-AI tidak akan tiba-tiba merasa baik-baik saja
  Karena itu saya menghindari proyek dengan AGENTS.md, commit yang ditulis bersama Claude, dan semacamnya tanpa alasan yang spesifik. Rasanya saja tidak enak dan tidak sesuai selera saya, ada bug atau tidak pun tidak penting. Saya rasa ada orang lain yang merasakan hal serupa

• Untuk penulisnya, pertama, fantasi itu adalah ujaran. Secara praktis Anda sedang mengklaim bahwa itu berhenti pada ujaran, atau setidaknya Anda tidak sedang mengklaim ada eskalasi nonverbal
  Kedua, kalau mau membuat klaim seperti ini, Anda perlu bertanya kepada ahli statistik terdekat bagaimana cara mendukungnya. Hanya karena beberapa orang membuat postingan seperti itu bukan berarti itu secara bermakna mendukung klaim bahwa hal tersebut “tipikal”
  Pengamatan anekdotal saya yang juga tidak didukung statistik adalah bahwa pengguna “anti-AI” cenderung tidak merasa bahwa masuknya LLM ke tempat yang tidak membantu itu sebagai sesuatu yang brutal, melainkan lebih dekat ke rasa sedih

  • Kadang saya melihat tulisan yang sangat panjang dan rinci yang mencoba membantah sebagian penentang LLM, biasanya mereka yang bereaksi secara emosional dan sosial terhadap LLM. Sulit menjelaskan alasannya dengan jelas, tetapi tulisan seperti itu terasa sangat tidak tulus dan seperti memukul pihak yang lebih lemah
    Terlalu rinci sehingga sulit dibantah dari sudut pandang emosional, dan pada akhirnya terkesan berujung pada “LLM bukan masalahnya; kalau dipakai dengan benar itu hanya alat penguat. Penentang AI tidak mengerti apa-apa dan cuma takut tertinggal”
    Saya juga tidak ingin mereduksi pekerjaan para maintainer rsync menjadi sekadar bahan debat, jadi saya tidak tahu bagaimana saya bisa menyusun sanggahan yang meyakinkan
    Statistik di sini mungkin menarik dari sudut pandang pemeliharaan open source, tetapi kesimpulannya terasa condong aneh ke satu sisi, dan meninggalkan kesan bahwa open source ala GitHub bukanlah bentuk kontribusi yang ingin saya lakukan
    Meski begitu, saya tetap berpikir bahwa tindakan beramai-ramai menyerbu maintainer di repositori rsync jelas tidak baik
  • Menyebut fantasi kekerasan publik sebagai sesuatu yang tidak bisa diterima itu benar. Itu bukan sesuatu yang layak dituju sebagai peradaban. Hanya saja saya terganggu ketika penulis menyebutnya “tipikal”, karena itu generalisasi
    Soal pengamatan anekdotal, rasanya komik ini benar. Saya suka melihat klaim yang konkret dan terukur, sebagian karena saya suka angka, dan juga karena itu membantu membuat diskusi online sedikit lebih dekat ke dunia ideal pada panel terakhir

• Terima kasih atas analisisnya, tetapi saya belum yakin dengan metodologinya. Saya penasaran dengan metrik seperti jumlah bug per unit perubahan yang mengalikan jumlah baris perubahan pada kode inti di setiap commit, yakni perubahan pada kode selain pengujian atau dokumentasi, serta analisis tentang waktu yang dibutuhkan untuk mencapai jumlah bug tertentu setelah rilis.
  Namun, karena rilis kali ini kemungkinan mendapat perhatian jauh lebih besar dibanding rilis lain sehingga lebih banyak bug dilaporkan, tampaknya sulit membuat metrik yang benar-benar meyakinkan. Pertanyaan seperti “apakah ini tergolong tipikal berdasarkan jumlah minggu setelah rilis?” juga mungkin tidak terlalu berguna.