[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:18931] Jessieがstableになった後でもフレッシュなバージョンでより大きな価値を届ける方法(という妄想)



 やまねです。

 ちょっと私の妄想にお付き合いいただけますでしょうか。


 Jessieはおそらく4月末ぐらいにはstableになるんじゃないか、と観測
 されています。んで、stableというと皆一様に言うのが「バージョンが
 古い」という奴です。

 これはある程度宿命的ではあると思いますが、一応今度からはbackports
 がdefault installで有効になるようにしましたので多少は緩和されたか
 と思います。

 が、しかし、backportsは明示的にbackportsのパッケージを使うよ、と
 いうのを指定しないといけないわけで、全員が全員この恩恵を浴びるか
 というとちょっと難しいように感じます。

 
 ここまでが前フリ。

 stableのパッケージをリリース後も新しくしちゃおう!というのができない
 だろうか、と妄想をしています。

 考え方としては leaf package に限って例外を認める、というものです。
 (leaf update exception)

 leaf package は他のいかなるパッケージからも依存されてないパッケージ
 です。つまり、これをアップデートしたところで依存関係が崩壊したり、
 リグレッションがあったとしても局所的に収まります。


 leaf packageのアップデートの流れは以下の5つのうちどれか、と考えています。

 unstable -> testing -> backports ->
   a) stable-proposed-updates -> stable
    b) stable-proposed-updates -> stable-updates
    c) stable-proposed-updates -> stable-leaf-updates
    d) stable-updates
    e) stable-leaf-updates

 一応、unstable -> testing -> backportsの間に最低限の「目」による
 チェックを受けてから、stable関連に放り込むという形です。

 stable に突っ込むのか、stable-updates/stable-leaf-updatesに
 入れるかの違いは、より保守的に使いたい人はstable-updates/stable-leaf-updates
 を切るという選択肢を入れてあげたほうがいい気もするからです。


 leaf update exceptionのメリットは
  - ユーザーがほぼ no configuration で更新したパッケージを使える
  ようになり、追加・更新された機能によるより大きな価値を得られる
  - 忌避されるregressionは存在しても局所的で、しかも随時更新のため
  に短い期間で済む
  - 完全にstableに統合できるならば、security fixのdeltaがupstream
  と小さくてすみ、コストが下がる

 と考えています。


 これをお読みになられた人で、なにかアイデアに対して議論ができれば
 嬉しいです(で、うまく行きそうであればdebconfに持って行ってみよう
 と思います)。


-- 
Regards,

 Hideki Yamane     henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane