Forge'dan ne istersiniz?

• Jujutsu ve diğer sürüm kontrol sistemi kullanıcıları için, büyük forge'ların yeterince ele almadığı saf Git iş akışları tartışma konusu
• Temel ilgi alanı SPA/JS ya da sunucu tarafında render edilen HTML gibi uygulama yöntemleri değil; deponun sürüm kontrol işlevlerini nasıl ifade ettiği ve çalıştırdığı
• Tangled, GitHub'ın stacked PRs yaklaşımı, forgefed gibi fikirler var; ancak tasarıma dair kullanıcı görüşlerinin toplandığı bir alan bulmak zor
• stacked PR/MR ve alternatif iş birliği modelleri de buna dahil; mevcut forge'ların ötesine geçen sürüm kontrol deneyimi ana tartışma başlığı
• Etiketler, commit'ler, ağaçlar, blob'lar gibi depo nesnelerinin gösterimi forge'lar arasında büyük ölçüde benzer ve küçük biçim farklılıkları dışında neredeyse hiç tartışılmıyor

[GN⁺]

Lobste.rs görüşleri

• Kod inceleme yorumları deponun kendisinin bir parçası değilse bunu asla kullanmam
  Değerli tarihsel bağlamı e-posta listelerinde, veritabanı silolarında ya da HEAD commit hash’ine sabitlenmeyen ayrı bir katmanda saklamak, temelde GitHub ile aynı türden bir risk
  Fossil bu yönde kısmen ilerliyor ama yalnızca issue’ları ele alıyor; kod inceleme ise hâlâ e-posta patch akışıyla yapılıyor: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
  Bu bilgi bir kez sürüm kontrol sisteminin içine girerse, üstüne güzel bir web UI, RSS feed’i ve e-posta listesi kurulabilir
  İkinci özellik, yerleşik merge queue desteği. Önemsiz olmayan projelerde tekil katkıcılar main branch’ine doğrudan push etmemeli; bunun yerine belirli commit’ler “entegrasyona hazır” diye işaretlenebilmeli ve bir bot önerilen değişiklikleri serileştirip CI’ı en iyi şekilde planlayarak main’i doğrulanmış hash’lerle ilerletmeli
  Üçüncü özellik ise Windows, macOS vb. heterojen ortamlarda izole iş çalıştırıcısı olarak CI: https://gregoryszorc.com/blog/2021/…

  • Buna ek olarak gereken şey, spam ve kötüye kullanım konusunda net bir yaklaşım
    Herkes hesap açıp issue oluşturabilmeli ama spam olmamalı
    GitHub şu anda bunu oldukça iyi yapıyor. Ara sıra spam görüyorum ama kötüye kullanım bildirildikten sonra çok hızlı kaldırılıyor. Muhtemelen arka tarafta bir sürü otomasyon ve gerçek insanlardan oluşan bir sınıflandırma ekibi var
  • Şu anda kod inceleme yorumlarını depo içinde saklayan bir araç var mı?
    Hobi projeleri için “forge” olarak Fossil’e bakıyorum; çok fazla dış katkıcı beklemiyorum, o yüzden kod inceleme olsa iyi olur düzeyinde
  • Issue ve pull request’leri doğrudan gerçek depoya koymak istemem
    Bunun yerine senkronize edilebilen, gönderilebilen ve istenildiği gibi sorgulanabilen bir SQLite DB isterim
    git-pr için bir sonraki büyük refaktörde yapmak istediğim şey, SQLite DB’yi bir SSH komutuyla açığa çıkarmak: ssh pr.pico.sh sql
    SQLite ihtiyaç duyulan her yerde var ve genel amaçlı, ama forge’un bir parçası olarak ele alındığında eksik olan şey kullanılabilirlik
  • Kod inceleme yorumlarını deponun kendisine koyma fikri gerçekten ilginç
    Ama geçmiş yeniden yazıldığında, örneğin force push ya da squash merge durumlarında, yorumların sonradan nereye “sabitleneceğini” ve kullanıcıların onları nasıl bulacağını merak ediyorum
    GitHub’da dayanak noktası Pull Request olduğu için, içindeki commit’ler değişse bile tartışmayı görebiliyorsunuz
    Bu sistemin de depoda saklanan ayrı bir PR kavramı mı olacağını, yoksa daha sıkı entegre bir şey mi beklendiğini merak ediyorum
  • Bunu commit hash’leriyle nasıl birleştireceğimi ve depo metadata’sının çok fazla dalgalanması sorununa nasıl bakacağımı bilmiyorum
    Yine de jj’yi iyi kullandığım için pratikte büyük bir sorun olmayabilir

• Hem Gerrit hem e-posta kullanan biri olarak, pull request modelinin bu kadar baskın olmasına üzülüyorum
  Özellikle bakımcıların, stil düzeyindeki küçük şeyleri yorum olarak yazmak yerine doğrudan düzeltebileceği durumlarda bu daha da belirgin; katkıcı da muhtemelen bu tür stil ayrıntılarını çok önemsemiyor
  Ama daha da üzücü olan, son zamanlarda giderek daha çok kullandığım Darcs ya da Pijul için e-posta dışı hiçbir iş akışının olmaması
  E-posta yerine XMPP tabanlı bir şey isterdim. Üzerinde çalışılan patch’ler için gerçek zamanlı dağıtık işbirliği sağlayabilir ve patch set başına bir MUC olabilir
  MUC’ler sesli sohbet gibi açılabilir; roller, ekler, tepkiler, arama, MAM, moderasyon ve tamamlandıktan sonra tombstoning gibi özellikler de zaten XEP’lerde tanımlı
  Abonelik için PubSub kullanılabilir, CI iletimi için de değerlendirilebilir
  Pratik olması için özel bir istemci gerekebilir ama birçok özellik herhangi bir istemcide de çalışabilir
  Gerçekçi olmak gerekirse, belki de bu daha çok eski federatif teknolojilerin beklenmedik biçimde genişlemesine son zamanlarda ilgi duymamla ilgili

• Kod inceleme ve onay darboğaz
  Kod gönderen kişiyle iletişimde gecikme çok yüksek; bazen haftalar ya da aylar sürüyor ve güvenilir de değil. PR açıp ortadan kaybolan insanlar oluyor
  GitHub’ın karşılıklı gidip gelmeye dayalı modeli burada tamamen çöküyor
  İnceleme sırasında kodu doğrudan düzenleyip git-absorb gibi commit’leri amend edebilmek isterdim. Yazım hatası gibi küçük sorunlar için göndericiyle ileri geri yapmak zaman kaybı; GitHub’ın Edit Suggestion hack’i de hantal ve geçmişi kirletiyor
  Aynı kodu tekrar incelemek istemiyorum. Sorun yalnızca bir fonksiyonda ya da tek bir commit’teyse geri kalanı önceden onaylayabilmeli ve gönderici force push ile düzeltince yeniden bakmak zorunda kalmamalıyım
  Bir PR’ın sadece bir kısmını merge edebilmek ya da PR’ı kapatmadan içinden commit çıkarabilmek isterdim. Bazen özelliğin kendisini istemezsiniz ama altyapı çalışmasını korumaya değer bulursunuz; bazen de gereksiz “temizlik” ya da formatting araya girer
  Asıl gönderici yanıt vermediğinde, başkalarının PR üzerinde birlikte çalışıp cilalayıp sorunları çözebilmesi gerekir. GitHub modelinde teorik olarak mümkün ama pratikte başka bir PR için PR açma gibi gizli bir numaraya dönüşüyor; o kod ve bildirimler de hedef projede görünmüyor. İnsanlar fork edip düzeltme PR’ı açınca yalnızca kafa karışıklığı ve merge conflict çıkıyor
  Çoğu zaman gönderilen kod genel olarak yeterince iyi ama küçük iyileştirmeler istiyorum. Gönderen açısından PR, tüm son rötuşlar tamamlanana kadar rehin kalmış gibi hissettiriyor; bakımcı açısından ise hemen merge edip sonra kişinin ortadan kaybolması ve sonraki iyileştirmelerin hiç yapılamaması riski var. Sonradan temizleme zorunluluğuyla geçici merge yapmanın bir yolu olsa güzel olurdu. Örneğin staging branch’ine merge edilir ama FIXME çözülene kadar stable branch’e cherry-pick edilmez
  Popüler açık kaynak projelerde, projeyi ileri taşıyacak kod inceleme ve onayı yapabilen tek bir kişi varken katkı yapmak ve birbirine yardım etmek isteyen 500 kişi olabiliyor. GitHub modeli bu fazla katkıcı kapasitesinden hiç yararlanamıyor. İşbirliğini kolaylaştırmak yerine bunu kriz, kaos ve öfkeli grup baskısına çeviriyor. Tek bir bakımcıya takılmadan başkalarının deney yapabilmesi ve projeyi ilerletebilmesi için fork yönetimi ile fork’lar arası kod kopyalamayı daha iyi desteklemeli; bakımcı da farklı fork’lardaki popüler ve çalıştığı kanıtlanmış değişiklikleri kolayca seçebilmeli

  • PR göndericisi bunu engelleyen ayarı açmadıysa, depo sahibi PR branch’ine doğrudan push edebilir
    Organizasyonlarda bu varsayılan gibi hatırlıyorum ama her hâlükârda bu durumda force push ile doğrudan temiz düzeltme yapabilirsiniz
    Gidip gelmeye değmeyecek küçük değişikliklerde bunu hep yapıyorum
  • Göndericinin yavaş olduğunu düşünüyorsanız bir de bakımcı yanıtını beklemeyi deneyin
    Genelde aylar hatta yıllarla ölçülüyor gibi geliyor
    Bazen bakımcı benim; itiraf etmeliyim ki ben de her zaman bundan hızlı değilim
  • Web inceleme arayüzü doğrudan kod düzenleyemese bile IDE’ye çok daha yakın olmalı
    Tanıma git, imza ya da dokümantasyon yorumlarını gösteren hover açılır pencereleri gibi özellikler istiyorum
    Branch’i checkout edip istediğiniz editörde inceleyince bu mümkün ama dediğim gibi inceleme darboğaz
    Birden fazla PR incelerken her seferinde branch’ler arasında gidip gelmenin ek yükü çok fazla

• Tek kullanıcılı, ya da en azından tek kullanıcılı bir moda ihtiyaç var
  Neden https://code.chrismorgan.example/chrismorgan/repository-name gibi bir URL’ye katlanayım? https://code.chrismorgan.example/repository-name yeterliyken
  Bunu ciddiyetle söylüyorum ve https://github.com/go-gitea/gitea/issues/11028 bağlantısına bakarsanız bunu isteyen epey kişi olduğu açık
  Fediverse hesabım olmamasının üç ana nedeninden biri de adreslerin korkunç olması
  Birincil e-posta adresi gibi @‌me@‌chrismorgan.info kullansam bazı insanlara sadece “@‌me” gibi görünebilir; @‌chrismorgan@‌chrismorgan.info ise bakması bile rahatsız edici
  Bu konuda ATProto çok iyi iş çıkardı. Alan adı bir handle olarak harika; birden çok kullanıcı gerekirse alt alan adları yeterli
  Paylaşımlı bir forge’da da alt alan adları kullanılarak mantıksal olarak tek kullanıcılı gibi hissettirilebilir. github.com/chris-morgan yerine chris-morgan.github.com düşünmek ilginç olabilir
  Estetik önemlidir
  Tek kullanıcılı tarafa yönelmenin daha büyük sonuçları da var. Mastodon gibi bir şeyi tek kullanıcı için küçültseniz bile hâlâ ağır kalıyor; ama baştan tek kullanıcı için tasarlanmış Fediverse projeleri bu kullanım için daha uygun
  Sunucumu kendim işletmek ama yerel kullanıcı olarak sadece kendimin olması istiyorum; ileride başka kullanıcı olabilir diye taviz vermek istemiyorum
  Bu aynı zamanda forge’ların kullandığı git gibi genel bir kullanıcı adı yerine, normal SSH’ta olduğu gibi chris kullanıcı adıyla push etmek istemem anlamına da geliyor
  Alışılagelmiş anlamda bir forge olacaksa federasyon elbette gerekli. Ama herkesin “ev sunucusu”nda yerel kullanıcı olarak yalnızca bir kişi olsa güzel olurdu

  • E-posta adreslerini nasıl kullanıyorsunuz?
    Kendi adınıza ait bir domain kullanıyorsanız orada da benzer bir sorun olmuyor mu?

• Bu konuda Nesbitt’s article hoşuma gitti
  Özellikle downstream ile daha iyi iletişim kısmı çok iyiydi

• Seçtiğim editörde yerel kod inceleme yapabilmeliyim
  Değiştirilemeyen fontlara ve berbat sözdizimi renklendirmesine sahip hantal web arayüzlerine zorla kapatılmak istemiyorum
  Şu anda Neovim için yazılmış özel araçlarla yan yana diff görüntüsünü okunur hâle getiriyor ve git pr komutuyla pull request’leri checkout ettiğim bir iş akışı kullanıyorum
  Ama inceleme yorumu bırakmak gibi biraz daha fazlasını istediğim anda, beş yıl sonra bile bakımının sürmesi pek olası olmayan birinin CLI’ına ya da GitHub API’siyle konuşan araçlara bağımlı kalıyorum
  Daha doğrusu sadece yerelde “çalıştırılabilen” araçlar değil, editörlerle vb. yerelde bütünleşen local-first araçlara daha çok ihtiyaç var
  Bunun birinci sınıf özellik hâline gelmesinin zor olmasının nedeni gereken emeğin büyük olması. Tek bir web arayüzü kullanıcıları ona mecbur bırakarak tüm platformlar ve editör ortamlarında “çalışır”; ama daha sıkı entegrasyon demek, N tane editör ve ortam varsa N tane entegrasyon gerekir demek
  CI için de benzer şekilde, commit’i bir branch’e push edip 15 dakika sıra beklemek yerine Linux, FreeBSD ve macOS’ta testleri kolayca çalıştırmak istiyorum
  run-remotely some-command --on freebsd,linux,mac gibi bir şey yeterli
  Temelde local-first ve merkezi olmayan bir CI sistemi olmalı; ama aynı zamanda merge öncesi tüm kodun aynı “onaylı” sistemden geçtiğini garanti eden tek gerçek kaynağı olarak merkezi bir sistemi de desteklemeli
  Bu, basit bir ssh user@host command ... işini aşar. Çünkü kaynak kodu kopyalamayı, cache’lemeyi, gerekli bağımlılıkları kurmayı vb. kapsayıp her seferinde aynı güvenilir durumu elde etmek gerekir

  • Son zamanlarda ben de benzer şeyler düşünüyorum
    Ama bunu forge özelliği olarak görmüyorum. Belirli bir forge olmadan da kullanılabilen ve her forge tarafından çağrılabilen bir iş çalıştırıcı aracı olarak sunulmalı
    Biraz “driver tabanlı” olması gerektiğini düşünüyorum. Aynı işi tamamen yerelde çalıştırabilir ya da bir uzak sisteme gönderip orada başlatabilirsiniz. O iş bir sanal makine, bir container ya da doğrudan çalıştırma olabilir

• Git dışı sürüm kontrol sistemlerini de desteklemeli
  Issue’ları, wiki’leri vb. uygun formatlarda içe ve dışa aktarabilmeli ki insanlar belirli bir sisteme kilitlenmesin
  Self-hosting de kolay olmalı

  • Git dışı tüm sürüm kontrol sistemlerini desteklemek epey büyük bir liste
    Gerçekte önemli olan bazı alt kümeler vardır muhtemelen
    Kardeş yorumdaki Heptapod Mercurial için; sourcehut da öyle
    Fossil’in kendi forge’u var; SourceForge’un Apache sürümü olan allura ise Subversion sunuyor

• Keşke CI katmanında Bazel benzeri bir şey sunan bir forge olsa
  Kastettiğim “CI’da Bazel çalıştırabilmek” değil; insanların bağımlılıkları tanımlı, iyi test ve build koleksiyonları yazmasını doğal olarak teşvik eden ve böylece CI süresini sebepsiz yere yakmayan bir yaklaşım
  Bununla bağlantılı olarak, “bir proje = bir repo” modelinin pek çok probleme yol açtığını düşünüyorum
  Buna daha iyi monorepo desteği de diyebilirsiniz, ama özünde CI ve issue gibi şeylerin kapsamı “bu dizinin kökü”nden daha geniş olabilmeli
  Pek çok proje forge ya da CI nedenleriyle depoları parçalıyor ve o durumda çalışmak keyifli değil
  İnceleyen biri olarak satır içi patch bölme de istiyorum
  Yani iyi bulduğum kısımları seçip yalnızca onları onaylayabilmeli ve memnun olduğum parçaları entegre edebilmeliyim
  Stack’lenmiş PR’ların hâlâ fazla ağır bir kavram olduğunu düşünüyorum
  Birisi “4 dosyayı değiştirmek istiyorum ve bunu tek bir PR olarak görüyorum” dediğinde, inceleyen kişi “tamam, bu 2 dosya iyi” diyebilmeli ve bu değişiklik setini PR’ın ayrı bir parçasına çevirebilmeli ya da hatta sadece o parçayı ayrı bir commit olarak merge edebilmeli
  Mevcut stacked PR sistemleri de sonuçta PR’ı atomik bir birim olarak ele alıyor. Çoğu sistemde PR bana fazla ağır geliyor

  • Basit bir gözlem ama JetBrains uzun süre hunk bazlı commit yapmaya izin vermeye karşı çıktı
    Gerekçeleri “bu dosyanın bir alt kümesi, derlenip derlenmeyeceğini bilemezsiniz” idi
    Bu görüşe hiç katılmıyorum ama web görünümünde böyle bir şey yapılacaksa epey dikkatli olunması gerekir; bu yorum da bana onu hatırlattı
    Tabii yukarıdaki yorumda dendiği gibi depo sahibiyseniz branch’e tercih ettiğiniz sürümü force push edebileceğiniz konusunu bir kenara bırakırsak

• Eforsuz CI/CD kurulumu gerekli
  Sadece make build, make test, make upload olsun yeter
  Geri kalanı makefile’da kalsın; oradan daha iyi bir build sistemine geçilebilir
  Fikirden yayımlanmış çalışır çıktıya iki dakikadan kısa sürede gitmek istiyorum

  • Neden illa hem de farklı sürümleri olan Make kullanılsın ki?
    Çoğu CI/CD sisteminin yaptığı gibi iyi bilinen bir konumdaki yapılandırma dosyası yerine, iyi bilinen bir dizinde iyi bilinen isimlere sahip üç shell script yeterli
    Bonus olarak Windows build gerekiyorsa bunlar .bat dosyası da olabilir
  • Bu yaklaşım güzel ama muhtemelen bağımlılık kurulumu için bir yönteme ihtiyaç duyulur
    İşletim sistemine göre değişebilir ve bunu makefile’ın içine koymak istemeyebilirsiniz
  • Doğrudan izolasyon getirebilen local-first CI geliştiriyorum: https://ci.pico.sh
    Güzel yanı, tüm işlerin zmx altında kendi pty’lerinde çalışması
    Başarısız bir işe attach olup yukarı ok ve Enter ile yeniden çalıştırabiliyorsunuz

• Nitelikli verinin yayımlanmasını sağlayacak korumaları olan güvenlik tavsiyeleri isterim
  Tüm projelerin anlamlı veri yayımlayabilmesi için commit merkezli bir ekosistem gerekli; ayrıca isteyen projelerin doğrudan CVE yayımlayabilmesi için entegrasyon da olmalı