Apa yang Anda inginkan dari forge?

• Pengguna Jujutsu dan sistem kontrol versi lain, serta alur kerja Git murni yang belum cukup ditangani oleh forge utama, menjadi bahan diskusi
• Fokus utamanya bukan pada metode implementasi seperti SPA/JS atau HTML yang dirender di server, melainkan pada bagaimana repositori merepresentasikan dan menjalankan fungsi kontrol versi
• Ada gagasan seperti Tangled, stacked PRs milik GitHub, dan forgefed, tetapi sulit menemukan ruang tempat pendapat pengguna tentang desain terkumpul
• Termasuk stacked PR/MR dan model kolaborasi alternatif, dengan pengalaman kontrol versi yang melampaui forge yang ada sebagai isu utama
• Tampilan objek repositori seperti tag, commit, tree, dan blob umumnya serupa di tiap forge, dan hampir tidak ada pembahasan selain perbedaan format kecil

[GN⁺]

Pendapat di Lobste.rs

• Komentar review kode tidak akan pernah bisa saya gunakan jika itu bukan bagian dari repositori itu sendiri
  Menyimpan konteks historis yang berharga di mailing list, silo database, atau lapisan terpisah yang tidak dipatok ke hash commit HEAD pada dasarnya adalah risiko dengan jenis yang sama seperti GitHub
  Fossil sudah bergerak sebagian ke arah ini, tetapi baru menangani issue dan untuk review kode masih memakai model patch via email: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
  Setelah informasi ini masuk ke dalam sistem kontrol versi, kita bisa menaruh web UI yang keren, feed RSS, dan mailing list di atasnya
  Fitur kedua adalah dukungan bawaan untuk merge queue. Dalam proyek yang tidak sepele, kontributor individu tidak seharusnya push langsung ke branch main; ketika commit tertentu ditandai “siap diintegrasikan”, bot seharusnya menserialkan perubahan yang diusulkan, menjadwalkan CI secara optimal, dan memajukan main ke hash yang sudah tervalidasi
  Fitur ketiga adalah CI sebagai eksekutor pekerjaan terisolasi di lingkungan heterogen seperti Windows dan macOS: https://gregoryszorc.com/blog/2021/…

  • Tambahan yang dibutuhkan adalah pendekatan yang jelas untuk menangani spam dan penyalahgunaan
    Siapa pun harus bisa membuat akun dan membuka issue, tetapi tidak boleh ada spam
    Saat ini GitHub menangani ini dengan cukup baik. Kadang saya melihat spam, tetapi setelah dilaporkan sebagai penyalahgunaan, itu dihapus sangat cepat. Sepertinya di baliknya ada campuran otomatisasi bodoh dan tim klasifikasi manusia sungguhan
  • Apakah sekarang ada alat yang menyimpan komentar review kode di dalam repositori?
    Saya sedang melihat Fossil sebagai “forge” untuk proyek hobi, dan sepertinya tidak akan banyak kontributor eksternal, jadi review kode hanya semacam bonus kalau ada
  • Saya tidak ingin issue dan pull request benar-benar dimasukkan ke dalam repositori
    Sebagai gantinya, saya ingin database SQLite yang bisa disinkronkan, dikirim, dan dikueri sesuka hati
    Hal besar berikutnya yang ingin saya kerjakan sebagai refaktor di git-pr adalah mengekspos database SQLite lewat perintah SSH: ssh pr.pico.sh sql
    SQLite ada di mana-mana sebanyak yang dibutuhkan dan bersifat umum, tetapi belum ada kemudahan penggunaan yang memperlakukannya sebagai bagian dari forge
  • Menaruh komentar review kode di repositori itu sendiri benar-benar ide yang menarik
    Hanya saja saya penasaran, dalam kasus riwayat ditulis ulang seperti force-push atau squash merge, komentar itu nantinya akan “dipatok” ke mana agar bisa ditemukan pengguna
    Di GitHub acuannya adalah Pull Request, jadi diskusinya tetap bisa dilihat meskipun commit yang termasuk di dalamnya berubah
    Saya penasaran apakah sistem ini juga membayangkan semacam konsep PR terpisah yang disimpan di dalam repositori, atau sesuatu yang lebih terintegrasi rapat
  • Saya kurang yakin bagaimana ini akan dipadukan dengan hash commit, dan bagaimana melihat masalah metadata repositori yang banyak berguncang
    Meski begitu, saya cukup sering memakai jj, jadi mungkin dalam praktiknya itu bukan masalah besar

• Setelah memakai Gerrit dan email, saya menyesalkan bahwa model pull request menjadi yang paling dominan
  Terutama ketika maintainer sebetulnya bisa langsung memperbaiki hal kecil seperti gaya penulisan alih-alih meninggalkan komentar, dan kontributor kemungkinan besar memang tidak terlalu peduli soal gaya seperti itu
  Tetapi yang lebih disayangkan lagi adalah bahwa untuk Darcs atau Pijul, yang belakangan makin sering saya pakai, tidak ada workflow selain email
  Akan bagus jika berbasis XMPP alih-alih email. Kita bisa melakukan kolaborasi terdistribusi secara real-time untuk patch yang sedang dikerjakan, bahkan mungkin satu MUC untuk tiap patchset
  MUC bisa dibuka seperti voice chat, dan fitur seperti peran, lampiran, reaksi, pencarian, MAM, moderasi, serta tombstoning setelah selesai sudah didefinisikan lewat XEP
  Untuk langganan bisa memakai PubSub, dan itu juga bisa dipakai sebagai sarana pengiriman CI
  Agar praktis memang akan butuh klien khusus, tetapi banyak fitur mungkin tetap bisa langsung berjalan di klien apa pun
  Secara realistis, mungkin ini lebih karena akhir-akhir ini saya tertarik melihat teknologi federasi lama berkembang dengan cara yang tak terduga

• Review kode dan persetujuan adalah bottleneck
  Komunikasi dengan pengirim kode memiliki latensi yang sangat tinggi, kadang memakan waktu berminggu-minggu atau berbulan-bulan, dan keandalannya juga rendah. Ada juga orang yang membuka PR lalu menghilang
  Model GitHub yang mengandaikan interaksi bolak-balik benar-benar runtuh di sini
  Akan bagus jika selama review saya bisa langsung mengubah kode dan meng-amend commit seperti git-absorb. Bolak-balik dengan pengirim hanya karena hal sepele seperti typo itu buang waktu, dan hack Edit Suggestion milik GitHub merepotkan serta mengacaukan riwayat
  Saya tidak ingin mereview kode yang sama lagi. Jika masalahnya hanya ada pada satu fungsi atau satu commit, saya ingin bisa menyetujui sisanya lebih dulu, dan ketika pengirim memperbaikinya lewat force-push, saya tidak perlu melihat ulang semuanya
  Akan bagus jika kita bisa merge hanya sebagian PR, atau menghapus commit tanpa menutup PR. Kadang fitur utamanya memang tidak diinginkan, tetapi pekerjaan dasarnya tetap layak dipertahankan; sebaliknya kadang ada “pembersihan” atau formatting yang tidak perlu ikut terselip
  Ketika pengirim asli tidak merespons, orang lain seharusnya bisa berkolaborasi di PR tersebut, merapikannya, dan menyelesaikan masalahnya. Dalam model GitHub ini secara teori mungkin, tetapi praktiknya lebih mirip trik tersembunyi membuat PR terhadap PR lain, dan kode serta notifikasinya tidak terlihat di proyek target. Kalau orang-orang fork lalu mengirim PR perbaikan, hasilnya cuma kebingungan dan konflik merge
  Sering kali kode yang diajukan sebenarnya sudah lumayan baik, tetapi saya masih ingin sedikit perbaikan. Dari sisi pengirim, rasanya PR seperti disandera sampai semua pekerjaan akhir yang bagus selesai; dari sisi maintainer, kalau langsung di-merge ada risiko pengirim menghilang dan perbaikan lanjutan tidak pernah terjadi. Akan bagus jika ada cara untuk merge sementara dengan kewajiban dibereskan nanti. Misalnya di-merge ke staging branch, tetapi tidak di-cherry-pick ke branch stabil sampai FIXME diselesaikan
  Dalam proyek open source populer, bisa terjadi hanya ada 1 orang yang dapat melakukan review kode dan persetujuan yang benar-benar mendorong proyek maju, sementara ada 500 orang yang ingin berkontribusi dan saling membantu. Model GitHub sama sekali tidak memanfaatkan kapasitas berlebih dari para kontributor ini. Alih-alih membantu kolaborasi, ia mengubahnya menjadi krisis, kebingungan, dan tekanan massa yang marah. Harus ada dukungan yang lebih baik untuk pengelolaan fork dan penyalinan kode antar-fork agar orang lain bisa bereksperimen dan memajukan proyek tanpa terblokir oleh satu maintainer, dan maintainer harus bisa dengan mudah memilih perubahan yang populer dan sudah terbukti berjalan dari berbagai fork

  • Jika pengirim PR tidak menyalakan pengaturan yang memblokirnya, pemilik repositori bisa push langsung ke branch PR
    Di organisasi seingat saya ini dulu adalah default, tetapi bagaimanapun dalam kasus itu kita memang bisa membereskan sesuatu secara langsung dan rapi lewat force-push
    Untuk perbaikan kecil yang tidak layak bolak-balik, saya selalu melakukan itu
  • Kalau menurut Anda pengirim lambat, coba rasakan menunggu respons maintainer
    Biasanya rasanya diukur dalam hitungan bulan atau tahun
    Kadang saya juga menjadi maintainer, dan saya akui saya pun tidak selalu lebih cepat dari itu
  • Akan bagus jika antarmuka review web, meski tidak bisa langsung mengubah kode, setidaknya jauh lebih mendekati IDE
    Saya ingin fitur seperti go to definition dan popup hover yang menampilkan signature atau komentar dokumentasi
    Itu bisa dilakukan kalau kita checkout branch lalu review di editor pilihan kita, tetapi seperti sudah dibilang, review adalah bottleneck
    Pekerjaan tambahan untuk terus pindah branch saat mereview banyak PR terlalu besar

• Perlu ada pengguna tunggal, atau setidaknya mode pengguna tunggal
  Kenapa saya harus menerima URL seperti https://code.chrismorgan.example/chrismorgan/repository-name? Padahal https://code.chrismorgan.example/repository-name sudah cukup
  Saya benar-benar serius, dan kalau melihat https://github.com/go-gitea/gitea/issues/11028 jelas banyak orang menginginkan hal seperti ini
  Salah satu dari tiga alasan utama saya tidak punya akun Fediverse juga karena alamatnya buruk sekali
  Kalau memakai @‌me@‌chrismorgan.info sebagai alamat utama, bagi sebagian orang itu mungkin cuma terlihat sebagai “@‌me”, dan @‌chrismorgan@‌chrismorgan.info benar-benar menjijikkan dilihat
  Dalam hal ini ATProto melakukannya dengan sangat baik. Nama domain sangat cocok dijadikan handle, dan kalau butuh banyak pengguna, subdomain sudah cukup
  Bahkan di forge bersama, memakai subdomain mungkin bisa membuatnya terasa secara logis seperti pengguna tunggal. Coba bayangkan chris-morgan.github.com alih-alih github.com/chris-morgan, mungkin akan menarik
  Estetika itu penting
  Beralih ke pengguna tunggal juga punya konsekuensi yang lebih besar. Jika sesuatu seperti Mastodon diperkecil untuk satu pengguna, itu tetap berat; tetapi proyek Fediverse yang sejak awal dirancang untuk pengguna tunggal lebih cocok untuk tujuan itu
  Saya ingin mengelola server saya sendiri, tetapi pengguna lokalnya hanya saya seorang, dan saya tidak ingin berkompromi hanya karena ada kemungkinan pengguna lain
  Ini juga berarti saya ingin push memakai nama pengguna chris, seperti SSH biasa, bukan nama pengguna umum seperti git yang dipakai forge
  Untuk forge dalam arti yang biasa dipahami, federasi tentu dibutuhkan. Tetapi akan bagus jika di masing-masing “home server” hanya ada satu pengguna lokal

  • Bagaimana Anda menggunakan alamat email?
    Kalau memakai domain atas nama sendiri, bukankah di sana juga ada masalah serupa?

• Saya menyukai artikel Nesbitt tentang topik ini
  Khususnya bagian tentang komunikasi yang lebih baik dengan downstream

• Harus bisa melakukan review kode lokal di editor pilihan
  Saya tidak mau dipaksa terjebak di antarmuka web lamban dengan font yang tidak bisa diubah dan syntax highlighting yang buruk
  Saat ini saya memakai workflow dengan alat kustom untuk Neovim agar tampilan diff berdampingan lebih enak, dan perintah git pr untuk checkout pull request
  Tetapi begitu saya menginginkan sedikit lebih banyak, seperti meninggalkan komentar review, saya akhirnya bergantung pada CLI buatan seseorang atau alat yang berbicara dengan API GitHub yang kemungkinan kecil masih terawat 5 tahun lagi
  Lebih tepatnya, yang dibutuhkan bukan sekadar alat yang “bisa dijalankan” secara lokal, melainkan alat local-first yang terintegrasi secara lokal dengan editor dan sebagainya
  Alasan ini sulit menjadi fitur kelas satu adalah karena upaya yang dibutuhkan besar. Satu antarmuka web bisa “berjalan” di semua platform dan lingkungan editor karena memaksa pengguna, tetapi integrasi yang lebih rapat berarti kalau ada N editor dan lingkungan, dibutuhkan N integrasi
  Hal yang sama berlaku untuk CI. Saya ingin bisa dengan mudah menjalankan pengujian di Linux, FreeBSD, dan macOS tanpa harus push commit ke branch lalu menunggu 15 menit sampai pekerjaan terambil
  Bentuk seperti run-remotely some-command --on freebsd,linux,mac sudah cukup
  Pada dasarnya ini adalah sistem CI terdesentralisasi yang local-first, tetapi sekaligus juga harus mendukung sistem terpusat sebagai satu-satunya sumber kebenaran yang memastikan semua kode melewati sistem “resmi” yang sama sebelum di-merge
  Ini melampaui sekadar ssh user@host command ..., karena harus mencakup penyalinan source code, caching, pemasangan dependensi yang diperlukan, dan seterusnya agar setiap kali didapat keadaan yang sama dan tepercaya

  • Akhir-akhir ini saya memikirkan hal serupa
    Hanya saja saya tidak melihat ini sebagai fitur forge. Ini seharusnya disediakan sebagai alat eksekutor pekerjaan yang bisa dipakai tanpa forge tertentu dan bisa dipanggil oleh forge apa pun
    Menurut saya ini seharusnya agak “berbasis driver”. Pekerjaan yang sama bisa dijalankan sepenuhnya lokal, atau dikirim ke sistem jarak jauh untuk diluncurkan. Pekerjaan itu bisa berupa virtual machine, container, atau eksekusi langsung

• Harus mendukung sistem kontrol versi selain Git
  Issue, wiki, dan semacamnya harus bisa diimpor dan diekspor dalam format yang nyaman agar tidak terkunci pada sistem tertentu
  Self-hosting juga harus mudah

  • Mendukung semua sistem kontrol versi non-Git akan menjadi daftar yang cukup besar
    Sepertinya ada sebagian cakupan yang benar-benar penting
    Heptapod pada komentar saudara itu untuk Mercurial, dan sourcehut, juga ada
    Fossil punya forge sendiri, dan allura, versi Apache dari SourceForge, menyediakan Subversion

• Akan bagus jika ada forge yang menyediakan sesuatu yang mirip Bazel di lapisan CI
  Bukan dalam arti “bisa menjalankan Bazel di CI”, tetapi dalam bentuk yang secara alami mendorong orang menulis kumpulan pengujian dan build yang baik beserta dependensinya, sehingga waktu CI tidak terbuang tanpa alasan
  Terkait itu, saya rasa model “satu proyek = satu repositori” telah menciptakan banyak masalah
  Bisa juga disebut dukungan monorepo yang lebih baik, tetapi pada dasarnya hal seperti CI dan issue harus bisa memiliki cakupan yang lebih besar daripada sekadar “root direktori ini”
  Banyak proyek dipecah menjadi beberapa repositori karena alasan forge atau CI, dan bekerja dalam keadaan seperti itu tidak menyenangkan
  Sebagai reviewer, saya juga ingin pemecahan patch inline
  Maksudnya, saya ingin bisa memilih bagian yang menurut saya baik dan hanya menyetujui bagian itu, sehingga potongan yang memuaskan bisa langsung diintegrasikan
  Menurut saya stacked PR masih merupakan konsep yang terlalu berat
  Kalau seseorang berkata, “Saya ingin mengubah 4 file dan saya melihat ini sebagai satu PR,” reviewer seharusnya bisa berkata, “Oke, 2 file ini bagus,” lalu menjadikan kumpulan perubahan itu sebagai bagian terpisah dari PR, atau bahkan merge hanya potongan itu sebagai commit terpisah
  Stacked PR yang ada sekarang pun masih memperlakukan PR sebagai unit atomik. Dalam kebanyakan sistem, PR terasa terlalu berat

  • Hanya pengamatan sederhana, tetapi JetBrains sudah lama menentang commit per hunk
    Alasannya adalah “itu hanya subset dari file, jadi kita tidak tahu apakah akan bisa dikompilasi”
    Saya sama sekali tidak setuju dengan posisi itu, tetapi untuk melakukan hal seperti itu di tampilan web memang harus sangat hati-hati, jadi komentar ini mengingatkan saya pada hal tersebut
    Tentu saja, untuk sementara mengesampingkan komentar di atas bahwa jika Anda pemilik repositori, Anda bisa force-push branch ke versi yang Anda sukai

• Perlu ada konfigurasi CI/CD tanpa usaha
  Cukup make build, make test, make upload
  Biarkan sisanya ada di makefile, lalu dari situ bisa berkembang ke sistem build yang lebih baik
  Saya ingin dari ide sampai artefak eksekusi yang dipublikasikan memakan waktu kurang dari 2 menit

  • Kenapa harus memakai Make, yang versinya juga bermacam-macam?
    Alih-alih file konfigurasi di lokasi yang sudah dikenal seperti yang dilakukan kebanyakan sistem CI/CD, cukup taruh tiga skrip shell dengan nama yang sudah dikenal di direktori yang sudah dikenal
    Sebagai bonus, kalau butuh build Windows, itu bahkan bisa dibuat sebagai file .bat
  • Pendekatan ini bagus, tetapi mungkin akan butuh cara untuk memasang dependensi
    Itu bisa berbeda menurut sistem operasi, dan mungkin Anda tidak ingin menaruhnya di dalam makefile
  • Saya sedang membuat CI local-first yang bisa membawa isolasinya sendiri: https://ci.pico.sh
    Keunggulannya adalah semua pekerjaan berjalan di pty masing-masing di bawah zmx
    Anda bisa attach ke pekerjaan yang gagal lalu menekan panah atas dan Enter untuk menjalankannya lagi

• Saya ingin advisori keamanan dengan guardrail agar data berkualitas bisa dipublikasikan
  Diperlukan ekosistem yang berpusat pada commit supaya semua proyek bisa menerbitkan data yang bermakna, dan juga integrasi agar proyek yang menginginkannya bisa menerbitkan CVE sendiri