[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:15762] summary of "Bits from the RM" (2003/8/19)
Anthony Towns さん <aj@xxxxxxxxxxxxxxxxxxx> は 2003/8/19 に
debian-devel-announce@lists.debian.org へ「Bits from the RM」という
題名のメールを投稿しました。いろいろ重要なことが書いてありますが、
長いので備忘録がわりに要約します。
どうやら一般ユーザが experimental を使うことを想定するように
なったようなので、testing とかぶらない訳語が必要だと思いました。
「実験版」ではいまいちです。いっそ「人柱版」か。
個人的には日程表のリリースクリティカルバグ修正法が
修羅場な感じでよかったです。
原文:
http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200308/msg00010.html
* 次のリリースの目標日は 12 月、2003-12-01 00:00:00 UTC とする。
* そもそも安定版 (stable) は必要なのかという質問がある。
安定版と不安定版 (unstable) などとのちがいのうち維持したいものに
更新頻度がある。サーバを維持するのに毎日あるいは毎週 15 分かけるより、
大規模な更新のために年一回一週間作業するほうが望ましい環境も
あるだろう。Debian の安定版リリースはこのような環境で最も有用だ。
* このような環境ではリリースがいつなのか前もってわかるのかが問題になる。
Debian をプリインストールした製品を出荷しようとするならなおさらだ。
* したがってリリースを早期に計画すること、そして計画どおりに
実行することがわれわれの作業内容のひとつだったし、これからも
そうだろう。
* 日常のパッケージ化作業について見ると、毎週あるいは毎日でも
システムをいじる意欲のあるユーザへのサポートも目標のひとつだ。
ここで機能と安定性とをはかりにかける必要がある。うまく動くと
われわれが自信を持てるソフトウェアか、可能なかぎり最新のものだが
動くかどうかは何とも言えないソフトウェアかを選べるようにしたい。
われわれはこの区別をテスト版 (testing) と不安定版とでつけようとした。
* これの主なまちがいはテスト版を可能な限り最新のものにしようとして、
不安定版の更新をあまりしてこなかったことだ。リリースされた
ソフトウェアを確信が持てるまでアップロードしなかったり、
CVS 版のパッケージをアップロードするのをためらったりしたわけだ。
これは悪い選択ではないが、この選択はユーザに任せるべきだ。
* 今回のリリースの第一の新要素のはリリース管理の分散だ。
これは階級支配制ではあるが、ともかく最初の一歩だ。 Joey Hess さん
<joeyh@debian.org>、Steve Langasek さん <vorlon@debian.org> そして
Colin Watson さん <cjwatson@debian.org> が Release Assistant に
任命された。
* experimental をより活用することにした。不安定版には最新の、
リリースに耐えるパッケージを、experimental には最新の開発中
バージョンのパッケージをアップロードしようというわけだ。
不安定版の foo-snapshot パッケージは名前から -snapshot を
除いたうえで experimental にアップロードすることになる。
不安定版のパッケージは Debian の安定版リリースに値する品質に
するべきだ。
* 不安定版もしくは experimental の一方にパッケージが収録されて
いる場合、他方にも自動的にアップロード可能となる。
* バグ追跡システム (BTS) に experimental タグが追加された。
* experimental へのアップロードで修正されたバグの報告は
クローズされるのではなく、fixed-in-experimental タグがつけられる。
* experimental は通常の buildd では自動構築されない。
* experimental を sources.list に追加しても、apt-get はそれを
自動選択しない。手動選択もしくは pinning が必要となる。
* その他については experimental は不安定版などと同様だ。
たとえば、.orig.tar.gz は変更できない。
* リリースクリティカル (RC) バグのリストにおいて、help、patch
あるいは pending タグがついているバグがカラー表示されるようになった。
* 目標達成のためにはこのリストのバグを毎週 50 から 100 件減らす
必要がある。一日あたり 10 から 20 件、開発者ひとりあたりなら
二週間ごとに 1 件の計算になる。
* バグ修正予約ページができた。
http://bugs.debian.org/cgi-bin/claims.cgi
これは master.debian.org の
master:/org/bugs.debian.org/bugsquash/claims/
中のユーザ名ファイルから生成される。作業の重複を避けるため、
バグを修正するときはここに項目を追加し、すでに予約がないか
調べるべきだ。以下のような URL も参考になるだろう。
http://bugs.debian.org/cgi-bin/claims.cgi?include=ajt@xxx
http://bugs.debian.org/cgi-bin/claims.cgi?exclude=pending,fixed
* この予約には強制力はない。作業の重複をいとわないなら、
予約ずみバグを修正してもかまわない。
* 8/23 (土) から 9/14 (日) までは非メンテナアップロード (NMU) に
ついて非常に寛大なポリシーを採用する。
- この期間の非メンテナアップロードは DELAYED ではなく
queue/unchecked (旧 Incoming) へ行える。
- すべてのパッケージの共同メンテナのつもりで作業するべきだ。
- これが sarge リリースに向けてバグを修正する最後の機会だ。
警告: 通常の非メンテナアップロードの伝統を守ること。
バージョン番号にはピリオドをつけ、修正しようとしている問題が
報告されているか確認し、バグ追跡システムにパッチを送り、
メンテナには報告し、同意が得られないならメンテナの意見を
尊重し、バグを発生させてしまったら自分のパッケージ以上に
すばやく修正し、すべからく高水準を保つこと。
この猶予 0 日の非メンテナアップロードについて話すときは、
上記の警告全文に言及し強調すること。われわれは官僚主義を
なくそうとしているのであって、品質を落とそうとしているのではない。
たちまち削除されてしまうような新機能を追加したりしないこと。
* 8/23 以降に標的になりそうなバグを修正するのはよいが、
非メンテナアップロードを過度にいやがらないこと。
* この非メンテナアップロードポリシーについての感想は 9/15 に
debian-devel へ投稿していただきたい。
* リリースクリティカルバグのあるパッケージはすべて削除の対象になる。
テスト版パッケージにリリースクリティカルバグがあればテスト版から
削除されるだろうし、不安定版パッケージにリリースクリティカルバグが
あり、積極的に作業している形跡がなければ、不安定版からの
削除もあり得る。これ以外の警告は行われない。
* テスト版への収録についての状況はここでわかる:
http://ftp-master.debian.org/testing/update_excuses.html.gz
* リリースクリティカルバグの定義は Debian ポリシーではなく、
以下になった:
http://people.debian.org/~ajt/sarge_rc_policy.txt
こちらが正式な定義である。
* リリースマネージャ用の sarge-ignore タグが導入された。
* 日程表:
8/19 (現在):
- 猶予 0 日の非メンテナアップロード (9/23 まで)
- sarge に大きな変更をもたらす開発中パッケージは experimental へ
- リリースクリティカルバグを 150 件減らして 700 件へ
(削除または修正によって)
- 勇敢なユーザによる debian-installer ベータテスト
(debian-boot を講読し、ここから入手:
http://people.debian.org/~tfheen/d-i/images/daily/)
- ネットワーク経由および sarge CD でのアップグレードベータテスト
(ここで入手可能、真の勇者限定:
http://gluck.debian.org/cdimage/)
9/1:
- 猶予 0 日の非メンテナアップロード
- toolchain パッケージの最終大変更
- リリースクリティカルバグを 200 件減らして 500 件へ
(削除または修正によって)
- debian-installer での sarge インストール方法を -devel-announce へ投稿
(志願者歓迎)
- sarge CD でのインストールを勇敢なユーザがベータテスト
9/15:
- リリースクリティカルバグを 150 件減らして 350 件へ
(詳しい説明、削除および修正によって)
- インストールべータテスト (debian-installer、tasksel、base-config、
パッケージインストール、CD イメージなどすべて)
- ドイツの Oldenburg にて debian-installer ハック大会
- 不安定版にアップロードされる主要パッケージの最後の大変更
10/1:
- リリースクリティカルバグを 150 件減らして 100 件へ
(削除、修正およびその場しのぎによって)
- 第 1 テストサイクル、感想公募
- インストーラの最終修正
10/15:
- リリースクリティカルバグを 100 件減らして 0 件へ
(修正、その場しのぎ、希望的観測および無視によって)
- バグ修正は最小限の無害なものに限る
- security.debian.org での sarge サポート
- 第 2 テストサイクル、感想公募
11/1:
- 残りのセキュリティバグにパッチ
- 第 3 テストサイクル (最終)、感想公募
- パッケージの更新はリリースマネージャによる個別許可が必要
11/15:
- 最終調整
- パッケージの更新はリリースマネージャによる個別許可が必要
12/1:
- リリース
* 作業はお早めに。テスト版入りにかかる 10 日間を忘れないように。
依存するパッケージが複雑でバグが発生しやすい場合 (glibc とか) も
余裕を持って。
--
大原雄馬 <oohara@xxxxxxxxxxxxxxxxxx>
Debian developer
PGP公開鍵 (鍵 ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt
Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695
enlightened self-interest
--- Nathanael Nerode、Debian に貢献する理由についての議論にて