フォージに何を求めますか？
(lobste.rs)- Jujutsu や他のバージョン管理システムのユーザーにとって、主要なフォージが十分に扱っていない純粋な Git ワークフローが議論の対象となっている
- 主な関心は、SPA/JS やサーバーサイドレンダリングHTMLのような実装方式ではなく、リポジトリがバージョン管理機能をどのように表現し、動作させるかにある
- Tangled、GitHub の stacked PRs、forgefed のようなアイデアはあるが、設計に関するユーザーの意見が集まる場を見つけるのは難しい
- stacked PR/MR や代替的なコラボレーションモデルも含まれ、既存のフォージを超えたバージョン管理体験が主な争点となっている
- タグ、コミット、ツリー、blob のような リポジトリオブジェクトの表示はフォージごとにおおむね似ており、些細なフォーマットの違い以外に議論はほとんどない
1件のコメント
Lobste.rs の意見
コードレビューコメントがリポジトリ自体の一部でないなら、決して使えない
メーリングリストやデータベースのサイロ、HEAD コミットハッシュに固定されない別レイヤーに貴重な過去の文脈を保存するのは、根本的に GitHub と同種のリスクだ
Fossil はこの方向に一部進んでいるが、扱うのは issue だけで、コードレビューはまだメールパッチ方式だ: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
ひとたびこの情報がバージョン管理システムの中に入れば、その上に優れた Web UI、RSS フィード、メーリングリストを載せられる
2つ目の機能は マージキュー の組み込みサポートだ。些細でないプロジェクトでは、個々のコントリビューターが main ブランチへ直接 push すべきではなく、特定のコミットを「統合準備完了」とマークしたら、ボットが提案された変更を直列化し、CI を最適にスケジュールし、main を検証済みハッシュへ進めるべきだ
3つ目の機能は、Windows や macOS など異種環境での隔離されたジョブ実行基盤としての CI だ: https://gregoryszorc.com/blog/2021/…
誰でもアカウントを作成して issue を開けるべきだが、スパムはあってはならない
今の GitHub はこれをかなりうまくやっている。たまにスパムを見るが、悪用報告のあと非常に素早く削除される。裏では自動化の山と実際の人間による分類チームが動いているのだと思う
趣味プロジェクト用の「フォージ」として Fossil を見ているが、外部コントリビューターは多くなさそうなので、コードレビューはあればうれしい程度だ
その代わり、同期できて、送れて、好きなように問い合わせられる SQLite DB が欲しい
git-pr で次の大きなリファクタリングとしてやろうとしているのは、SQLite DB を SSH コマンドとして公開することだ:
ssh pr.pico.sh sqlSQLite は必要な場所にはどこにでもあり汎用的だが、フォージの一部として扱う使い勝手が欠けている
ただ、force push や squash merge のように 履歴が書き換えられる場合、コメントがあとでどこに「固定」されてユーザーが見つけられるのか気になる
GitHub ではその基準が Pull Request なので、含まれるコミットが変わっても議論を見られる
このシステムも、リポジトリ内に保存される別個の PR 概念を置くのか、それとももっと緊密に統合された何かを想定しているのか気になる
それでも
jjをうまく使っているので、実際には大きな問題ではないのかもしれないGerrit とメールを両方使っていると、pull request モデルが最も支配的なのは残念だ
特に、メンテナーがスタイル程度の細かな指摘をコメントで残すより、自分で直してしまえばよい場面ではなおさらで、コントリビューターはそうしたスタイルをそれほど気にしないことが多い
しかしもっと残念なのは、最近ますます使われている Darcs や Pijul について、メール以外のワークフローがまったくない点だ
メールの代わりに XMPP ベースだとよい。作業中のパッチについてリアルタイムの分散コラボレーションができ、パッチセットごとに MUC を1つ持つこともできる
MUC はボイスチャットのように開けて、ロール、添付ファイル、リアクション、検索、MAM、モデレーション、完了後の tombstoning のような機能もすでに XEP で定義されている
購読には PubSub を使い、CI の伝送手段としても活用できる
実用的にするには専用クライアントが必要だろうが、多くの機能はどのクライアントでもそのまま動かせるはずだ
現実的には、古い連合技術が思いがけず拡張されていく様子に最近惹かれている、というだけかもしれない
コードレビューと承認がボトルネックだ
コード投稿者とのコミュニケーションは遅延が非常に大きく、数週間や数か月かかることもあり、信頼性も低い。PR を出して消えてしまう人もいる
往復のやり取りを前提にした GitHub モデルは、ここでは完全に崩壊する
レビュー中にコードを直接修正し、
git-absorbのようにコミットを amend できるとよい。typo のような些細な問題で投稿者と往復するのは時間の無駄で、GitHub の Edit Suggestion ハックは煩雑で履歴を汚す同じコードを再レビューしたくない。ある関数やあるコミットだけに問題があるなら、残りは先に承認しておき、投稿者が force push で直したときにもう一度見る必要がないようにしてほしい
PR の一部だけをマージしたり、PR を閉じずにコミットを除去できたりするとよい。機能そのものは要らなくても、その基盤作業は残す価値があることがあるし、逆に不要な「整理」やフォーマット変更が紛れ込むこともある
元の投稿者が対応しないとき、他の人が PR 上で協業し、磨き上げ、問題を解決できるべきだ。GitHub モデルでも理論上は可能だが、実際には別の PR に対する PR を作る隠し技に近く、そのコードや通知は対象プロジェクトには見えない。人々が fork して修正 PR を出すと、混乱とマージ衝突しか生まれない
提出されたコードがだいたい十分良いが、少し改善してほしいことはよくある。投稿者の立場では、きれいな仕上げを全部終えるまで PR が人質に取られているように感じて苛立たしいし、メンテナーの立場では、すぐマージした結果、投稿者が消えて後続の改善が永遠に行われないリスクがある。あとで整理する義務付きで一時的にマージする方法があるとよい。たとえば staging ブランチにはマージするが、FIXME が解決するまで安定ブランチには cherry-pick しない、といった形だろう
人気のあるオープンソースプロジェクトでは、プロジェクトを前に進めるコードレビューと承認を行える人が1人しかいない一方で、貢献して助け合いたい人が500人いる、という状況が起こる。GitHub モデルはこの過剰な貢献者の能力をまったく活用できない。協業を助ける代わりに、危機、混乱、怒った集団圧力へと変えてしまう。単一のメンテナーに塞がれず、他の人々が実験しプロジェクトを前進させられるよう、fork の管理と fork 間のコードコピーをよりよく支援すべきで、メンテナーは複数の fork から人気があり動作確認された変更を簡単に選べるべきだ
組織ではこれがデフォルトだった気がするが、とにかくこの場合は force push で直接きれいに直せる
往復する価値のない小さな修正には、いつもそうしている
たいてい数か月や数年単位で測る感覚だ
たまに自分がメンテナーの側になることもあるし、自分もいつもこれより速いわけではないと認める
定義へ移動、シグネチャやドキュメントコメントを見せる hover ポップアップのような機能が欲しい
ブランチを checkout して好みのエディタでレビューすれば可能だが、言ったようにレビューがボトルネックだ
複数の PR をレビューするたびにブランチをあちこち切り替える追加作業は大きすぎる
単一ユーザー、あるいは少なくとも単一ユーザーモードが必要だ
なぜ https://code.chrismorgan.example/chrismorgan/repository-name のような URL を受け入れなければならないのか？ https://code.chrismorgan.example/repository-name でいいのに
本気でそう思っているし、https://github.com/go-gitea/gitea/issues/11028 を見ると、こういうものを望む人が確かに多いと分かる
Fediverse のアカウントを持っていない主な理由の1つも、アドレスがひどいことだ
メインのメールアドレスのように @me@chrismorgan.info を使えば、人によっては単に「@me」と見えるかもしれないし、@chrismorgan@chrismorgan.info は見るだけで嫌だ
この点は ATProto が非常にうまくやった。ドメイン名はハンドルとして優秀で、複数ユーザーが必要ならサブドメインで十分だ
共有フォージでもサブドメインを使えば、論理的には単一ユーザーのようにできそうだ。github.com/chris-morgan の代わりに chris-morgan.github.com を想像すると面白いかもしれない
美しさは重要だ
単一ユーザーへ向かうことは、より大きな結果ももたらす。Mastodon のようなものを単一ユーザー用に縮小しても依然として重いが、最初から単一ユーザー向けに設計された Fediverse プロジェクトはその用途により適している
自分のサーバーを自分で運用しつつ、ローカルユーザーは自分1人だけでありたいし、他のユーザーがいる可能性のために妥協したくない
これは、フォージで使われる
gitのような汎用ユーザー名ではなく、普通の SSH のようにchrisというユーザー名で push したい、という意味でもある一般に理解される意味でのフォージなら、連合は当然必要だ。だが各自の「ホームサーバー」にはローカルユーザーが1人だけであってほしい
自分の名前のドメインを使うなら、そこでも似たような問題がない？
この話題についての Nesbitt’s article が気に入った
特に ダウンストリームとのより良いコミュニケーション がよかった
好きなエディタで ローカルコードレビュー ができるべきだ
変えられないフォントとひどいシンタックスハイライトの鈍重な Web インターフェースに閉じ込められたくない
現在は Neovim 向けのカスタムツールで並列 diff を見やすくし、
git prコマンドで pull request を checkout するワークフローを使っているしかし、レビューコメントを残すといった少し先のことをしたいだけで、5年後も保守されている見込みの薄い誰かの CLI や GitHub API と通信するツールに依存することになる
より正確には、単にローカルで「実行可能」なツールではなく、エディタなどとローカルで統合される ローカルファーストのツール がもっと必要だ
これが一級機能になりにくい理由は、必要な労力が大きいからだ。1つの Web インターフェースはユーザーを強制することで、あらゆるプラットフォームと編集環境で「動作」するが、より緊密な統合では、エディタと環境が N 個あれば統合も N 個必要になる
CI も同じだ。コミットをブランチに push して 15 分間捕まるのを待つのではなく、Linux、FreeBSD、macOS でテストを簡単に回したい
run-remotely some-command --on freebsd,linux,macのような形でよい基本的にはローカルファーストで分散型の CI システムでありつつ、同時に、すべてのコードがマージ前に同じ「承認済み」のシステムを通過したことを保証する単一の真実の供給源としての中央システムも支援すべきだ
これは単なる
ssh user@host command ...を超える。ソースコードのコピー、キャッシュ、必要な依存関係のインストールなどを含め、毎回同じ信頼できる状態を得る必要があるからだただ、これはフォージ機能ではないと思う。特定のフォージなしでも使え、どのフォージからでも呼び出せる ジョブ実行基盤 ツールとして提供されるべきだ
少し「ドライバーベース」であるべきだと思う。同じジョブを完全にローカルで実行することも、リモートシステムへ送って立ち上げることもできる。そのジョブは仮想マシンかもしれないし、コンテナかもしれないし、直接実行かもしれない
Git 以外のバージョン管理システムもサポートすべきだ
issue や wiki などを扱いやすい形式でインポート・エクスポートできれば、特定のシステムに縛られない
セルフホスティングも容易であるべきだ
実際に重要な一部の範囲があるはずだ
兄弟コメントの Heptapod は Mercurial 向けで、sourcehut, also もある
Fossil には独自のフォージがあり、SourceForge の Apache 版である allura は Subversion を提供している
CI レイヤーに Bazel 的な何か を提供するフォージがあるとよい
「CI で Bazel を実行できる」ではなく、人々が依存関係を備えた良いテストとビルドのまとまりを書くよう自然に導き、特に理由もなく CI 時間を燃やさないようにする形だ
関連して、「1プロジェクト = 1リポジトリ」モデルが多くの問題を生んだと思う
より良いモノレポ対応と言い換えてもよいが、基本的には CI や issue のようなものが「このディレクトリの最上位」より大きな範囲でスコープされるべきだ
多くのプロジェクトがフォージや CI の都合でリポジトリを分割しており、その状態で作業するのは楽しくない
レビュアーとしては インラインのパッチ分割 も欲しい
良いと思う部分を選び、その部分だけを承認して、満足できる部分を統合できるようにしてほしいということだ
スタック型 PR は、依然として重すぎる概念だと思う
誰かが「4ファイルを変更したい、そしてこれを1つの PR と見ている」としたら、レビュアーは「よし、この2ファイルは問題ない」と言って、その変更のまとまりを PR の別部分にしたり、さらにはその断片だけを別コミットとしてマージできるべきだ
現在のスタック型 PR も、依然として PR を原子的単位として扱っている。ほとんどのシステムでは、PR は重すぎると感じる
理由は「それはファイルの部分集合なので、コンパイルできるか分からない」というものだった
その立場にはまったく同意しないが、Web ビューでそういうことをやるにはかなり慎重である必要があるので、このコメントを見てそれを思い出した
もちろん、上のコメントのようにリポジトリ所有者なら好みのバージョンでブランチに force push すればよい、という話はいったん脇に置くとして
手間いらずの CI/CD 設定 が必要だ
make build,make test,make uploadだけあればよい残りは makefile に置かせてくれれば、そこからより良いビルドシステムへ進められる
アイデアから公開された実行成果物まで 2 分以内で行きたい
多くの CI/CD システムがそうしているように既知の場所の設定ファイルを使う代わりに、既知のディレクトリに既知の名前のシェルスクリプトを 3 つ置けばよい
おまけに Windows ビルドが必要なら
.batファイルにすることもできるOS によって異なるかもしれないし、makefile の中には入れたくないかもしれない
利点は、すべてのジョブが zmx 配下の専用 pty で実行されることだ
失敗したジョブに attach して、上矢印と Enter で再実行できる
質の高いデータが公開されるようガードレールを備えた セキュリティアドバイザリ が欲しい
すべてのプロジェクトが意味のあるデータを公開できるよう、コミット中心のエコシステムが必要であり、望むプロジェクトには自分で CVE を発行できる統合も必要だ