2週間ぶりの定期リリース。今回のリリースでは、-j をつけたときにビルドジョブを make jobserver という仕組みで賢く振り分けたり、Fable 5 にやらせたメモリ削減を入れたり、cooldown や plugin の渋いバグを直したりとまあまあなボリュームを入れている。
https://blog.rubygems.org/2026/06/24/4.0.15-released.html
ついでに、コンフリクトをいい感じに直すのを claude に仕込みつつあるので、rb_sys のバージョン更新など、今までならコンフリクト解消だる、でやめていたのをウリャっと進めてしまった。
https://github.com/ruby/rubygems/pull/9640
あと、メンテナンスブランチへ auto pick するにはコードベースが違いすぎるので、個別に pull req を用意してマージしたやつが changelog に出てこなかったり、手元の branch が remote origin と差があるときに pick の対象とならなかったり、みたいなケースも claude に「直して」とバンバンぶん投げて直してもらった。
で、RubyGems のリリースは自動化スクリプトによる auto pick を駆使しているんだけど、2-3回は素振りをしてコンフリクトの傾向を把握してから、本番リリース、としていて素振りで修正したコンフリクトが2-3回目の試行では自動で直っていてなんで?と思ったらこれは git rerere という機能だった。
名前だけは知っていたけど、何かはよくわかっておらず、おすすめ設定として有効にしていたので適用されていた、ということっぽい。これは、コンフリクトの修正を間違えてやった場合もそのまま間違えたまま適用、を繰り返すのでだるい、となったので claude に「なんで間違えた修正が繰り返し入るんですか?」と聞いたら、rerere や、forgot を使って消すことができます、というのも教えてくれて勉強になった。
claude を使うとき、あまり丁寧に背景とか説明しないで、やりたいことだけをすごい雑に聞く、というのに慣れてきた気がする。
rubygems では 10 年くらいに渡って、トップディレクトリに bundler というディレクトリを入れたままリポジトリはモノレポだけど、ただコードが同じ箇所にあるだけ、CI には便利、一緒に直すときも便利、という物理的にしか意味がなく、コードの共有化、とか結合レベルの上げ下げ、みたいなことは何もできない状態が続いていたのだけど、AI パワーでやっと lib の下にフラットに配置してしまった。
https://github.com/ruby/rubygems/pull/9634
とはいえ、これをベースに重複している vendor コードの共通化、モンキーパッチしているコードの共通化、なども含めた大きめの計画を丸2日くらいかけて、日本語であーでもない、こーでもない、というのを考えてから「で、これ作れるんですか?」「作れます」まで行けたので進めたのだった。
https://github.com/ruby/rubygems/issues/9236#issuecomment-4748470107
実際にやってみると、手元だけでは実行できないケースで CI が落ちたものの、ひたすら claude に直させたら割とあっさり終わったので 4.0.15 のリリース後にさくっとマージしてしまった。
なんか、bundler 側に lib/rubygems/* というコードを放り込んで、ロード時に二重ロードしない、というガードを入れたら、このまままずはランタイムベースの統合を進めて行ける気がしてきたなあ。頑張ろう。