Linux 7.2 ve "Yeni Normal": Tarihi Koru, Revert'i Ucuzlat

Linus Torvalds, Linux 7.2 sürümünü 16 Ağustos Pazar günü, takvime uygun şekilde yayınladı. Özellik listesi sağlam. Ama benim aklım daha çok duyuru metninin kendisinde kaldı. Son hafta yine istediğinden büyük geçti. Torvalds buna rağmen, son anda yapılan birkaç revert ile sürümü çıkardı. Gerekçesi şu: artık "yeni normal" dediği yoğun yama hacmi altında, büyük bir hafta yüzünden sürüm ertelemek büyük ihtimalle hiç sürüm çıkaramamak anlamına gelirdi. Kernel, bu ölçekteki bir projenin yapay zekâ kaynaklı değişiklik hacmiyle nasıl baş ettiğini gösteriyor. Cevap kahramanlık değil, sürüm disiplini.

Neler geldi#

Phoronix'in ve The Register'ın sürüm haberinin verdiği bilgilere göre öne çıkanlar şunlar:

• Cache Aware Scheduling. AMD EPYC 5 ve Intel Xeon 6 gibi çok çekirdekli çiplerde kernel'ın cache'lerde zaten duran veriyi daha iyi kullanmasını sağlıyor.
• Intel'in geliştirdiği USB4STREAM protokolü, AMDGPU HDMI 2.1 FRL ve Intel ile AMD tarafında ek sürücü çalışmaları.
• Hem AMD hem Intel sistemlerde I/O performans iyileştirmeleri, daha hızlı poll performansı ve Intel Arc B390 grafiklerde kazanımlar.
• Linux'u Apple M3 cihazlarda çalıştırmayı mümkün kılan çalışmalar.
• AppleTalk desteğinin ve ARCNet ağlarında kullanılan eski ISA ve PCMCIA adaptörlerinin desteğinin kaldırılması.

Phoronix'e göre Ubuntu 26.10 ve yakında çıkacak başka dağıtımlar 7.2 kullanacak. The Register bir hafta önce 7.2'nin bir long-term support sürümü olmadığını da not etmişti. Yani çoğumuz bu sürümle bir dağıtım kernel'ı üzerinden tanışacağız.

"Yeni normal" nereden çıktı#

Bu ifade sürümden önce de kullanılıyordu. Torvalds 2 Ağustos'ta rc6'nın "yeni normal" standartlarına göre bile büyük olduğunu, en azından commit sayısına bakılırsa muhtemelen yıllardır görülen en büyük rc6 olduğunu söyledi. Bir hafta sonra rc7'yi duyururken boyuttan pek memnun olmadığını belirtti ve bunu yeni normale bağladı. The Register'ın rc7 haberine göre ortada çok sayıda düzeltme vardı ve bunların çoğu çeşitli yapay zekâ araçlarıyla yapılan incelemelerden geliyordu. Aynı haberde Torvalds'ın daha önce kernel güvenlik mail listesinin yapay zekâ üretimi hata bildirimleri yüzünden neredeyse yönetilemez hale geldiğinden yakındığı da hatırlatılıyor. Bu bildirimlerin çoğu mükerrerdi. Torvalds bununla birlikte Linux'un yapay zekâ karşıtı bir proje olmadığını da söylemişti.

Yani yük aynı anda iki biçimde geliyor. Bir yanda yapay zekâ kodlama araçlarını kullanan geliştiricilerden daha fazla katkı var. Öbür yanda mevcut kodun yapay zekâyla incelenmesinden doğan daha fazla düzeltme var. Ben her gün birkaç coding agent'ı paralel çalıştırıyorum ve bu etkiyi çok daha küçük bir ölçekte tanıyorum. Kod yazmak darboğaz olmaktan çıkıyor. Neyin merge'e hazır olduğuna karar vermek darboğaz oluyor.

Tarihi tut, hazır olmayanı revert et#

7.2 duyurusundaki iki karar örnek alınmaya değer.

Birincisi, tarih kaymadı. Torvalds açık konuştu: yoğun bir hafta erteleme sebebi sayılsaydı "muhtemelen hiç sürüm çıkaramazdık." Zamana dayalı bir sürüm modeli ancak hacim tarihi oynatamıyorsa işe yarar. Oynayan şey kapsam olur.

İkincisi, son dakika revert'leri olağan bir araç olarak görülüyor. Bu döngüde en çok göze çarpanı şuydu: DRM scheduler yeni bir "fair" varsayılana geçmişti, bu bir regresyona yol açtı ve son haftada tekrar FIFO'ya döndürüldü. Torvalds, revert etmenin şık görünmeyebileceğini ama hazır olmadığı anlaşılan kodu ele almanın doğru yolu olduğunu, ilgililerin daha sonra yeniden deneyeceğini söyledi. Revert, fikir hakkında verilmiş bir hüküm değil. Sadece değişikliği bu sürümden çıkarıyor.

Bu yaklaşım ancak revert ucuzsa işler. Birçok ürün reposunda ise ucuz değil, çünkü tek bir merge içinde bir refactor, bir davranış değişikliği ve bir bağımlılık güncellemesi bir arada geliyor.

Bir ekip reposunda neyi değiştirirdim#

Agent'ların yazdığı PR'lar birikirken pazartesi planlama toplantısına şunları götürürdüm:

• Bir PR, revert edilebilir tek bir birim. Squash-merge kullanın, agent PR'larını küçük ve tek amaçlı tutun, bir agent'ın refactor ile davranış değişikliğini aynı pakete koymasına izin vermeyin. Bir revert birbiriyle ilgisiz beş şeye dokunuyorsa, baskı altında kimse onu yapmaz.
• Revert kuralını yazıya dökün. Stabilizasyon penceresinde bir regresyon önce revert edilir, sonra düzeltmesiyle birlikte yeniden merge edilir. "Neredeyse düzeldi" tartışması yapılmaz.
• Değişen varsayılanları en riskli son dakika değişikliği sayın. DRM revert'ü de yeni bir varsayılandı. Yeni varsayılanları bir flag arkasına koyun ki geri almak kod değişikliği değil, config değişikliği olsun.
• Makinenin bulduğu hataları insanlar görmeden önce tekilleştirin. Yapay zekâ inceleme araçları issue açıyorsa bir reproduction ya da fail eden bir test şartı koyun, triage'dan önce de mükerrerleri gruplayın. Kernel güvenlik listesi bunun uyarısı.
• Bir merge son tarihi koyun. Torvalds 7.3 merge penceresi için şimdiden 40 bekleyen pull request'i olduğunu söyledi ve kendi PR'larını zamanında gönderenlere teşekkür etti. Tarihin sabit kalmasını sağlayan şey, hem insanların hem agent'ların uyduğu bir son tarih.

Benim yorumum#

Linux 7.2'nin ilginç yanı yapay zekânın hacmi artırmış olması değil. Kernel'ın buna yavaşlayarak ya da hacme daha fazla güvenerek karşılık vermemesi. Takvimi korudu ve revert etmeyi rutin hale getirdi. Bu, geliştirdiğim review CLI'ı Quorate'in arkasındaki fikre yakın: agent çıktısı merge edilmeden önce deterministik kontrollerden geçmek zorunda ve FAIL tartışma konusu değil, düpedüz FAIL. Bu sürümden kendi kontrol listeme eklediğim şey revert kuralı. Yoğun bir haftada bir değişikliği sürümden çıkarmak, onu yerinde düzeltmekten daha ucuz olmalı.