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

In article <[e-mail]>,
  "Shugo Maeda" <[e-mail]> writes:

> 繰り返しになりますが、問題意識はセキュリティフィックスの際に無関係な修正
> のためにアップグレードが困難になることを避けたいという点にあるので、
> ruby_1_8_xに適用する修正を限定するということにはそれほど拘りはありません。

拘りはないのかもしれませんが、セキュリティフィックス以外の修
正をどう扱うかを決めないと実際の運用はできませんよね。

また、セキュリティフィックスが問題を導入することもあります。

たとえば、リストに出ている CVE-2008-2376 は Array#fill です。
この修正は挙動を変えるということで、また別の修正が入っている
のですが、それはリストにはあげられていないようです。

同様に、1.8.6p230 のセキュリティフィックスのひとつの alloca
のところの修正は潜在的に GC 問題があって、1.8 で修正しました
がまだ 1.8.6 には入っていません。

そういう問題はどう扱うんでしょうか。

もし、前田さんの当初の案のように、セキュリティ問題以外は修正
しないとすれば、これらは放っておくのでしょうか。

また、拘りはないとすれば、修正するのかもしれませんが、修正す
るとしたらどういう手順を踏むのでしょうか。

また、1.8.6p114 と 1.8.6p230 のあいだの話ですが、
[ruby-dev:34480] の GC 問題の修正が入っています。
これが以前からある問題だとすると、セキュリティ問題ではないと
いうことで、1.8.6 には入れないのでしょうか。

GC 問題はよくわからないときによくわからないことが起こるわけ
で、問題があることがわかってもどんな修正をする必要があるのか
不明なわけですが、そうすると [ruby-dev:35413] の
「この修正を適用しないなんてけしからん」という主張を行うこと
自体が困難です。そうすると必然的にその主張をする人は少なくな
り、苦労して問題を同定して主張した挙げ句に 1.8 では修正され
てるけど文句を言う人は多くないので修正しない、と却下されるの
は幸せを追求する適切なやりかたなのでしょうか。
-- 
[田中 哲][たなか あきら][Tanaka Akira]