前田です。

ruby_1_8_6/ruby_1_8_7ブランチのメンテナンスポリシーについての提案です。

今回の脆弱性対応について色々考えてみたのですが、デグレードが起きてしまった
要因の一つに現在のブランチのメンテナンスポリシーがあるように思います。

たとえば、1.8.6を例に取ると今回リリースされた1.8.6-p230の前にリリースされた
のは1.8.6-p114ですので、116もの修正が適用されていることになります。
いかにテストを充実させたとしても、これだけの修正が適用されたものにデグレード
がないことを、少人数・短期間で検証するのは非常に難しいと思います。

脆弱性の影響が今回のもの程度であれば、まつもとさんが言われていたように通常
通りの手順でruby-devで議論した上で、release candidateを多くの人に試して
いただいてからリリースするという手順を踏めるかもしれませんが、報告される脆弱
性によってはそれではまずいケースも考えられます。
また、脆弱性の影響が低いと我々が判断したとしても、今回のように第三者から、
「任意のコードを実行される可能性がある。修正の公開は○月○日まで待って
ほしい」と言われたら、それに反論して上記のような手順を踏むのには相当の確信
がないと難しいと思います。

で、ここからが提案なのですが、ruby_1_8_6/ruby_1_8_7ブランチでは、適用後
ただちにリリースを行う必要があるような重大な修正(たとえばセキュリティフィックス)
以外は行わないようにしてはどうでしょうか。

これにより、

* セキュリティフィックスをリリースする際のデグレードのリスクを減らすことができる。
* ディストリビュータが脆弱性に対する修正点を確認しやすい。
* メンテナの負担が減る。

というメリットがあります。

デメリットは、これまで行われていたようなバグ修正がruby_1_8_6やruby_1_8_7
に適用されなくなることですが、リリースしなくても大多数の人はそれほど困らない
ような修正なら1.8.8まで待ってねということでよいのではないでしょうか。
それよりもセキュリティフィックスの際に混乱が起きないことの方が重要なように思います。

別の案としては、セキュリティフィックスを出す際には、直前にリリースしたパッチレベル
まで遡ってセキュリティフィックスだけ適用したものをリリースする、ということも考えられ
ますが、バージョニングをどうするかが問題になりますし、私としては前者の案の方が
シンプルでよいと思っています。

-- 
Shugo Maeda