[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:09027] QA check (Re: [Wnn] libjd.a)
むつみです。
Mitsuru Oka <95i44@xxxxxxxxxxxxxxxx> さんは
Subject: [debian-users:09024] Re: [Wnn] libjd.a
Message-ID: <19981014154924Q.oka@xxxxxxxxxxxxxx>
において言いました
>> 岡＠情報科学.高知大です。
>> 石川> QA って、ぜんぜん定期的じゃないです(むしろ、バースト的に作業が発生し
>> 石川> ます)。
>>
>> 石川> freeze してから、作業をはじめて、stable に移行するまで(リリースまで)
>> 石川> の時期しか作業しませんから(って、常時やってれば、あんなに作業量が爆発
>> 石川> しないんじゃない?って話もあるんだけど ^^;;)
>>
>> この作業、もう少し詳細まで知りたいです。ソースパッケージから
>> バイナリパッケージ作成、インストール、可能ならテスト運用まで
>> のチェックを全てのパッケージについて行っていくんですよね?
>>
>> で、問題があれば BTS に投げればいいと。
とりあえず、そうです。が、現状、組織だったり形式だってやってるわけじゃ
なくて、決まった手順というものも存在していません(QA チームの構成員も
流動的というか、ちゃんと組織されているわけじゃなくて、private 内でリリー
ス前に手が空いている人間が手分けしてやってるって感じ)
で、QA 作業に関しては、install/uninstall と build のテストがメインだ
と思うんですが、それ以外、つまり freeze 前後に行った、その他の作業まで
含め説明しておきます。
＃一応、流れ的には http://www.debian.or.jp/devel/roadmap-jp.html
＃をみてください
今からの話は、Hamm-JP リリース前はどうだったかという点です。(た
だし、家に帰らないと、その時のやり取りが確認できないんで、記憶にのみ頼っ
て書いてます。間違ってる部分は、指摘お願いします ＞メンテナのみなさん)。
まず、実際の作業ですが、以下に分類できると思います。
1) libc5 依存パッケージ洗いだし
2) lintian チェック
3) copyright チェック
ここまでが、freeze 前、以降 freeze 後
4) build チェック
5) install/uninstal チェック
狭義の QA といってるのは、この 4) 5) の部分です。
まず、1) ですが、Hamm-JP のリリースでは、libc6 への以降が必須条件だっ
たため、Bo-JP から引き続き残っていた libc5 に依存するパッケージを洗い
出しました。このリストに乗っているものに関しては、freeze の期日までに
libc6 版を用意しない/できない場合は orphand 行きという扱いになりました。
今回の slink(slink-jp) のリリースでは、必要ない作業です。
で、2) ですが、すべてのパッケージに対して lintian をかけました。
多分、lintian を使うのは、パッケージメンテナぐらいだと思うんで ^^;;
その存在すら知られてないと思いますが、C に対する lint のように deb パッ
ケージに対して lintian をかけると、パッケージングに関する問題点を
洗い出してくれます。
で、その結果をメンテナ毎にリストにして、改善を促すと。ただし、今回の
リリースでは、この修正に関しては努力目標ということで、全部改善しなけれ
ばならないというような強制はしませんでした。
続いて、3) に関しては、各メンテナが自分の担当パッケージのライセンスを
報告してもらって、それをまとめていき、main, contrib, non-free のどこに
入れるかということを確認しました。DFSG 準拠が明確にならないものに関し
ては、upstream のメンテナに問い合わせなども行っています。DFSG に準拠し
ないものは non-free に移動しました(が、Wnn6 の問題に鵜飼さんが気付い
て、全員焦ったのは、この作業のずーっと後、だったんですけど ^^;;)
ここまでが、freeze までの作業。で、freeze 後の作業。
QA テストの部分です。
4) は ソースを展開して、build して deb パッケージが作成できるかという
ことをチェックします(今回は、結局、わたし一人でほとんどやりました。
この作業は、ディレクトリを指定すると、そのディレクトリにあるソースを順
番に展開、build していくスクリプトがあるんで、自動化できます、いや、自
動化できるはずでした ^^;;
確かに、そのスクリプトを使うと順に展開して build していってくれるし、
どうなったかというログも残してくれ、さらに、失敗したか成功したかをファ
イルに記録していってくれるんですが、実は失敗していても成功だと判定する
というバグが存在することが、作業中にわかりました。で、スクリプトを直し
てる時間もなかったんで、結局、失敗してるかどうかをログをみて判断しなけ
ればならないということになってしまいました。
＃そういえば、このバグ原因究明して直しとかないと、また苦しむのか ^^;;
で、build できなかったものに関しては、その log (と、私がみた、何が問
題かという解析コメント、さらに余裕がある場合、それを改善するパッチ)を
BTS に順次登録していきます。これが改善されないものは、Hamm-JP からはず
されることになります。
この作業に関しては、
1) ソースを全部手元に持ってきても苦にならないような(ある程度充分な帯
域を持った)ネットワーク(最低、ISDN じゃないときついと思う、アナ
ログではちょっと無理)。
2) Debian-JP のソースを展開して、build して、出来上がったものを全部保
存していっても、大丈夫な DISK 領域(2GB ぐらいの空き領域があればいい)
3) 可能な限りの開発環境(lib*-dev など)をインストールしてある環境
があった方がいいです。じゃないと、恐ろしく作業が困難になります。逆に、
全部用意できるのであれば、一人でできちゃうと思います。
＃特に、今回は Hamm-JP から引き継いでるものが多いんで、build
＃に失敗するようなパッケージは少ないと思うし。
5) は install/uninstall テストです。個人的には、この作業が一番大変と
いうか気を使うんじゃないかと思います。というのは、ちゃんと install で
きないパッケージとか uninstall できないパッケージがあると(最悪)そのテ
ストを行っていた環境が使い物にならなくなる可能性をもってるからです(ま
あ、そこまでひどいバグを持ったパッケージが freeze 時に残ってることはな
いでしょうが)。
今回どのように行ったのか知りませんが、私がやるなら、一台つぶれてもい
いマシンを用意して、順次 install/uninstall を繰り返すという方法をとる
と思います。
と、こんな感じなんですが、いかがでしょう?
--
From Nagoya
ishikawa@xxxxxxxxxxx, ishikawa@debian.or.jp
＊＊ 石川 睦％無意味な全文引用をする人は嫌い＠Japan Linux Users Group ＊＊
(Nagoya Linux Users Group)
My Debian-JP NEWS http://www.linux.or.jp/~ishikawa/linux/debian-jp/
X-TT 1.0 [Aoi MATSUBARA] http://www.linux.or.jp/~ishikawa/linux/X-TT/