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

[Hideki Yamane <henrich@debian.or.jp>]

　やまねです。

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


　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