«前の日記(2008-12-07) 最新 次の日記(2008-12-13)» 編集

ポケットを空にして。

1985|10|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2100|01|

「人の心に残るというのが大事」と言う話。

何か連絡がある場合はメールでどうぞ(過去の日記へのツッコミは基本的にみていません)
プレゼントは随時受け付けております :-) ここ最近のツッコミ/トラックバックリスト。

  1. minahito (12-31)
  2. minahito (12-31)
  3. aya (12-18)


2008-12-08 [長年日記]

「出せるときにリリース」→component-based & time-based remix release

Debian に関わっているからといって、Debian 全肯定マンセー!とかいう人ではない。ので、何とかしたいところを書いてみる。

やっぱり Lenny リリースが順調に遅れてるわけですが…まぁ、構成要素があまりにも増えすぎているのに、一律リリースにしているところが問題の一つ。複雑度が指数関数的に増えていくのに対応が難しいですよね。

  • アーキテクチャごとの固有の問題点(先日は Ruby 1.9 on hppa のビルドが出来なかった、とかがありました)
  • 各ソフトウェアプロジェクトごとのリリーススケジュール(gnome, kde などはリリーススケジュールが決まってる)
  • 動いてる人はボランティアなわけで、対応に波がある
  • 利用者だって都合があるわけで、先にスケジュールが決まってた方が対応計画が立てられて楽

それによくよく考えるとですね、あるソフトウェアに致命的なバグがあったからといって影響度がどこまで及ぶかというと、要素同士の結合度がどの程度によるかという話がありますな。例えば Perl5.10.0 に問題があったからといって Python 2.5 のモジュールには何の問題もないわけです。現状のリリースマネジメントはこの点が解決できていない。

ということで、そろそろ大量のアプリケーションを一気にリリースは止めて、時間通りに出荷しましょうぜ、ということを前々から考えています。

で、どうすんのさ?というとcomponent-based & time-based remix releaseが最適だと思っています。
いくつかの "component" にソフトウェアをカテゴライズして、そのカテゴリーごとにリリーススケジュールを決める。例えば 2009/04 には GNOME 2.26 が出るので、2009/05 に GNOME を含めたリリースを出すように調整する、など。
言語は言語で perl, python, ruby, php と分けられますし、デスクトップ環境も KDE、xfce などメジャーなものからその他のものまで出来ます。

各コンポーネントごとにコンポーネントマネージャを置いてリリースマネジメントをさせ、全体のリリースマネージャの調整作業を少なくします。

で、MS 方式で毎月第2火曜とかに各コンポーネントごとのアップデート候補をリリース(適用は任意)出しておく

…とまぁ、妄想したんですが、どうでしょうねぇ。