From: Akinori MUSHA Date: 2006-11-06T00:19:55+09:00 Subject: [ruby-dev:29837] Re: 1.8 proposal of RUBY_PATCHLEVEL At Sun, 5 Nov 2006 20:57:41 +0900, MoonWolf wrote: > Akinori MUSHA wrote: > >> Akinori MUSHA wrote: > >>> 　要するに常に最新のものを基準とし、個々のパッチの取捨選択の > >>> 面倒は見ないでいいと思います。修正同士の衝突や依存関係を考え > >>> 出したらきりがないし、個別にサポートすることも困難です。 > >> 今回の提案は全てがセキュリティのパッチであるということではありませんよ > >> ね?「なんらかのパッチセット」と書かれています。 > >> 深刻なバグに対するフィクスであり互換性に影響がなければ取り込まれるものと > >> 認識しました。 > > > > 　そのコンセンサスは取れていないと思います。セキュリティとともに > > 仕様の安定性を重視するブランチであれば、セキュリティ上の問題が > > なければバグも含めて修正しないというポリシーもあり得ます。 > > 修正しないというポリシーもあり得ますが、いまの1.8をそこまでガチガチに固 > めるといったことは私がみたところ求められてはいないように思います。 > ある程度の頻度でバグが修正されたバージョンが欲しい。でも次のリリースがい > つになるかわからない。1.9にあげるのは互換性の問題で無理。といった感じです。 　まあそれはひとつの意見表明ということで、議論しましょう。 > >> # じゃあ普通のリリースとの違いは?といわれると？？？となります。 > > > > 　ブランチのポリシー次第ですが、正規リリースは事前にスケジュール > > され、RCを重ねてQAを行うものだと思います。そうしたプロセスを必要 > > とするブランチはつまりそれだけの規模・種類・数の変更があるという > > ことでもあり、逆にセキュリティ・仕様安定性最重視ブランチでは正規 > > リリースのようなプロセスは不要でかつ無用のはずです。 > > セキュリティ最重要視なのにQAも不要なのですか? > 修正によって本当に対策できたか?修正漏れはないか?修正によって互換性を損な > わないか?エンバグしてないか?こういう確認を行うのはQAとは呼ばないのかな? > 私は品質について詳しくないのでQAとQCの違いがよくわかってません^^; 　いや、脆弱性の修正についてはRCを通じた公開ベータテストよりは 手元で確認すべきケースの方が多いという意味もあります。時間的にも、 情報の性質的にも。 -- / /__ __ Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Different eyes see different things, Different hearts beat on different strings -- But there are times for you and me when all such things agree"