GuixがCodebergへ移行して1年
(guix.gnu.org)- Guixは10年以上にわたりSavannahとメールベースのDebbugsで運用してきた協業方式を2025年にCodebergへ移し、年間400人超が参加するプロジェクトの貢献の入口を大きく変えた
- この移行は、2024年12月に導入されたGuix Consensus Document手続きの最初の実践例であり、GCD 002は2か月の議論を経て2025年5月初めに発効した
- 既存のメールワークフローはEmacs、mumi、qa.guix.gnu.orgのようなツールのおかげで熟練者には効率的だったが、900人が回答したアンケートでは、貢献者にとっての障壁としてたびたび挙げられた
- Codeberg移行後はコミット作成者数と新規作成者数が増えたものの、2025年6月の一時的なピークを除けば、明確なCodeberg効果を確認するのは難しい
- 毎月500件を超えるプルリクエストが開かれてバックログが拡大しており、CIの空白・署名要件・レビュー負荷を減らすことがGuixの次の実務課題として残っている
メールベースの協業からCodebergへ移行
- Guixは2025年にソースコードホスティング、課題追跡、プルリクエストをCodebergへ移行した
- それ以前は10年以上にわたって Savannah にコードをホスティングしていた
- バグ報告とパッチはメールで処理し、Debbugsインスタンスで追跡していた
- 毎年400人超がコードに貢献するプロジェクトであるため、移行そのものが大きな変化だった
- 既存の中核貢献者はメールワークフローに慣れており、Emacs向けDebbugsパッケージや高機能メールクライアントで効率的に作業していた
- Debbugsは数百行のPerlコードとメール標準・連合構造に依存する一方、ForgejoのようなWebフォージはGo依存の多い、より大きなシステムである
- メールフローの周辺にはすでに補助ツールも整備されていた
- mumi はDebbugs向けのWebインターフェースを提供する
- Quality Assurance service はメールのパッチシリーズをGitブランチに自動適用し、そのブランチでパッケージをビルドする
- 2025年1月に公開された最初のユーザー・貢献者アンケートには900人以上が回答し、貢献者はメールワークフローを貢献への障壁としてしばしば挙げた
GCD 002で進めた合意ベースの意思決定
- Guixには意思決定を行う「benevolent dictator」はおらず、2024年12月に Guix Consensus Document process を導入した
- GCD手続きは単純な投票よりも合意形成を目指す
- 提案作成者は参加者とともに提案を調整しなければならない
- 参加者は単に反対するのではなく、自分の必要と、それを反映する具体的な変更を提案しなければならない
- 最終案では
support、accept、disapproveで立場を示す
- GCD 002 は2025年2月、Codeberg移行の提案として提出された
- 議論 は手続き上の最長期間である2か月にわたって行われた
- Guixチームメンバーの3分の2が熟議に参加した
- 参加者の72%は
support、残る28%はacceptを選んだ disapproveはなく、提案は2025年5月初めに発効した
- 長く貢献してきた一部メンバーは、Web優先に見えるワークフローがメールより非効率だと感じ、メールベースのインフラの一部を手放すことにも消極的だった
- より広いコミュニティとの接点が生まれ、開発者体験が改善される可能性がこの移行を後押しした
- 自由ソフトウェアベースのフォージと、非営利団体 Codeberg e.V. がホストするフォージを好んだ点は大きな論争を生まず、Guixの志向とも合っていた
段階的な移行と想定以上に大きかったCIの空白
- Codebergへの移行はGCDの合意どおり段階的に進められた
- メインリポジトリは2025年5月25日に 移行 された
- 旧リポジトリは現在もミラーとして残っている
- 既存の課題・パッチトラッカーは2026年1月1日まで維持される
- 以後はCodebergの課題とプルリクエストだけが正式にサポートされる仕組みとなる
- 過去のバグ報告とパッチは オンラインでアクセス できる
- 合意形成の議論の中で作られた計画のおかげで、移行時の大きな問題や想定外の事態は少なかった
- Codeberg e.V.のスタッフとボランティアによるサービス品質は良好で、断続的なダウンタイムも通常は短く、明確に告知された
- ブラウザ外のワークフローを好む貢献者にとっては、Emacsインターフェースの改善が助けになった
fj.elと Emacs-Forgejo が発展した- AGit workflow でプルリクエストを作成できる点も、適応負担を軽減した
- 十分に予測できていなかった問題は、プルリクエスト向け継続的インテグレーションだった
- qa.guix.gnu.orgでメールパッチをビルドしていた機能はCodebergへ移植されなかった
- 数か月のあいだ、レビュー担当者がプルリクエストに問題がないかを自分で確認しなければならず、持続可能な状態ではなかった
- 2025年9月には Cuirass インスタンスが pulls.ci.guix.gnu.org に構築され、プルリクエストのビルドを開始した
- 当初はqa.guix.gnu.orgより制約が多く、暫定対応 と見なされていた
- 現在、パッケージは単一アーキテクチャ向けにビルドされている
- 新規貢献者は
guix-cuirass-botがプルリクエストに残す成功・失敗の結果をすぐに確認できる
貢献の流れは増えたがバックログも拡大
- 2024年5月から2026年5月までのメインブランチへのコミット数を見ると、Guixのコミット速度は一貫して「高い」と「非常に高い」の間にとどまっている
- コミット速度だけでは変化が見えにくいため、月ごとのコミット作成者数・コミッター数・新規コミット作成者数のほうが有用な指標となる
- 月ごとの作成者数と新規作成者数は継続的に増加している
- Codeberg移行直後の2025年6月には、作成者数と新規作成者数の両方でピークがあった
- それ以外の期間の成長は、2025–2026年区間と2024–2025年区間でほぼ同程度だった
- Guixは継続して新規貢献者を引きつけているが、明確なCodeberg効果は大きくなかった
- 月ごとのコミッター数の増加は作成者数の増加より緩やかで、これはコミッターがより多くの貢献を処理していることを示唆する可能性がある
- プルリクエストのデータはCodebergの Forgejo API で収集された
- 毎月500件を超えるプルリクエストが開かれ、マージ速度も高いが、流入をやや下回るためバックログは増え続けている
- 現在オープンなプルリクエストは全6,459件中およそ639件で、約10%に当たる
- 比較対象として挙げられたNixpkgsでは、全473k件中オープンなプルリクエストは12k件で約2.5%である
- Guixのバックログは、過度な摩擦や不十分なCIフィードバックが原因かもしれない
- Guixでは各コミットに 承認されたコミッターの署名 が必要である
- Nixpkgsを含む多くのプロジェクトのように
Mergeボタンを押すだけではない - マージする人が変更を適用し、署名する責任を負う
- Guixは開発者の利便性と ユーザーのセキュリティ の間で、ソフトウェアサプライチェーンの安全性を選んでいる
- このコストを減らせるかどうかは、まだ確認が必要である
- Nixpkgsを含む多くのプロジェクトのように
Codebergでより見えやすくなった協業
- Codeberg移行後、プロジェクト活動はより可視化された
- CI結果がプルリクエスト内に直接表示されるため、貢献者はすぐ確認できる
- Guixの チーム はCodebergのチームとして実装されている
- チームの担当範囲は
CODEOWNERSファイル に明記されている - 該当範囲の担当者が自動的に呼び出される
- ボットは
team-pythonのようなラベルを付け、課題とプルリクエストをラベルでフィルタリングできるようにする
- チームの担当範囲は
- そのラベルが付いた課題でチームが通知を受け取れない問題 は不便な点として残っている
- 課題とプルリクエスト間の相互参照や、マイルストーン のような機能も協業に役立っているようだ
残るインフラ課題とCodebergとの関係
- Guixのインフラには、なお一層の支援が必要である
- パッケージャーのワークフローにも改善の余地がある
- トピックブランチとworld rebuild scheduling は、引退したバグトラッカーにかなり依存している
- GuixはCodebergサーバーに過度な負荷をかけないようにしつつ、リポジトリ使用量も監視しなければならない
- Codebergサーバーに 過度な負荷を与えた事例 があった
- Guixの単一フォークが、Codebergの新規ユーザー向け750MiBクォータを超える可能性がある
- 解決策として、新規貢献者に AGit workflowを使ってプルリクエストを作成するよう求める 案がある
- AGitはGuix貢献者の間ですでに人気がある
- ただし、慣れ親しんだ一般的なプルリクエストワークフローより馴染みにくく、「ダウングレード」と見る人もいる
- Gentooの事例のように「AGit fork」アイコンを追加すれば、見つけやすさを高められるかもしれない
- Guix Foundationは感謝と支援の表明として、Codeberg e.V.の支援会員になることを 投票 で決めた
- Forgejoと、それをGuixで設定するサービスを追加するプルリクエスト が提出された
- 宣言的設定と再現可能なフォージ展開をGuix内で実現できる方向性である
1件のコメント
Lobste.rs の意見
Codeberg への移行に関連する実際のプロジェクト指標を見るととても興味深い。個人的には GitHub を離れるべき理由があまりにも多いので、Codeberg が新しい GitHub になってほしいと思っているが、自分は独自の Forgejo サーバーへ移行し、今はすべてのリポジトリのバックアップ先として Codeberg を使っている
新たなオープンソース中心のハブはもう必要ない
これまで非常に満足しており、
gitより明らかに好んでいる。今どきの基準ではそのハードルもそこまで高くはないがCodeberg を使い始めてから本当に腹立たしかったのは、git 連携をきちんとサポートするツールがほとんどなく、実際には GitHub / GitLab 専用である場合が大半だという点だ
magit forgeを使っている身としては泣ける以前の課題・パッチ追跡システムを 2026 年 1 月 1 日まで維持し、その後は Codeberg の Issue と Pull Request だけをサポートするようにしたという点は理解できない
貢献者のかなりの部分が新しい流れを嫌っているのなら、なぜ強制的に変えるのかわからないし、複数の流れを許容することに隠れたコストがあるのかも気になる。なぜ全員に同じやり方を強いる必要があるのか疑問だ
些細な揚げ足取りではあるが、Codeberg には有給スタッフが何人もいるようには見えず、私の知る限り 1 人だけだった。訂正: 昨年 12 月に 2 人目のスタッフを追加したとのこと