Claude, rsync'in hata sayısını artırdı mı?

• Claude destekli sürümler yalnızca rsync v3.4.2 ve v3.4.3 olmak üzere iki tane ve şiddet ağırlıklı hata/10 commit ölçütüne göre geçmiş sürümlere kıyasla alışılmadık derecede fazla hataya sahip olduklarını gösteren bir kanıt yok
• sev/10c, hata şiddeti puanlarını 0~1 aralığına normalize edip sürüm bazında toplayan, commit sayısına bölen ve ardından 10 commit başına değere çeviren temel metriktir
• v3.4.2, 50 commit·9 Claude commit'i·0 hata·0.00 sev/10c; v3.4.3 ise 34 commit·28 Claude commit'i·17 hata·3.29 sev/10c değerine sahip ve her ikisi de IQR'nin iki yanına yerleşiyor; hiçbiri aykırı değer değil
• Kesin permütasyon testi p-değeri %46, Fisher'ın kesin testi p-değeri %74 ve odds ratio 1.06; yani Claude sürümlerinin rastgele seçilmiş 2 sürümden daha kötü olduğu ya da medyanı aşma olasılığının daha yüksek olduğuna dair neredeyse hiçbir sinyal yok
• v3.4.1, Claude kullanılmadan önceki bir sürüm olmasına rağmen 59 hata·9 commit·39.39 sev/10c ile tüm veri kümesindeki en kötü değerdi; rsync tartışmasının özü, tarihsel dağılım olmadan tek bir regresyonu Claude ile ilişkilendirmekti

---

Arka plan ve soru

• Mayıs 2026'nın sonlarında rsync tartışması, v3.4.3 regresyonunu ve bu sürümdeki Claude commit'lerini ilişkilendiren bir Mastodon gönderisiyle başladı; ardından Hacker News'e ve GitHub'daki "Please Do Not Vibe Fuck Up This Software" başlıklı issue'ya yayıldı ve bu issue'da 300'den fazla yorum birikti
• Tekrarlanan temel iddia, Claude destekli geliştirmenin daha önce istikrarlı olan bir araca hata soktuğu yönündeydi; veri açısından soru ise Claude destekli sürümlerin tarihsel sürümlere göre anormal derecede fazla hataya sahip olup olmadığıydı
• Lobsters'ta sürüm bazında regresyon sayılarının zaman grafiğiyle gösterilmesi istendi ve analiz tek bir soruya odaklandı: “Claude destekli sürümler alışılmadık derecede fazla hata mı içeriyor?”

Veri kapsamı ve yeniden üretilebilirlik

• Veri, RsyncProject/rsync'in v2.4.6'dan v3.4.3'e kadar hata verisi bulunan 36 sürümünü kapsıyor; Claude commit'i içeren sürümler ise yalnızca v3.4.2 ve v3.4.3
• Metrik, metodoloji ve veri kaynağı seçimleri doğrudan insan tarafından yapıldı ve istatistik yüksek lisans derecesine sahip eşin tavsiyeleri yansıtıldı
• Veri toplama, DuckDB'ye yükleme, view oluşturma ve istatistik analiz betikleri GLM 5.1 tarafından yazıldı; ancak tüm sayılar, istatistikler, kartlar ve grafikler, istatistik analizini çalıştıran Python betiği tarafından otomatik şablonlarla eklendi
• Yeniden üretim için alexispurslane/rsync-analysis deposu, tüm pipeline'ı baştan sona çalıştırabiliyor

Metrikler ve hata atama yöntemi

• Temel metrik, şiddet ağırlıklı hata/10 commit anlamına gelen sev/10c olup hesaplama formülü sev/10c = (Σ severity/100 ÷ total_commits) × 10 şeklindedir
• Commit'ler ana dalda committer date sırasına göre dizildi; her sürüm aralığı bir önceki tag'den ilgili tag'e kadar olan commit'ler olarak alındı ve pre·rc tag'leri sınırdan hariç tutularak nihai sürüme dahil edildi
• Hata kaynakları üç taneydi: GitHub issue'ları, rsync Bugzilla ve rsync e-posta listesi; GitHub issue'ları ve e-posta listesi hataları, raporlama anından hemen önce dağıtılmış en son sürüme atandı
• Bugzilla kayıtlarında “Version” alanı hatanın raporlandığı sürümü açıkça belirttiği için hata o sürüme atandı
• Sürüm bazlı analizin seçilme nedeni, eleştirinin bizzat “Claude commit'i içeren sürümlerin tamamı daha hatalı hale geldi” biçiminde olması ve çoğu hatanın tam olarak hangi commit'ten kaynaklandığının belirtilmemesiydi

Şiddet değerlendirme yöntemi

• Tüm hata raporları, Qwen 3 35B tarafından 0~100 arası bir şiddet puanıyla değerlendirildi; prompt, gerçek kullanıcı etkisi perspektifinden kıdemli bir güvenilirlik mühendisi rolü veriyordu
• 90~100 puan sessiz veri bozulması·veri kaybı·uzaktan kod çalıştırma veya yetkisiz erişim güvenlik açıkları; 70~89 puan çökme·takılma·yedekleme başarısızlığı·build başarısızlığı; 50~69 puan ise aşılabilir işlev gerilemeleri olarak sınıflandırıldı
• Bugzilla ve e-posta listesi kayıtlarında gövde metni yerine yalnızca başlık bulunduğundan model sadece başlığa bakarak değerlendirme yaptı; bilgi yetersizse 40~60 puanlık orta aralığa eğilim göstermesi istendi
• Çıktı, structured output için JSON schema kullanılarak yalnızca tam sayı şiddet puanlarına izin verecek şekilde sınırlandı ve aynı girdinin aynı puanı üretmesi için temperature 0'a sabitlendi
• Özellik isteği, spam, AI ile ilgili teknik olmayan şikayetler ve boş gönderimler gibi 0 puan alan issue'lar temel hata sayısından çıkarıldı

Claude sürümlerinin istatistiksel sonuçları

• v3.4.2, 50 commit'in 9'unda Claude commit'i içeriyordu; gerçek hata sayısı 0, sev/10c değeri 0.00 ve yüzdelik konumu 0 idi
• v3.4.3, 34 commit'in 28'inde Claude commit'i içeriyordu; 17 hata, 3.29 sev/10c ve 77. yüzdelik dilimdeydi
• Tarihsel IQR 0.29~2.59 sev/10c aralığındaydı; v3.4.2 IQR'nin hemen altında, v3.4.3 ise hemen üstünde yer alıyor; yani iki sürüm orta dağılımı karşıt uçlardan çevreliyor
• Kesin permütasyon testi, mümkün olan 595 adet 2 sürümlük kombinasyonun 272'sinin Claude grubunun ortalaması olan 1.65 sev/10c veya üzerinde olduğunu gösterdi ve p-değerini %46 olarak verdi
• Fisher'ın kesin testi, medyan 0.74 sev/10c eşiğine göre Claude sürümlerinin medyanı daha sık aşıp aşmadığına baktı ve p-değeri %74, odds ratio ise 1.06 çıktı

Commit sayısı ve değişiklik boyutu

• Claude sürümleri ortalama 42 commit içeriyordu; Claude içermeyen sürümler ise ortalama 185 commit ve rastgele seçilen 2 sürümün en az bu kadar ya da daha fazla commit'e sahip olma olasılığı %88'di
• GitHub compare API'ye göre değişen satır sayısı, Claude sürümlerinde ortalama 3.756 satır; Claude içermeyen sürümlerde ise ortalama 696 satırdı ve rastgele 2 sürümün en az bu kadar ya da daha fazla değişen satıra sahip olma olasılığı %5'ti
• Şiddet ağırlıklı hata sayısı, Claude sürümlerinde ortalama 5.6; Claude içermeyen sürümlerde ise ortalama 14.9'du ve rastgele 2 sürümün en az bu kadar ya da daha fazla şiddet ağırlıklı hataya sahip olma olasılığı %77'ydi
• Sonuç olarak Claude sürümleri çok daha fazla değişen satır içeriyordu, ancak ne commit sayısı ne de şiddet ağırlıklı hata sayısı daha yüksekti

Sürüm düzeni ve önceden var olan aykırı değerler

• v2.x sürümlerinin ortalaması 1.11 sev/10c, v3.x sürümlerinin ortalaması ise 4.23 sev/10c idi; yani v3.x tarafında daha yüksek bir hata oranı görülüyordu
• Yalnızca v3.x karşılaştırıldığında bile Claude sürümleri orta sıralarda veya daha iyi konumdaydı; Claude'u aykırı değer gibi göstermek için daha sakin bir geçmiş dönemle kıyaslamak ve aslında Claude'dan önce gerçekleşmiş değişimi Claude'a yüklemek gerekiyor
• Wald–Wolfowitz runs test, Claude içermeyen 35 sürümde gözlenen 13 run, rastgele beklenen 18.5 run, z=-1.88 ve p=0.060 sonucunu verdi; bu da 0.05 eşiğinde rastgeleliği reddedecek kadar güçlü değil
• v3.4.1, Claude kullanılmadan önceki bir sürüm olmasına rağmen 59 hata·9 commit·39.39 sev/10c ile tüm veri kümesindeki en yüksek hata oranına sahip sürümdü
• v3.4.1, v3.4.0'dan sonraki gün çıkan bir hotfix sürümüydü; diğer tüm sürümleri tek haneli farkların çok ötesinde geride bırakan en yüksek hata oranına sahipti, ancak o dönemde suçu AI'ya atacak bir hedef yoktu

Yorum ve sınırlamalar

• Verilerle uyumlu yorum, “şu anki iki Claude sürümü tarihsel sürümlerden istatistiksel olarak ayırt edilemiyor” yönündedir
• v3.4.3, 3.29 sev/10c ile 77. yüzdelik dilimde olduğu için yüksek sayılabilir, ancak uç bir değer değildir; tarihsel olarak bundan daha yüksek puan alan 8 sürüm vardır
• “Claude kesin olarak daha kötü hale getirdi” iddiası; ne sürüm dağılımı, ne permütasyon testi, ne de Fisher testi tarafından destekleniyor
• Tersine, “Claude commit'leri genel olarak gelecekte de daha kötü hale getirmez” sonucu da bu veriden çıkmıyor; mevcut bulgu yalnızca bu iki sürümün sıradan aralıkta kaldığıdır
• Bu metrik, commit karmaşıklığını veya güvenlik çalışmalarının yoğunluğunu kontrol edemeyen kaba bir araç olma sınırlamasına sahip

Tartışılan karıştırıcı etkenler

• Hacker News'teki bir kullanıcı, CVE yanıtı kapsamında yapılan güvenlik düzeltmelerinin 2007'den beri kodda bulunan programlama hatalarını görünür hale getirmiş olabileceğini düşündü
• Lobsters'taki bir kullanıcı, “LLM → bilinen güvenlik sorunlarında artış → normalden fazla değişiklik ihtiyacı → normalden fazla regresyon” şeklinde bir nedensellik zinciri önerdi
• Andrew Tridgell, AI tarafından üretilen CVE raporu selinin rsync'in saldırı yüzeyinde hızlı ve kapsamlı değişiklikler gerektirdiğini açıkladı
• Bu karıştırıcı etkenler de hesaba katıldığında, sorun Claude'un kendisinden ziyade daha fazla güvenlik çalışması ve buna bağlı artan değişiklik hacmi gibi görünüyor

[GN⁺]

Lobste.rs görüşleri

• Bundan sonra vibe coding ile yürütülecek FOSS projelerini kullanmaya devam edip etmeyeceğine herkesin kendisinin karar verebileceğini düşünüyorum. Ancak bakımcının vibe coding araçlarına geçmesinden sonra topluluğun gösterdiği öfke oldukça şaşırtıcıydı ve yazıdaki ampirik veriler en azından bu pratik değişikliğinin etkisini daha iyi bağlama oturtuyor
  Bakımcı bu kodlama yaklaşımını benimsedikten sonra güvenin korunup korunmayacağını ya da daha da aşınıp aşınmayacağını zaman gösterecek

  • Bu geçişe öfkelenenler arasında gerçekten rsync’e anlamlı katkı yapmış ya da para vermiş kaç kişi olduğunu merak ediyorum

• Bu analiz tam da görmek istediğim şeydi, hatta daha fazlasıydı. Özellikle “tüm metrikleri, metodolojiyi ve veri kaynaklarını Penn State University’de istatistik yüksek lisansı yapmış eşimle görüşerek bizzat seçtim” kısmını beğendim; gerçek bir istatistik uzmanını sürece dahil etmiş olmaları ve bunu okunması kolay bir yazıya dönüştürmeleri harika
  “10 commit başına hata sayısı” gibi tek bir metrik kullandıklarını söylüyorlar ama SI öneki kullanıp buna commit başına desihata (decibugs) deme fırsatını kaçırmış gibiler

  • Katılıyorum. Yazı benim değil ama birinin hararetli lehte/aleyhte tartışmaların ötesine geçip kod kalitesine etkisini verilerle göstermesi hoşuma gitti

• Açık kaynak projelerin başarısı algıya fazlasıyla bağlı; öyle ki insanlar GitHub yıldızlarını para verip satın alıyor. Ne yazık ki bu algı sorunu artık kontrolden çıkıp başlı başına bir talking point hâline geldi ve bunu herhangi bir verinin değiştirmesi zor
  Bundan sonra “rsync bakımcısı LLM kullandı ve her şeyi bozdu” sözü, “veri merkezleri günde 500 bin galon temiz suyu israf ediyor”, “METR araştırması LLM’lerin üretkenliği düşürdüğünü söyledi” gibi başlıklarla birlikte AI şüphecilerinin öne süreceği bir nokta olacak
  AI şüphecisi olup olmadığımı söylemeye çalışmıyorum; sadece bu konudaki tartışmaların genelde böyle aktığını söylüyorum

  • Bu neden bir “talking point” olsun ki, düpedüz gerçek değil mi?
  • Yazarın verilerle birilerini ikna etmeye çalışıp çalışmadığından emin değilim. Bence bu yazı, rsync’in araç benimsemesi etrafındaki hararetli tartışmaya veri bağlamı ekliyor
    Ama yazıda nicel olmayan diğer unsurların tamamen dışarıda bırakıldığı da doğru; muhtemelen hem evangelistlerin hem de şüphecilerin gürültüsü zaten yeterince fazla olduğu için bunu bilerek yaptı

• rsync tarihindeki en kötü sürümün Claude devreye girmeden önce çıkmış olması ve 10 commit başına 39,39 hata düşmesi çok önemli ve beklenen bir sonuç
  Kullanıcı ile geliştirici arasında test, kalite güvencesi gibi süreçler yazılımın doğruluğunu garanti etmiyorsa, ortada LLM olsun ya da olmasın, hatalı yazılım yayımlanır. LLM bu süreçte zararlı da olabilir, faydalı da

  • Katılıyorum. cURL’ün yakın tarihli yazısı karşı taraftan bir örnek gösteriyor gibi
    Zaten yıllardır yerleşmiş güçlü yazılım mühendisliği pratikleri sayesinde, benzer AI araçlarıyla hata bulmanın değeri genel olarak daha düşük kalmış
  • rsync’in geleceğiyle ilgili bazı endişelerim var. En büyük sorun, rsync’in aslında yıllardır fiilen tamamlanmış bir proje olması ama AI kullanılmaya başlanınca mevcut test kodunun sökülüp yerine Python test paketi getirilmesi ve uzun bir süre eski testlerin paralel çalıştırılarak doğruluğun doğrulanmaması
    Bana göre bu sorumsuzluk. Özellikle de rsync’in temel amacının değerli verileri taşımak olduğu ve bu verilerin bütünlüğünün mutlak önem taşıdığı düşünülürse

• “AI karşıtı kullanıcılarda tipik olduğu gibi sonunda şiddet fantezisine kadar tırmandı” gibi ifadelerden kaçınılmasını isterdim. Bu, yazarın aynı fikirde olmadığı bazı insanları genelleştirmekle kalmıyor, baştan zaten katılmayan okurları da itiyor ve tam da yazıyı en çok okuması gereken kişilerin uzak durmasına yol açıyor
  Ayrı olarak, önceki sürümden daha fazla ya da daha az hata olması umurumda değil. Benim için önemli olan, yazılımın benim doğru bulduğum yazılım geliştirme anlayışıyla uyuşmayan bir şekilde geliştiriliyor olması. Verimlilik dışında da sorunlar olabileceğine dair temel bir kavrayış yoksa bu tutumun makul olduğunu insanlara anlatmayı beklemiyorum
  Neyse ki istemezsem rsync’in bu sürümünü kullanmak zorunda değilim ve LLM kullanılmadan önce çatallanmış bir alternatifi tercih edeceğim

  • Bu yazı o kadar öfke doluydu ki uzun süre okuyamadım, bırakmak zorunda kaldım. Adil olmaya çalışsa ya da en azından öyle görünse daha iyi olurdu
    Ayrıca, ilk hata raporunun insanların akın ettiği issue olduğu gibi çoktan çürütülmüş bir meme’i tekrarlaması da yardımcı olmadı. Gerçekte ilk hata raporu farklıydı

• Bence yazı şu an dürüst olmak gerekirse daha iyi. Yine de “bu metrik commit karmaşıklığını, güvenlik hassasiyetini ve hata ciddiyetini kontrol edemiyor. Tek satırlık yazım hatası düzeltmesiyle CVE yamasını ayırt edemeyen kaba bir araç” kısmı, LLM'ler kötüdür tarafındaki benim konumumdan bakınca asıl eleştiriyi kaçırıyor.
  Benim ve başkalarının dile getirdiği eleştiri, yapay zekanın daha büyük, anlaşılması daha zor ve karmaşıklığı artıran commit'ler üretmeye yöneltmesi. LLM savunucuları da benzer şeyler söyleyip sonra, onlarca yıldır doğrulanmış “PR okuma” pratiğinden çıkıp kaleyi “LLM her şeyi test edebilmeli” noktasına taşıyor. Ama kod karmaşıklığının teknik borç olduğu gerçeği ortadan kalkmıyor.
  Bu vakada hatanın ciddiyeti çok yüksek. Çünkü yedekleme iş akışı gerçekten bozuldu. rsync yedeklemede yaygın biçimde kullanılıyor ve insanlar bunu o kadar “sahada kanıtlanmış” bir araç olarak gördü ki, bir yama güncellemesinin yedekleme betiklerini bozabileceğini hayal bile etmedi.
  LLM'in hatalı yazılım üretmesinin tesadüf olduğunu ya da bakımcının LLM iş akışını değiştirip test kapsamını artırması gerektiğini söyleyebilirsiniz. Nitekim bakımcı da bunu söyledi. Ama öfkenin özü, bu aracın o güveni kırmış olması.
  Gerçekten de bugünlerde “kodu hiç okumuyorum” diyen yeni bir LLM programcısı türü var. Sebebi, okumanın çok uzun sürmesi ve sıradan programcı koduna göre kavramasının daha karmaşık olması. Kod okumak, başkasının zihinsel modelini öğrenmektir; LLM araçları ise tek ve tutarlı bir zihinsel model sunamıyor.
  Ayrı olarak sitenin erişilebilirliği de kontrol edilmeli. Görüşüm oldukça iyi ve 20'li yaşlarımın sonundayım ama krem/sarı arka plan üstündeki açık gri yazıyı okumak gerçekten çok acı verici.

  • Alıntılanan kısım kafamı karıştırdı. Yazıdaki metrik, her 10 commit başına düşen hata sayısına ciddiyet ağırlığı vermiş gibi görünüyor; yazar kendi kendisiyle çelişiyor mu? Ben mi yanlış okudum?
  • İş akışının bozulduğunu söyleyenler için bunun, açık kaynak yazılımın ve GPL lisansının ne olduğunu ve ne tür güvenceler verdiğini öğrenmek adına iyi bir fırsat olduğunu düşünüyorum.
    İnsanların bu hatayı doğrudan kendilerinin keşfetmiş olduğunu sanmıyorum. rsync kullanıcılarının %90'ından fazlasının bu hatayı içermeyen eski bir sürümü kullandığını tahmin ediyorum. Ben de onlardan biriyim.

    $ 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)  
    [...]  
    

    İlgi çekmesinin nedeni buysa, şu anda topluluğun önemli bir kısmının kafa karışıklığı yaşadığını görmek için Steven Pinker olmaya gerek yok. LLM'lerin programlamada insanlardan daha iyi olduğu gerçeğini kabullenmek kolay değil.
    Kimliğini ve özsaygısını programlama becerisine ya da mesleğine dayandıran insanlar, gelecekteki geçim/ piyasa değeri konusundaki belirsizlik ve kimlik krizi olmak üzere iki krizle karşı karşıya.
    Korku, belirsizlik ve şüpheyle başa çıkmak zor; LLM şirketleri de hisse fiyatlarını yükseltmek için bunun etkisini büyütmek adına ellerinden geleni yapıyor. Ekim'den sonra piyasa sert biçimde düzeltirse bu büyütme mekanizmasının da zayıflayabileceğini düşünüyorum.
    Dünya çapındaki programcıların çok küçük bir yüzdesi, yani kodu bir sanat biçimi olarak görenler, muhtemelen LLM'leri eğitim ve beceri geliştirme için kullanacaktır.

• Bu yazı regresyondan bahseden yorumlardan çokça alıntı yapıyor ama analiz aslında regresyon değil, yalnızca hata raporlarını ölçüyor. Hataları, hatanın eklendiği sürüme değil bildirildiği sürüme bağlıyor ve sürümün ciddiyetini commit sayısıyla ölçerken sürüm süresi ya da dağıtım benimsenmesi gibi bariz etkenleri dışarıda bırakıyor.
  Bunun nasıl anlamlı olabildiğini anlayamıyorum.

• Kişisel olarak LLM kullanan projelerden kaçınıyorum. Bunun somut bir nedeni olduğundan değil; sadece bana çok itici geliyor. Birinin “kek” ya da “fren” gibi şeyler söylemesini, ortada özel bir neden olmasa bile artık o kişiyle etkileşmek istemediğime dair bir işaret saymama benziyor.
  Şu anda LLM kullanımını sevmemek için öne sürülen açıklamalar bana sonradan eklenmiş rasyonalizasyonlar gibi geliyor. Etik, kalite gibi mevcut kaygılar doğru olabilir ama bu sorunlar çözüldü diye benim gibi AI karşıtı eğilimdeki insanların bir anda bunu sorun etmemeye başlayacağını sanmıyorum.
  Bu yüzden “AGENTS.md”, Claude ortak yazarlı commit'ler vb. olan projelerden somut bir gerekçe olmadan uzak duruyorum. Sadece hoşuma gitmiyor, zevkime uymuyor; hata olsun ya da olmasın fark etmiyor. Başkalarının da benzer hissettiğini düşünüyorum.

• Yazara şunu söylemek isterim: Birincisi, fantezi sözdür. Fiiliyatta bunun sözde kaldığını iddia etmiş oluyor ya da en azından sözün sözel olmayan bir tırmanışa dönüştüğünü iddia etmiyor.
  İkincisi, böyle bir iddiada bulunacaksanız, yakındaki bir istatistik uzmanına bunun nasıl desteklenebileceğini sormanız gerekir. Birkaç kişinin böyle gönderiler paylaşmış olması, bunun “tipik” olduğu iddiasını anlamlı biçimde desteklemez.
  Benim istatistikle desteklenmemiş anekdotsal gözlemime göre “AI karşıtı” kullanıcılar, LLM'lerin işe yaramadığı yerlere sokulmasını çoğunlukla şiddetli bir şey olarak değil, daha çok üzücü bir şey olarak görüyor.

  • Bazen LLM karşıtlarının bir kısmına, genelde LLM'lere duygusal ve toplumsal tepki veren kesime karşı çok uzun ve ayrıntılı yazılar görüyorum. Nedenini net açıklamak zor ama bunlar bana çok kötü niyetli geliyor; sanki zayıfa vuruyor gibi.
    O kadar ayrıntılı oluyorlar ki duygusal açıdan karşı çıkmak zorlaşıyor ve sonuçta “Sorun LLM değil, doğru kullanılırsa bir yükselteçtir. AI karşıtları ne konuştuklarını bilmiyor, sadece geri kalmaktan korkuyor” noktasına varıyor gibi görünüyor.
    rsync bakımcılarının çalışmalarını tartışmaya indirgemek de istemediğim için, buna nasıl ikna edici bir karşı argüman kurabileceğimi bilmiyorum.
    Buradaki istatistikler açık kaynak bakım perspektifinden ilginç olabilir ama sonuç garip biçimde tek tarafa eğilmiş görünüyor ve GitHub tarzı açık kaynağın benim katkı vermek istediğim biçim olmadığı hissi kalıyor.
    Yine de rsync deposunda bakımcıya topluca yüklenilmesi hiç iyi değildi diye düşünüyorum.
  • Kamusal şiddet fantezisini kabul edilemez diye nitelemek doğru. Bu, uygarlık olarak hedeflememiz gereken bir şey değil. Ama yazarın bunu “tipik” diye adlandırdığı kısım, bir genelleme olduğu için rahatsız edici.
    Anekdotsal gözlem konusunda ise şu çizgi romanın haklı olduğunu düşünüyorum. Belirli ve ölçülebilir iddialar görmeyi seviyorum; biraz sayıları sevdiğim için, biraz da çevrimiçi tartışmaları son karenin ideal dünyasına biraz daha yaklaştırdığı için.

• Analiz için teşekkürler ama metodoloji konusunda ikna olmuş değilim. Her commit için çekirdek kodda, yani test veya dokümantasyon dışındaki kodda değişen satır sayısıyla çarpılmış fark birimi başına hata sayısı gibi bir metrik ve belirli bir hata sayısına ulaşmanın sürümden sonra ne kadar zaman aldığının analizi ilgimi çekiyor
  Yine de bu sürümün diğer sürümlere kıyasla çok daha fazla ilgi görmüş olması ve bu yüzden daha fazla hata bildirilmiş olma ihtimali yüksek; dolayısıyla gerçekten ikna edici bir metrik oluşturmak zor görünüyor. “Sürümden sonraki ilk birkaç hafta açısından tipik mi?” gibi sorular da pek faydalı olmayabilir