Yugui さん、
遠藤です。

いい加減、1.9.2 をリリースしましょう!

勝手に作ったリリーススケジュール案です。


  - 3 月末: 仕様フリーズ
  - 4 月末: コードフリーズ
  - 5 月末: 1.9.2-preview2 リリース
  - 6 月末: 1.9.2-rc リリース
  - 7 月末: 1.9.2-p0 リリース


それぞれのイベントの内容は以下の通りです。


=== 3 月末: 仕様フリーズ ===
* 1.9.2 での導入を目指す Feature チケットを締め切る

  - この時までに API 設計の合意がなされなかった Feature チケットは
    1.9.2 には入らない (target を 1.9.x に変更する)
  - これ以降に登録された Feature チケットは 1.9.2 には入らない


=== 4 月末: コードフリーズ ===
* 1.9.2 での導入を目指す Feature の実装を締め切る

  - この時までに trunk にコミットされなかった Feature は 1.9.2 には
    入らない (たとえ 3 月末に合意していても)
  - (推奨しないが、多少未完成でもコミットされれば生き残る)


=== 5 月末: 1.9.2-preview2 リリース ===
* 1.9.2 で導入される Feature set を確定する

  - この時までに、安定していない or 未完成と認められる Feature は
    revert される
    - 重大なバグが残っている、バグが短期間に多数報告された
    - API 設計や名前などの議論・懸案が残っている、など

* 1.9.2 で対処すべき Bug チケットを整理する

  - Bug チケットはこれ以降に登録されたものも考慮される
  - 評価は保守的になる (「直感に反する」などが理由なら 1.9.x 行き
    または reject)

* サードパーティの対応を呼び掛ける

  - いろんなプラットフォームでテストしてもらう
  - 1.9 対応を謳う 3rd party project でテストや修正をしてもらう


1.9.2 に不可欠と考えることに合理的な理由があると認められる Feature
(dl on libffi など?) が安定していない場合は、最長 1 週間遅延する。


=== 6 月末: 1.9.2-rc リリース ===
* 1.9.2 で対処すべき Bug チケットの対処を終える

  - 大規模な変更が必要と判明した問題は、致命的な問題でなければ、1.9.2
    での修正見送りを決定する

Bug チケットが対処しきれない場合は遅延する。


=== 7 月末: 1.9.2-p0 リリース ===
* 2 週間ほどバグ報告を待つ

Bug チケット数が 0 になったらリリースする。


この予定でも当初の予定から 7 ヶ月も遅れます。危機感を持ってください。


-----


Yugui さん、上記スケジュール案の可否を *即決で* 判断してください。


可決の場合はすぐ ruby-core に翻訳して流します。多少の修正は受け入れますが、
bug 対応でなく feature の実装待ちを理由にした期限なし延期を最初から予定に
組み込むことは受け入れません。もう遅れすぎなのです。

否決の場合、または 10 日間で議論がまとまらない場合は、Yugui さんのリリース
マネージャからの discharge を提案します。当初のリリース予定日から 3 ヶ月が
経ってリスケジュールのめどが立たない状況は、Discharging Process の発動に値
すると考えます。


後者の場合はそれ自体が時間の無駄になるので (3 月末の仕様フリーズはさすがに
無理になる) 、前向きな判断を期待しています。

-- 
Yusuke ENDOH <mame / tsg.ne.jp>