Guix'in Codeberg'e taşınmasının üzerinden 1 yıl

 (guix.gnu.org)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Guix, 10 yılı aşkın süredir Savannah ve e-posta tabanlı Debbugs ile sürdürdüğü işbirliği modelini 2025'te Codeberg'e taşıyarak, yılda 400'den fazla kişinin katkı sunduğu bir projede katkı giriş noktasını büyük ölçüde değiştirdi
  • Bu geçiş, 2024 Aralık'ta devreye alınan Guix Consensus Document sürecinin ilk gerçek uygulama örneğiydi ve GCD 002, iki aylık tartışmanın ardından 2025 Mayıs başında yürürlüğe girdi
  • Mevcut e-posta iş akışı Emacs, mumi, qa.guix.gnu.org gibi araçlar sayesinde deneyimli kişiler için verimliydi; ancak 900 kişinin yanıtladığı ankette katkı sunanlar tarafından sık sık bir engel olarak gösterildi
  • Codeberg'e geçişten sonra yazar sayısı ve yeni yazar sayısı arttı; ancak 2025 Haziran'ındaki geçici zirve dışında belirgin bir Codeberg etkisini doğrulamak zor
  • Her ay 500'den fazla pull request açılması nedeniyle backlog büyüyor; bu yüzden CI eksikliği, imza zorunluluğu ve inceleme yükünü azaltmak Guix'in bir sonraki operasyonel görevi olarak duruyor

E-posta tabanlı işbirliğinden Codeberg'e geçiş

  • Guix, 2025'te kaynak kod barındırma, issue takibi ve pull request süreçlerini Codeberg'e taşıdı
    • Daha önce kodu 10 yılı aşkın süre boyunca Savannah üzerinde barındırıyordu
    • Hata raporları ve patch'ler e-posta ile işleniyor, Debbugs instance'ı üzerinden takip ediliyordu
    • Her yıl 400'den fazla kişinin koda katkı sunduğu bir proje olduğu için bu geçiş başlı başına büyük bir değişimdi
  • Mevcut çekirdek katkıcılar e-posta iş akışına alışkındı ve Emacs için Debbugs paketi ya da gelişmiş e-posta istemcileriyle verimli çalışıyordu
    • Debbugs, birkaç yüz satırlık Perl koduna ve e-posta standartları ile federatif yapıya dayanırken, Forgejo gibi web forge'ları Go bağımlılığı yüksek daha büyük sistemlerdir
  • E-posta akışının etrafında zaten yardımcı araçlar da oluşmuştu
    • mumi, Debbugs için bir web arayüzü sağlıyordu
    • Quality Assurance service, e-posta patch serilerini otomatik olarak Git branch'lerine uyguluyor ve bu branch'lerde paketleri derliyordu
  • 2025 Ocak'ta yayımlanan ilk kullanıcı ve katkıcı anketine 900'den fazla kişi yanıt verdi; katkıcılar e-posta iş akışını katkı sunmanın önündeki bir engel olarak sık sık gösterdi

GCD 002 ile ilerleyen uzlaşma temelli karar

  • Guix'te kararları alacak bir “benevolent dictator” yoktu ve 2024 Aralık'ta Guix Consensus Document process devreye alındı
  • GCD süreci, basit oylamadan çok uzlaşma oluşturmayı hedefliyor
    • Teklif yazarı, katılımcılarla birlikte teklifi uyarlamak zorunda
    • Katılımcılar yalnızca karşı çıkmak yerine kendi ihtiyaçlarını ve bunları yansıtacak somut değişiklikleri önermek zorunda
    • Nihai metinde tutumlar support, accept, disapprove ile belirtiliyor
  • GCD 002, 2025 Şubat'ta Codeberg'e geçiş önerisi olarak sunuldu
    • Tartışma, süreçte izin verilen azami süre olan iki ay boyunca devam etti
    • Guix ekip üyelerinin üçte ikisi müzakereye katıldı
    • Katılımcıların %72'si support, kalan %28'i ise accept seçeneğini işaretledi
    • disapprove çıkmadı ve teklif 2025 Mayıs başında yürürlüğe girdi
  • Uzun süredir katkı sunan bazı üyeler, web öncelikli görünen iş akışının e-postaya göre daha verimsiz olduğunu düşündü ve e-posta tabanlı altyapının bir bölümünden vazgeçilmesinden rahatsız oldu
  • Daha geniş toplulukla temas kurulması ve geliştirici deneyiminin iyileşme ihtimali geçişi destekledi
  • Özgür yazılım tabanlı bir forge ve kâr amacı gütmeyen Codeberg e.V. tarafından barındırılan bir forge tercih edilmesi büyük bir tartışma yaratmadı; ayrıca Guix'in yönelimiyle de uyumluydu

Aşamalı geçiş ve beklenenden büyük CI boşluğu

  • Codeberg'e geçiş, GCD uzlaşmasında kararlaştırıldığı gibi kademeli olarak ilerledi
    • Ana depo 25 Mayıs 2025'te taşındı
    • Eski depo hâlâ mirror olarak duruyor
    • Mevcut issue ve patch takipçisi 1 Ocak 2026'ya kadar korunacak
    • Sonrasında yalnızca Codeberg issue'ları ve pull request'leri desteklenen mekanizma olacak
    • Geçmiş hata raporları ve patch'lere çevrimiçi erişim devam ediyor
  • Uzlaşma tartışmaları sırasında hazırlanan plan sayesinde geçişte büyük sorunlar ya da beklenmedik durumlar az oldu
  • Codeberg e.V. çalışanları ve gönüllülerinin sunduğu hizmet kalitesi iyiydi; aralıklı kesintiler genelde kısa sürdü ve açık biçimde duyuruldu
  • Tarayıcı dışı iş akışını tercih eden katkıcılar için Emacs arayüzündeki gelişmeler faydalı oldu
  • Yeterince öngörülemeyen sorun, pull request'ler için sürekli entegrasyon oldu
    • qa.guix.gnu.org üzerinde e-posta patch'lerini derleyen işlev Codeberg'e taşınmadı
    • Aylar boyunca incelemeciler, pull request'lerin sorun yaratıp yaratmadığını kendileri doğrulamak zorunda kaldı ve bu sürdürülebilir bir durum değildi
  • 2025 Eylül'de Cuirass instance'ı pulls.ci.guix.gnu.org üzerinde kuruldu ve pull request'leri derlemeye başladı
    • Başlangıçta qa.guix.gnu.org'a göre daha fazla kısıta sahip olduğu için bir geçici çözüm olarak görülüyordu
    • Şu anda paketler tek bir mimari için derleniyor
    • Yeni katkıcılar, guix-cuirass-botun pull request'lere bıraktığı başarı ya da başarısızlık sonuçlarını doğrudan görebiliyor

Katkı akışı arttı ama backlog da büyüdü

  • 2024 Mayıs'tan 2026 Mayıs'a kadar ana branch commit sayısına bakıldığında, Guix'in commit hızı sürekli “yüksek” ile “çok yüksek” arasında kaldı
  • Değişim yalnızca commit hızıyla iyi görünmediği için, aylık commit yazarı sayısı, committer sayısı ve yeni commit yazarı sayısı daha faydalı ölçütler oldu
  • Aylık yazar sayısı ve yeni yazar sayısı artmayı sürdürdü
    • Codeberg'e geçişten hemen sonra, 2025 Haziran'ında hem yazar sayısında hem de yeni yazar sayısında zirve görüldü
    • Diğer dönemlerdeki büyüme, 2025–2026 aralığında da 2024–2025 aralığına benzerdi
    • Guix yeni katkıcı çekmeyi sürdürse de belirgin bir Codeberg etkisi büyük değildi
  • Aylık committer sayısındaki artış, yazar sayısındaki artıştan daha yavaştı; bu da committer'ların daha fazla katkıyı işlediğine işaret ediyor olabilir
  • Pull request verileri, Codeberg'in Forgejo API aracılığıyla toplandı
  • Her ay 500'ü aşkın pull request açılıyor ve birleşme hızı da yüksek; ancak giriş hızı bundan biraz daha yüksek olduğu için backlog büyümeye devam ediyor
    • Şu anda açık pull request sayısı, toplam 6.459'un yaklaşık 639'u; yani yaklaşık %10
    • Karşılaştırma için verilen Nixpkgs'te toplam 473k pull request'in 12k'si açık; yani yaklaşık %2,5
    • Guix backlog'u, aşırı sürtünme ya da yetersiz CI geri bildirimi nedeniyle oluşuyor olabilir
  • Guix, her commit'in onaylı bir committer'ın imzasını taşımasını istiyor
    • Bu, Nixpkgs dahil birçok projede olduğu gibi yalnızca Merge düğmesine basılan bir model değil
    • Birleştiren kişi, değişikliği uygulama ve imzalama sorumluluğunu üstlenmek zorunda
    • Guix, geliştirici kolaylığı ile kullanıcı güvenliği arasında yazılım tedarik zinciri güvenliğini tercih ediyor
    • Bu maliyetin azaltılıp azaltılamayacağı henüz net değil

Codeberg'de daha görünür hâle gelen işbirliği

  • Codeberg'e geçişten sonra proje etkinliği daha görünür hâle geldi
  • CI sonuçları doğrudan pull request içinde göründüğü için katkıcılar bunları anında kontrol edebiliyor
  • Guix takımları, Codeberg takımları olarak uygulanıyor
    • Takım kapsamı CODEOWNERS dosyasında belirtiliyor
    • İlgili kapsamdaki sorumlular otomatik olarak çağrılıyor
    • Bot, issue ve pull request'lerin etiketlere göre filtrelenebilmesi için team-python gibi etiketler ekliyor
  • Bu etiketin bulunduğu issue'larda takımın bildirim alamaması sorunu rahatsız edici bir nokta olarak kalıyor
  • Issue'lar ile pull request'ler arasındaki çapraz referanslar ve milestone gibi özellikler de işbirliğine yardımcı oluyor gibi görünüyor

Kalan altyapı görevleri ve Codeberg ile ilişki

  • Guix altyapısının daha fazla desteğe ihtiyacı var
    • pulls.ci.guix.gnu.org üzerindeki derleme performansının artırılması gerekiyor
    • x86 dışı mimariler için de derleme yapılabilmesi iyi olurdu
    • Cuirass'ın çeşitli sınırlamaları var ve bunların bir kısmı planlanan 1.4.x serisinde çözülüyor
    • pulls.ci.guix.gnu.org hâlâ paket odaklı; uygun olduğunda sistem testlerini de çalıştırabilmesi faydalı olurdu
  • Paketleyici iş akışında da iyileştirme alanı bulunuyor
  • Guix'in, Codeberg sunucularında aşırı yük oluşturmaması ve depo kullanımını da izlemeye devam etmesi gerekiyor
  • Çözüm olarak, yeni katkıcıların AGit workflow kullanarak pull request oluşturmasının istenmesi öneriliyor
    • AGit, Guix katkıcıları arasında zaten popüler
    • Ancak daha tanıdık genel pull request iş akışına kıyasla daha az tanıdık olduğu için bunu bir “geriye gidiş” olarak görenler de var
    • Gentoo örneğinde olduğu gibi bir “AGit fork” simgesi eklenirse keşfedilebilirlik artabilir
  • Guix Foundation, teşekkür ve destek göstergesi olarak Codeberg e.V.'nin destekleyici üyesi olmak için oylama yaptı
  • Forgejo ve bunu Guix içinde yapılandıran hizmeti ekleyen bir pull request sunuldu
    • Bu, deklaratif yapılandırma ve yeniden üretilebilir forge dağıtımının Guix içinde mümkün hâle gelmesi yönünde bir adım

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Lobste.rs görüşleri

  • Codeberg’e geçiş ile ilgili gerçek proje metriklerini görmek çok ilginç. Kişisel olarak GitHub’dan ayrılmak için fazlasıyla neden olduğunu düşünüyorum; bu yüzden Codeberg’in yeni GitHub olmasını umuyorum, ancak ben kendi Forgejo sunucuma taşındım ve şu anda Codeberg’i tüm depolarım için yedek hedefi olarak kullanıyorum

    • Bunun iyi niyetle söylendiğini biliyorum ama her şeyin Codeberg’de toplanmasındansa, birden çok bağımsız forge’un ForgeFed ile birbiriyle iletişim kurması daha iyi olur diye düşünüyorum
      Yeni bir açık kaynak merkezli hub’a daha ihtiyacımız yok
    • Şu anda Forgejo’nun bu rolü kaldırabilecek kadar ölçeklendiğini düşünmüyorum. Codeberg tarafı yapabildiği kadarını yapıyor ve umarım daha da iyileşir, ama bunun zaman alacağını sanıyorum
    • Kişisel işlerimi sonunda tamamen Fossil’e taşıdım ve başkalarıyla paylaşmak istediklerim için kendi Fossil sunucumu kurdum
      Şimdiye kadar gayet iyi oldu ve kesinlikle git’e tercih ediyorum. Günümüz ölçütlerine göre bu engel o kadar da yüksek değil gerçi

  • Codeberg kullanmaya başladıktan sonra beni gerçekten sinirlendiren şey, git entegrasyonunu düzgün destekleyen araçların neredeyse hiç olmaması ve çoğunun fiilen yalnızca GitHub / GitLab’e yönelik olmasıydı

    • magit forge kullanan biri olarak gözlerim doluyor

  • Eski sorun·yama takipçisini 1 Ocak 2026’ya kadar koruyup sonrasında yalnızca Codeberg issue’ları ve pull request’lerini destekleyecek olmaları bana mantıklı gelmiyor
    Katkı yapanların önemli bir kısmı yeni akışı sevmiyorsa neden bunu zorunlu kılıyorlar, ayrıca birden fazla akışı desteklemenin gizli bir maliyeti olup olmadığını da merak ediyorum. Neden herkese aynı yöntemi dayatmak gerekiyor, anlamıyorum
    Küçük bir ayrıntı ama Codeberg’de birden fazla maaşlı çalışan var gibi görünmüyordu; bildiğim kadarıyla sadece bir kişi vardı. Düzeltme: Geçen aralıkta ikinci bir çalışan eklenmiş.