[ruby-dev:35415] Re: ruby_1_8_6/ruby_1_8_7ブランチのメンテナンスポリシーについて

卜部です。

実は前田さんの意見に何が何でも反対というわけではないです。卜部的には作業
が減って楽になるのでそういう意味で個人的においしい方向ではあります。

でも俺一人が楽したいを突き詰めちゃうとgit-svnで手元にローカルコピー作っ
て俺rubyを俺だけで使う話に落ちちゃうので、最大多数の最大幸福からは遠ざ
かっちゃうんですよね...

Shugo Maeda さんは書きました:
> セキュリティフィックスに限ると言いたいわけではなくて、リリースする必要がある
> と判断されるような重要な修正のみに限ってはどうかという提案です。
> セキュリティフィックスについても、それほど重要ではないと判断したものは
> ruby_1_8_6/ruby_1_8_7には適用しない、という方針です。
> もちろん、判断の基準があった方がよい(Debianのstableに対するポリシーが
> 参考になるかもしれません、と思ったのですが参考URLがぱっと見つからない)
> とは思うのですが、ある程度恣意的な側面が残っても仕方ないんじゃないですかね。
>
> 適用しなかった結果、「この修正を適用しないなんてけしからん」という人が多け
> れば、そこで考え直して適用したバージョンをリリースすればよいんじゃないでしょ
> うか。
> 逆にそういう人がそれほど出て来ない修正については、1.8系の最新を使うか、
> 自分でバックポートしてください、ということで。
>
> どんなにがんばっても批判はあると思いますが、ちゃんと耳を傾けた上で、同意
> して対処したり、反論したり、場合によっては無視すればよいと思います。
>   

仮に前田さんのご提案の方式になるのだとしたら、ここまでのご主張にとくに問
題はないと思います。今だって(見落としとかで)「この修正を適用しないなんて
けしからん」と言われることは実は経験あるし、同意したり反論したり無視した
りするのもやってきたことなので、今後も(精神的にくじけなければ、作業的に
は)やっていけるだろうと思います。

>> 私は、今のなんとなくユルい運用も嫌いではありませんが、いまの運用が許され
>> ているのは、ひとえに「問題に対する修正は重要度に限らずやがてすべての枝に
>> 入る」という前提があるからだと思っています。この前提なしでは、ある問題に
>> 対する重要度の評価がいまほどダメな状態は危険だと思います。
>>     
>
> 私としては先ほど書いたような考えなので、その前提には疑問があります。
> また、修正が少ないブランチにメリットを見い出すユーザもいると思います。
> バグ修正とはいえ、Rubyの挙動が変わればアプリケーションが期待通りに動作
> しなくなる可能性もあるわけですから。
>   

実は自分も1.8.5のメンテナンスを始める前は修正が少ないほうがいいだろうと
思ってました。自身すっかり忘れてましたが、[ruby-dev: 29800]でははっきり
『本音を申し上げれば「修正などというものは無いのが理想」』などと書いてい
たようです。

じゃあなんでそうなってないのということで、ブランチ切った直後に緊急でp2ま
で入るのは予定されてましたから、その次のp3(r11345)を見てみると、

* hash.c (rb_hash_s_create): fixed memory leak, based on the patch
  by Kent Sibilev <ksruby at gmail.com>.  fixed: [ruby-talk:211233]

という修正なんですね。

このへんまで追いかけてだんだん思い出してきましたが、rb_hash_s_createとい
うのはHash.newなわけですが、Hash.newのようなきわめて頻繁に使われるはず
(と俺は思う)のメソッドにメモリリークが残っていたことに当時かなりの衝撃を
受けた気がします。さらにp5, p6, p7あたりはどれもSEGVの修正ですけども、よ
うするにこの時期の1.8.5ではそこそこの頻度でSEGVが報告され、修正されてい
たといえます。このような状況を見ると、すくなくとも1.8.5が始まったころに
はRubyはまだ相当に不安定なように見えました。

修正が少ないブランチに価値があるのはそのブランチが十分に枯れている場合
で、不安定なままに修正が少ないのはただの放棄なわけです。なぜ俺が修正を
じゃんじゃん入れるほうに宗旨変えしたかというと、要するに修正が少ない*だ
け*では嬉しくなかったからなのでした。

> 自分の提案で、何の問題もない理想的な状況になるとは思いませんが、
> 限られたリソースですぐにできる対策としては、それなりに有効なんじゃな
> いでしょうか。
>   

限られたリソースですぐにできる対策は実は俺も考えているんですが、たとえば
今みたいに3ヶ月おきリリースとかはやめて、チェンジセット32個ごとにリリー
スとか、そういう変化量に対する基準でリリースするというのはどうでしょうか。

長所:
* 毎回のリリースで(多少の凹凸はあっても)変化の量がある程度の範囲に収まる
-> 内容を確認しやすい
* 変化がなければリリースされないので「便りのないのはよい便り」と言える
* ある程度チェンジセットが溜まったらリリース作業で強制ブレイクが入るの
で、一期に駆け込みがおこりづらくなる

短所:
* いつリリースされるかの予想は非常に困難 -> 各方面への影響が大
* あと一個修正あればリリース、とかの条件で何ヶ月も経過するかも

> で、他の対策をする必要がないと思っているわけではなくて、重要度の評価基準
> やリリース前のテストの強化についても別途検討した方がよいと思います。
> とくにテストについては、わりとだれでもできて、かつボランティアでやるにはモチ
> ベーションを維持しにくい作業が多いと思うので、Rubyアソシエーションで何か
> できないか検討したいと思います。
>   

テストはまあ、できる範囲でやってはいるんですよ。手元では。毎回make
test-allで失敗が増えないのまで確認してからコミットしてるし。テストで困っ
てるのは、ちょっと前にもありましたけど、プラットフォーム固有のバグを修正
するであるとかの場合に、手元ではなんとも確認できないことがわりとあって、
勘というか目視に頼らざるをえない場合がままあるのが何とかならないかなーと
思ってます。俺が目で見た程度で気づくバグばかりなら世界はもっと平和なわけ
で...