Re: Quality Assurance in Debian (Debianの品質向上)

[Taketoshi Sano <xlj06203@nifty.ne.jp>]

佐野＠浜松です。

以下に引用するメールも debian-devel ML に流れたものです。
「みんなで協力してバグを潰していこう」という呼びかけですね。

  ====   ====   ====   ==== 以下引用   ====   ====   ====   ==== 

   From: rhertzog@hrnet.fr (Raphael Hertzog)
   Subject: Quality Assurance in Debian
   Date: 13 Sep 99 09:39:23 GMT
   X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/44374

 > [1  <text/plain; iso-8859-1 (8bit)>]
 > Hi,
 > 
 > I didn't want to announce this today but since Joey has brought up
 > a hot topic on -devel this morning, I feel that it's time
 > to make public what some people (me, Christian Kurz, Tortsten Landschoff,
 > Josip Rodin, Vincent Renardias and Martin "Joey" Schulze) have 
 > prepared for resurrecting debian-qa.

これを今日流すつもりは無かったのだが、Joey が今朝から熱い議論を
 -devel で始めたので、そろそろこれを公開してもいい頃かな、と思った。
これは有志 (私 (Raphael Hertzog)、Christian Kurz, Tortsten Landschoff,
Josip Rodin, Vincent Renardias and Martin "Joey" Schulze) が今 debian-qa の
再構築のために何を準備しているのかを示すものだ。

# そういえば例のビンセントさんも入ってますね。devel/maintainer_contacts に
# よれば彼は QA マネージャーだったらしい、、、そういや全然関係無いけど
# "iwj" って Ian Jackson のことですか ?

 > Please read the text attached (or the html version you can find here :
 > http://tux.u-strasbg.fr/~raphael/qa/doc/qa.html/). Any comments are
 > welcome.

とりあえず、添付した文章を読んでみてくれ。(html 版は以下の場所にある (略))
意見は大歓迎だ。

 > [ Please read below only once you read the text mentionned in the
 >   paragraph above ]

(以下の文章は、添付した文章に一度は目を通してから読むようにしてほしい)

# ということで、先に添付文書のほうへ行きます。

 > [2 qa.txt <text/plain; iso-8859-1 (8bit)>]
 > 
 >                         Quality Assurance in Debian
 >                         ---------------------------
 > 
 >                    Raphael Hertzog <hertzog@debian.org>
 > 
 >                     Christian Kurz <shorty@debian.org>
 > 
 >                                     0.2
 > 
 > 
 > -------------------------------------------------------------------------------
 > 
 > 
 > Abstract
 > --------

要約

 >      With the growing number of developers working on Debian (>500
 >      registered developers at the moment), the increasing number of
 >      packages (>3500 already) and the large number of bugs (about 10000)
 >      Quality Assurance (QA) is urgently needed. This document explains a
 >      proposed solution for Debian about the quality assurance issue.

Debian のために作業している開発者達の数が増えたこと (現時点で 500 名以上
の開発者が登録されている)、またパッケージの数 (既に 3500 以上) が増えて
バグの数も非常に多く (およそ 10000) なってきたことにより、品質向上 (QA) の
作業が緊急に必要とされている。この文書は品質向上のために Debian が取るべき道を
提案するために作成された。

 > Copyright Notice
 > ----------------

著作権表記 (ここはパス)

 >      Copyright 1999 by the Debian Project
 > 
 >      This text is free software; you can redistribute it and/or modify it
 >      under the terms of the GNU General Public License as published by the
 >      Free Software Foundation; either version 2 of the License, or (at your
 >      option) any later version.
 > 
 >      This is distributed in the hope that it will be useful, but WITHOUT
 >      ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 >      FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
 >      for more details.
 > 
 >      A copy of the GNU General Public License is available as
 >      /usr/share/common-licenses/GPL in the Debian GNU/Linux distribution.

 > -------------------------------------------------------------------------------
 > 
 > 
 > Contents
 > --------

目次 (ここもパス)

 >      1.        Why do we need Quality Assurance ?
 >      1.1.      Some facts
 >      1.2.      Goal of the proposed organization
 > 
 >      2.        Overview
 > 
 >      3.        The different entities
 >      3.1.      The QA committee
 >      3.2.      The QA core team
 >      3.3.      The QA members
 > 
 > 
 > -------------------------------------------------------------------------------
 > 
 > 
 > 1. Why do we need Quality Assurance ?
 > -------------------------------------

なぜ「品質向上」が必要なのか ?

 > 1.1. Some facts
 > ---------------

現状分析

 >         * The number of bugs is growing as is the number of packages.

バグの数はパッケージの数とともに増え続けている

 >         * Some packages have many bugs because the maintainer left Debian
 >           without orphaning his packages.

開発者がパッケージを orphan せずに Debian から離れてしまい、
多くのバグを集めながら、何も対処されずにそのままとなっている
パッケージもある。

 >         * Some maintainers can't manage all their packages and accept to
 >           live with buggy packages.

すべてのパッケージをきちんと管理することができずに、バグのあるパッケージと
一緒にやっていくことを受け入れてしまう開発者もいる。

 >         * Some bugs are sometimes too difficult to correct for the
 >           maintainer.

開発者にとって修正が実現不可能なくらい困難なバグも中にはある。

 >         * There's also period during which some maintainers can't work at
 >           all for Debian, but their packages may still need some attention.

開発者が Debian の作業をまったくできない期間というのもあるが、
彼らのパッケージを放っておくわけにはいかない。

 >         * In general, the quality of Debian can be improved in various way.
 >           There are still lots of packages not using all the suggested
 >           tools and integration utilities (menu files, doc-base files,
 >           alternatives, proper section/priorities, ...).

一般に、Debian の品質はさまざまな方法で向上可能である。
推奨されたツールや統合化されたユーティリティ (menu, doc-base, alternative,
適切なセクション、優先順位、、、) を未だに使っていないパッケージもある

 > 1.2. Goal of the proposed organization
 > --------------------------------------

この文書で提案する組織の目標

 >      Working on Quality Assurance is a big job, in fact it should not be
 >      the job of some volunteers only. Each Debian developer should take
 >      care of the quality of his packages. However this cannot be enforced
 >      by any rules because quality is sometimes a point of view. Therefore
 >      this document won't define strict rules for the packages (the Debian
 >      policy already dictates the rules) but a global organization so that
 >      every volunteer can help by doing things that will concretely improve
 >      the quality of Debian. One of the main point here is scalability, many
 >      people must be able to work together on quality assurance without
 >      interfering too much.

品質向上のための作業は大きな仕事だ。実際これは数人のボランティアだけに
まかせておくべき仕事じゃない。Debian 開発者はそれぞれ自分のパッケージの
品質に責任を持つべきだ。しかし、これはルールによって強化できるような
類いのものではない。なぜなら品質とはひとつの見方だからだ。このため、この
文書ではパッケージに対する厳密なルールを定義しようとはしていない。(ルールは
Debian policy によって既に決定されている) そうではなくて、この文書では
すべてのボランティアが参加して Debian の品質を具体的に改善できるような
全体的な組織を定義しようとしている。ここでの大きなポイントのひとつは、
拡張性 (スケーラビリティ) だ。多くの人々が互いに干渉し過ぎることなく
品質向上のために一緒に作業できなければならない。

 > -------------------------------------------------------------------------------
 > 
 > 2. Overview
 > -----------

全体像

 >      The work is coordinated on <debian-qa@lists.debian.org>, there's an
 >      official committee which is in charge of leading the volunteers that
 >      want to help with QA issues. There's also a QA core team (composed of
 >      regular QA workers) that can do NMU when the committee request it.

作業は debian-qa リストで調整される。QA 関連の作業に貢献したいと希望する
ボランティアをまとめていくための公式な委員会を置く。また委員会の要請に
応じて NMU を行なうことのできる QA コアチーム (常時 QA の作業ができるメンバーで
構成される) も発足する。

 >      The QA committe can lead people into different tasks :

QA 委員会は以下のようなさまざまな作業に人々を送り込む :

 >         * provide help/patches for particular bug reports (reducing the
 >           number of bugs in buggy packages).

特定のバグ報告について、対処方法やパッチを提供する
 (バグの多いパッケージからバグの数を減らす)

 >         * check if release critical bugs are corrected rapidly, if after 2
 >           weeks one is not corrected, they may contact the maintainer and
 >           ask him if he wants help or NMU ...

リリースクリティカルバグが即座に修正されたかどうかを調べる。
もし 2 週間過ぎても修正されていなければ、メンテナーに連絡を
取って援助が必要か、NMU を希望するかについて質問する。

 >         * help for mass update, maintain list of updated packages, send
 >           mail to the maintainers, allow NMU after X weeks without
 >           response.

大量の更新を支援する。更新されたパッケージのリストを保守する。
メンテナーへのメールを送る。x 週間経っても返事が無かった場合は NMU を
許可する。

 >         * check if all packages providing user programs (X11 or not) come
 >           with menu files.

ユーザープログラムを提供するすべてのプログラム (X11 上のものもそうでないものも)
に対して、メニューファイルが添付されているかどうか調べる。

 >         * check that all packages that provide documentation register it
 >           with doc-base.

文書を提供しているすべてのパッケージが doc-base 経由でそれを
登録しているかどうか調べる。

 >         * check if package are policy conforming (lintian is very useful
 >           for this).

パッケージがポリシーに従っているかどうか調べる
 (lintian はこの目的のために非常に有効なツールだ)

 >         * provide more documentation where it's lacking.

不足している部分により多くの文書を提供する

 >         * check if old packages (ie without recent upload) still work and
 >           if they are still maintained.

古いパッケージ (つまり最近更新されていないもの) がちゃんと動作するかどうか、
またきちんと保守されているかどうか調べる。

 >         * check if the informations provided by the packages are accurate
 >           (dependencies, sections, priorities, description, ...).

パッケージが提供する情報が正確かどうか調べる
 (依存関係、セクション、優先順位、説明、、、)

 >         * check if all the packages are linked against the proper libraries
 >           (so that old libraries may be dropped in favour of most recent
 >           ones).

すべてのパッケージが適切なライブラリにリンクされているかどうか
(つまり古いライブラリを最も新しいものと置き換えてしまうことが
できるかどうか) 調べる。

 >         * check that we have the latest upstream version.

最新の upstream version になっているかどうか調べる。

 >         * any other useful (QA related) job.

その他の有益な (QA 関連の) 作業

 > 
 > -------------------------------------------------------------------------------
 > 
 > 3. The different entities
 > -------------------------

それぞれの実際について

 > 3.1. The QA committee
 > ---------------------

QA 委員会

 >      It's composed of volunteers designated by the leader. Their members
 >      would manage a database of QA related tasks. They lead the QA core
 >      team and the QA members. They contact maintainers which could benefit
 >      from some help because they have buggy (or difficult) packages. They
 >      offer the assistance of the QA members. But when the QA group has
 >      provided help (via patches in the BTS in general), the maintainer has
 >      to upload corrected packages (considering of course that the patch are
 >      ok according to him) in a time frame of 3 weeks (or 1 week during a
 >      freeze). After this delay, the QA committee can ask the QA core team
 >      to NMU the package in order to integrate the patches and to correct
 >      all the bugs that can be corrected.

委員会はリーダーによって指名されたボランティアによって構成される。
委員会のメンバーは QA 関連作業のデータベースを管理する。
委員会は QA コアチームおよび QA メンバーを率いる。委員会はバグの多い
 (または扱いの難しい) パッケージに苦労していて、支援が必要だと思われる
開発者に連絡を取る。委員会は QA メンバーによる支援を提供する。
ただし QA グループが (通常 BTS にパッチを登録することにより) 支援を提供した
場合には、開発者は 3 週間以内 (フリーズ期間中は 1 週間以内) に修正済みの
パッケージを upload しなければならない。
(もちろん提供されたパッチが開発者によって効果を認められた場合) 
この猶予期間を過ぎると、QA 委員会は QA コアチームにそのパッケージに対して
 NMU を行ない、パッチを統合して修正可能なバグをすべて修正するよう要請できる
ものとする。

 >      If the maintainer doesn't respond to the mails from the QA committee
 >      in a delay of a month (considering that the maintainer did not
 >      announce that he's in vacation), the committee may first allow a NMU
 >      to be done to correct the bugs and may later (two months after the
 >      initial mail) orphan the package if he still hasn't responded.

開発者が (長期休暇に出ていることを宣言していない場合を考慮して) 1 ヶ月経っても
QA 委員会からのメールに反応しない場合は、委員会はまずバグを修正するために
 NMU することを許可し、その後 (最初のメールから 2 ヶ月経っても) 連絡が無い
場合は、そのパッケージが orphan されたものとして扱うことができるものとする。

 >      The QA committee is also in charge of the WNPP (Work Needed and
 >      Prospective Packages) list since they are already contacting
 >      maintainers about packages they might want to orphan.

QA 委員会はまた WNPP (作業の必要な、または期待されるパッケージ) リストに
ついても責任を持つものとする。これは開発者が orphan するつもりのパッケージに
ついて、委員会が開発者に連絡を取っているはずだからである。

 > 3.2. The QA core team
 > ---------------------

QA コアチーム

 >      It's composed of QA members designated by the QA committee, only
 >      people actively involved in QA for more than a month can become member
 >      of the QA core team. Beeing member of the QA core team doesn't give
 >      you many power, the reason of the existence of the QA core team is to
 >      know who can do NMU when the committee request it. However you can be
 >      proud to be part of it, because this does mean that you're doing a
 >      great work for Debian and his quality. If a member of the QA core team
 >      suddenly stops working for QA, he will be removed from the list.
 >      However he can rapidly integrate it again when he restarts working for
 >      QA.

QA 委員会によって指名された QA メンバーによって構成される。QA 関連の作業を
１ヶ月以上活発に行なったメンバーだけが QA コアチームに参加することができる。
QA コアチームのメンバーになっても、特別な力を与えられることはない。QA コア
チームの存在理由は委員会が要請した時に誰が NMU を実行できるか知っておくこと
である。しかし、このチームのメンバーであることは開発者にとっての誇りである。
なぜならこのことは Debian とその品質向上のために偉大な作業を行なっていると
いうことを意味するからだ。QA コアチームのメンバーが QA のための作業を突然
やめてしまった場合、彼はリストから外される。しかし彼が QA の作業を再開すれば、
早期に復帰することは可能である。

 > 3.3. The QA members
 > -------------------

QA メンバー

 >      Everybody who is subscribed to <debian-qa@lists.debian.org> is a QA
 >      member. The more QA members the better ... the task list will be
 >      posted to debian-qa by the committe once or twice a week, the QA
 >      member are encouraged to work on the problems submitted by the
 >      committee. A QA member who has worked a lot in this area can ask the
 >      committee to be added to the list of QA core team members.

 <debian-qa@lists.debian.org> ML の参加者は誰でも QA メンバーである。
# ということは official maintainer に限定されないってことか ?
 QA メンバーは多いほど良い。作業リストは委員会から週 1, 2 回 debian-qa に
投稿される予定である。QA メンバーは委員会によって提出された問題について
作業することを奨励される。この領域で多くの作業実績を残した QA メンバーは
 QA コアチームメンバーに加えてもらうことを委員会に申請できる。

 > -------------------------------------------------------------------------------
 > 
 > 
 >      Quality Assurance in Debian
 > 
 >      Raphael Hertzog <hertzog@debian.org>
 >      Christian Kurz <shorty@debian.org>
 > 
 >      0.2

 ====

(以上、添付文書)

 > I believe that the proposed organization (associated with the tools
 > developed aka 2 mailbots, a database and the website) can be the 
 > solution for :

私はここで提案している組織が ( 2 mailbots, データベース、および Web サイト
などのこのために開発された道具を使うことで) 以下の問題に対する解決策と
なり得ると信じている:

 > - following the Release Goals. If you wonder why I said that check out
 >   http://tux.u-strasbg.fr/~raphael/qa/big-tasks.html
 >   Each of the release-goal can be splitted in simple tasks. Everybody can
 >   follow what needs to be done on the web and can help.
 >   It's inspired from the Gnome Status Page.

リリースゴールに従うこと。もし何を言っているのかわからなければ、
http://tux.u-strasbg.fr/~raphael/qa/big-tasks.html を見てほしい。
それぞれのリリースゴールは単純な作業に分割できる。誰でも Web の情報を
見てしなければならないことを理解し、協力することができる。
これは Gnome Status Page からヒントを得た。

 > - correcting buggy packages [more explication below why it could work]

バグの多いパッケージの修正 (これについては後で説明する)

 > - finding "cruft" and maintainers that have vanished (this is the
 >   job of the QA committee)

"不要なもの" と姿を消した開発者とを見つけだす (これは QA 委員会の仕事)

 > Now some comments why this can work. Many people expressed their interest
 > to work for Debian's quality but they said it was difficult because :

これでうまくいくと考えた理由を説明しよう。多くの人々は Debian の品質向上の
ために貢献することに関心があるが、以下の理由で難しいと表明している:

 > - they don't know where to begin

どこから手をつけたらいいのかわからない

 > - they don't want to work too much (they'd like to grab a little task they
 >   can do in 2-3 hours and after that forgot QA since the following and so
 >   on)

あまりに負荷の高すぎる作業はやりたがらない (たいてい 2, 3 時間で済むような
ちょっとした作業を簡単にやっつけるほうを好んでいて、そしてその後は以下の
ような理由で QA のことを忘れてしまう)

 > - they don't want to continue writing patch if they are not used. Sometimes
 >   patches sent to the BTS are simply ignored (which does often mean that
 >   the maintainer vanished)

採用されないパッチを書き続けたいとは思わない。BTS に送られたパッチが
単に無視されているといった場合かいくつか存在する。(これはたいていの
場合、開発者が姿を消したことを意味している)

 > - they don't want to do NMU because they don't want to argue with
 >   the maintainer

開発者と議論したいとは思っていないため、NMU をしたがらない。

 > - even if they want to do a NMU, they must contact the maintainer
 >   and wait for his response. If the maintainer doesn't respond, they
 >   should wait 3 weeks (it's 3 times enough to forget about the
 >   NMU they wanted to do) ...

もし NMU をしようと考えたとしても、まず開発者に連絡を取ってその返事を
待たなければならない。もしも開発者からの返事がすぐに来なかったら、3 週間
待ち続けなければならない。 (これは NMU しようと思ったことを忘れてしまうのに
十分な時間の 3 倍くらいの長さだ)、、、

 > Now, let's listen how those problem are solved :

じゃあ、これらの問題をどうやって解決するか:

 > - they don't need to choose a package and a bug to correct, they simply
 >   work on what the committe has brought up to them

パッケージを選んだり修正するバグを選んだりする必要は無い。
単に委員会から提示された問題について作業するだけで良い。

 > - the committee has splitted the work in many little task so that everyone
 >   can help

委員会はひとつの作業を誰でもできるような多数の小さな作業に分割する。

 > - once someone has provided a patch for the task, it is marcked as "patch
 >   available". Those tasks are stored in a special list that the
 >   committe check from time to time. When a task is marked as patched for
 >   more than 3 weeks the committee can ask for an NMU in order to 
 >   integrate the work. Note that the person doing the NMU don't have to be
 >   the person who wrote the patch.

いったん誰かがある作業にパッチを提供したら、それは「パッチあり」と記録される。
これらの作業は委員会が定期的にチェックする特別なリストに保存される。
ある作業が「パッチあり」と記録されてから 3 週間以上経過した場合、
委員会はパッチを統合するために NMU を要請できる。NMU を実行するのは
パッチを提供したのと同一人物である必要は無いことに注意してほしい。

 > - people doing the NMU at the request of the QA committee don't have to
 >   fear the maintainer's reaction. They'll simply respond "I did it
 >   because the QA committee decided it, check with them if you have a
 >   problem".

QA 委員会からの要請に基づいて NMU を実行した場合、開発者からの反応を
怖れる必要は無い。単に「QA 委員会の決定に従って行なった。問題があれば
委員会に言ってくれ」と反応することができるだろう。

 > The main tool for debian-qa will be a new (dynamic) web site where
 > the tasks to do are listed. The tasks where a patch is available
 > are also listed separately. And last but not least you can find a list
 > of meta-tasks. The meta-tasks are big tasks composed of many little
 > tasks. This is a practical way to follow the release goals and other big
 > jobs like "Killing release critical bugs" and so on.

 debian-qa の主な道具は、新しい (動的な) Web サイトである。ここに必要な作業が
リストされる。パッチが提供されている作業もまたこのサイトに独立してリストされる。
大事なことを忘れていたが、ここには「メタ作業」のリストも掲示される。
「メタ作業」とは多数の小さな作業によって構成される大きな仕事である。
これはリリースゴールを守るための、また「リリースクリティカルバグを潰せ」など
のようなその他の重要な仕事のための、実際的な方法である。

 > The web site can be easily updated by sending mails to 2 mailbots. The
 > committee only can create new tasks but everybody can update the
 > information available for each task (setting the task as 'patch
 > available', closing it, setting the status field, ...).

Web サイトは 2 つの mailbot にメールを送ることで、簡単に更新可能である。
委員会は新しい作業を作り出すだけだが、誰でもそれぞれの作業についての
情報を更新できる (ある作業を「パッチあり」に記録したり、完了させたり、
状態フィールドに値を設定したり、、、)

 > What can I say more ?

何か他に言うことあったかな ?

 > I hope that we can agree on this proposal (i've already spent many hours to
 > write the tools) and that we can start to try this way of working.

私は、我々がこの提案に合意できることを希望している。
(私は既に道具を開発するために多くの時間を費しているんだ) 
またこのやりかたで作業を始めてみることができるように期待している。

 > Oh yes, for the QA committee: myself, Christian Kurz and Tortsten
 > Landschoff are volunteers to begin.

ああ、そうだ。QA 委員会は私自身と、Christian Kurz、それに Tortsten Landschoff を
最初のメンバーとして発足する。

 > BTW, do we need to vote the proposed text ?

ところで、この提案について投票する必要はあるかい ?

 > One of the main thing I want to do right at the beginning of our work is
 > contact all maintainers and ask them to reply (yes a ping message where
 > you have to reply to explicitely tell that you are still with Debian). They
 > will be also asked if they don't want to orphan some of their packages,
 > that they do no more use.

この作業を始めるにあたって、まずやりたいことのひとつは、すべての開発者に
連絡を取って、彼らに返事をするよう依頼したい、ってことだ。
(そうだ。ping メッセージだよ。君がまだ Debian と一緒にいるってことを
はっきりさせるために返事をしてくれなくちゃ)

それから、もう自分では使っていないパッケージを orphan するつもりがあるかどうか、
彼らに質問するつもりだ。

 > Maintainer that do not respond could be removed from the keyring later
 > (some months after another try). And the packages orphaned that nobody
 > wants to adopt could be removed (yes there are some unuseful packages,
 > like psptools).

返事をしない開発者は (数ヶ月後にもう一度試してみてから) 後でキーリングから
削除されるだろう。そして誰も後を継ごうとしない orphan されたパッケージは
削除されるだろう。(そうだ、 psptools のようにもう使い道の無いパッケージも
あるんだよ)

 > Cheers,
 > -- 
 > Raphael Hertzog -=- http://tux.u-strasbg.fr/~raphael/
 > <pub> CDs Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd </pub>

じゃあね。

  ====   ====   ====   ==== 以上引用   ====   ====   ====   ==== 

-- 
     ＃わたしのおうちは浜松市、「夜のお菓子」で有名さ。
    <xlj06203@nifty.ne.jp> : Taketoshi Sano (佐野　武俊)