Rubyの開発

Rubyの開発に参加するのに必要なことのメモ。

前提

宛先

バグ報告や機能追加要望は雑談レベルならlistに、開発レベルならdevに。
バグ報告だけもないよりはいいのだけれども、パッチを投げる方が望ましい。
というか、早く修正してほしいならパッチもつけましょう。
特に機能追加に関してはパッチがあるかないかで対応がかなり違います。

パッチを送る

# CVSを導入し、Rubyのソースをcheckoutする (http://www.ruby-lang.org/ja/20020106.html)
# 適当に変更する
# cvs diff -u でdiffをとる。
# 変更の理由を書く。バグならそう書き、機能追加要求ならなぜその機能が欲しいか書く。書き方は後述。
# ruby-devに投げる。

機能追加要求に際しての戦術

機能追加要求の場合、その理由が重要で、これがはっきりしない場合は却下されます。

主な理由としては二つです。

利便性

こちらで攻める場合は、その機能があることによって楽の出来る例を挙げましょう。
また、提示した解決策以外の解決策がある場合、
それとの比較およびそれらに対するメリットを提示します。
このとき、複数の解決策でメリット・デメリットがある場合でも、
自分が推すものを一つあげておいたほうが話が早いでしょう。

整合性・統一性

これがあったほうが言語的に・設計的に美しいというケースです。
実例としては[ruby-dev:24104] String#clearが好例でしょう。

コミッタになる

ライブラリを標準添付にさせることに成功したり、
継続的にRubyに変更をすることが予想される場合、
コミッタになる必要があります。

コミッタになることについて合意を形成されたうえで、
まず、GPGの公開鍵を前田さんとやりとりします。
わたしは実際に会ってやりとりしました。
そのあと、ssh2の公開鍵をGPGで署名して送ります。

そうすると、英語のメールが届くのでコミットできるようになります。

コミットする

普通にコミットすればOK。
ちゃんとcvsのログは書きましょう。
ログの書き方は他の人のものを参考に。

バグ修正の場合fixed: [ruby-devなんちゃら]とかかくと、
自動的に先述のruby bugtraqで捕捉されるようです。

また変更した時は忘れずに
/ruby/Changelogも変更しましょう。
これも他の人のを参考にして書きます。

!!ブランチ

現在HEAD（ruby1.9系）とruby-1-8が運用されています。