Re: Comments on Debian Quality Assurance (long)

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

佐野＠浜松です。

 debian-qa から、もういっちょ。長いです。(つかれた、、、)

In article <11CD408013B6D2119BB50008C7EA510C0E07F9@eseis05nok>
 arto.astala@nokia.com さん writes:

> From: arto.astala@nokia.com
> Subject: RE: Comments on Debian Quality Assurance (long)
> To: teknofin@libero.it, vincent@waw.com, debian-qa@lists.debian.org
> Date: Fri, 12 Nov 1999 23:00:19 +0200

> Hi,
> 
> this is quite long, since there are so many related
> issues here. I try to touch on some, but not all are even
> mentioned.

やあ。

これはとっても長い文章だ。なぜならこれには非常に多くの事柄が関連しているから。
私はその中のいくつかについて触れようとしたが、ここにはまったく記載されていない
ような関連事項もまだまだたくさんある。

> What is quality in Debian?
> ==========================

「Debian における品質とは何か ?」

> When discussing quality of Debian three separate but
> interconnected issues should be addressed:

Debian において品質を議論する際、3 つの別個な、それでいてお互いに
結びついた問題に注意を向ける必要がある:

> A) quality of software in Debian (i.e. quality of software
>    that is being packaged for Debian).
> B) quality of packaging of that software (i.e. quality of
>    work that is being done when adapting the software to
>    Debian).
> C) quality of Debian system (i.e. selection of suitable
>    packages and defining how they should be configured to
>    make an integrated whole).

 A) Debian に含まれるソフトウェアの品質
     (Debian のためにパッケージ化されたソフトウェア自体の品質)

 B) そのソフトウェアのパッケージ化についての品質
     (そのソフトウェアを Debian に適合させるために行なわれた
      パッケージ化作業の品質)

 C) Debian システムの品質
     (適切なパッケージを選択することや、システム全体を統合させるために
      各パッケージをどう設定するべきかについて定義すること)

> Often these issues are confused, which makes discussion
> difficult at times.

これらの問題はしばしば混同され、そのたびに議論を難しくしている。

> How these issues are handled:

これらの問題をどのように取り扱うべきか:

> A) is easiest to define, since Debian is primarily a packaging
>    organization. Probably less than 5% of packages are Debian
>    specific. Quality of software is dependent on upstream
>    quality. Debian supports it by Bug Tracking System and by
>    forwarding any bugs, fixes and enhancements upstream.
> 
>    Some maintainers do more but that is not required. Also doing
>    more is conceptually difficult, since having a version that
>    is modified from upstream is considered forking by many.
>    Forking is considered inherently bad for free software.

 A) の定義はもっとも簡単である。なぜなら Debian は主として
パッケージングを行なう組織であるから。おそらく Debian 固有の
パッケージは全パッケージの 5% 以下 (訳者注: ホントか ?) である。
ソフトウェアの品質は上流 (upstream) の品質に依存する。
Debian は Bug Tracking System (バグ追跡システム) と、そのソフトウェア
に関するバグ報告、修正、機能強化などを上流に転送することによってこの
問題を支援している。

それ以上の作業を行なっている開発者 (メンテナー) もいるが、それは
必要条件ではない。また、上流ソフトウェアから変更されたバージョンを
提供することは、多くの人々から「分派活動 (フォーク)」と見なされるため、
より多くの作業を行なうことは、コンセプト上難しいことでもある。

分派活動 (Forking) はフリーソフトウェアにとって本質的に害をなすものと
考えられている。

# 訳者注: この最後の文にはちょっと異議あり。統合することだけが唯一絶対の
#  正義ではなく、多様化と競争によって達成されるものもあるはず。
# 
#  Debian local なものでは意味が無い、というのは Social Contract の
# 
#  「私たちはフリーソフトウェアコミュニティーにお返しをします
#     私たちが Debian システムの構成要素として新しいソフトウェアを
#     作成したときは、それをフリーソフトウェアとしてライセンスします。
#     私たちはフリーソフトウェアが広く配布されそして使われるよう、可能な限り
#     最高のシステムを開発していきます。また私たちのシステムに含まれている
#     ソフトウェアを私たちの「上流」で開発している作者に、バグ修正、
#     改良、ユーザの要求などをフィードバックします。」
# 
#  からある程度納得できる面もあるが、「上流」で互いに別の方向へ進化を
#  続けるために fork したソフトウェアについて Debian が統合を迫るのは
#  その使命を逸脱しているのではないかという疑いがある。
# 
#  もちろんユーザーから見て、「似たような機能を持つちょっとずつ異なる
#  ソフトウェアが多数存在して、何かちょっと違うことをするたびにいつも
#  パッケージを入れ換えないといけない」ような状況は、けしてありがたい
#  ものであるはずがなく、「すべての機能を取り込んだ、統合されたソフト
#  ウェア」への進化を「ユーザーからの要望」として上流に伝えることは
#  Debian の使命に沿った活動と考えられる。
#
# いずれにしろ、上流開発者と協調して、オリジナルに取り込まれるような形で
# ソフトウェア自身の品質向上について作業することはまったく問題無いはず。

> B) is mainly handled by Debian Policy document and policy
>    conformance checking tool Lintian. Policy is mainly discussed
>    on list 'debian-policy'. The other main document is the
>    Debian Developer's Reference. There are some other documents
>    available in Developers Corner. There are also several tools
>    to partially automate package creation and maintenance. These
>    are designed to eliminate some of the most common errors.

 B) は主に Debian ポリシー文書およびポリシー適合度チェックツール Lintian に
よって対処されている。ポリシーは主に 'debian-policy' メーリングリストで
議論されている。
もうひとつの主な文書は Debian デベロッパーズリファレンスである。
これらの他にも、開発者のコーナー (http://www.(jp.)debian.org/devel/) から
いくつかの文書を読むことができる。またパッケージの作成と保守を部分的に
自動化するためのツールがいくつか存在している。これらのツールは大部分の
パッケージに共通する間違いを取り除くために開発されている。

> C) is also handled by Policy and various subpolicies (e.g. Perl
>    policy for Perl packages, emacsen policy, etc.)

 C) もまたポリシーおよびさまざまなサブポリシー (例: Perl 関連パッケージの
ための Perl ポリシーや、emacsen ポリシーなど) によって対処されている。

> Technical issues related to all of A) to C) are often brought
> up on all mailing lists and discussed in depth, often with great
> expertise.

 A) から C) の全てに関連する技術的な問題がしばしばすべてのメーリング
リストで定義され、詳細に、また多くの場合専門的知識を背景に議論されて
いる。

> Quality assurance in voluntary organization
> ===========================================

「ボランティアによって構成される組織における品質保証」

> Modern quality thinking seems to place much emphasis on planned
> quality and then verifying that planned quality has been achieved.
> This is a difficult one for a large voluntary project like Debian.
> Here decisions are made mostly by discussion and consensus, not as
> managerial decisions. Also there is no practical way to control
> the work of an individual as it is being done. By necessity all
> controls are either before the work or after the work. Also the
> pre-work controls are weak by nature, there is no way of preventing
> anybody doing any work (in any way they want to do it), the only
> real control is when incorporating that into Debian. On the other
> hand, even weak controls are very effective on the long run,
> since the main rewards are peer recognition, which cannot be
> achieved with poor quality work, and work satisfaction, ditto.

現代的な品質についての考えは、要求品質レベルの計画に重点が置かれ、
次にその計画どおりの品質を達成できたかどうかの検証が重視される
ようである。これは Debian のような大規模なボランティアベースの
プロジェクトでは困難な課題である。ここでは主に議論と合意によって
決定が下され、特定の管理者によって決断が下されるということはない。
また、個々の作業を、その進行中にコントロールする現実的な手段は
存在しない。すべてのコントロールは必要に応じて作業の前あるいは
後に行なわれる。また作業前のコントロールは必然的に弱いものとなる。
なぜなら誰かが何かについて (自らが望む方向に) 作業しようとした時、
それを防止する方法は存在しないからだ。唯一の現実的なコントロールは
その作業結果を Debian に受け入れる際にのみ取りうる。
一方、弱いコントロールであっても長期的に見れば非常に効果的となりうる。
なぜなら (ボランティアである開発者にとって) 主な報奨は仲間達から
認められることや、自分の作業についての達成感であり、これは品質の低い
作業をしていては得られないものであるからだ。

> This means that one of the most important issues is induction of
> new developers. This has recently been improved, but could still
> be better. There is also the list 'debian-mentors' for asking any
> packaging related question or requesting private tutoring on
> packaging. Other important issue is keeping maintainers active
> for long time. This has been recognized but no solution has been
> found yet.

これは、最も重要な問題のひとつに、新しい開発者達の誘導があることを
意味している。これは最近改善されているが、また充分ではない。
なおパッケージ化作業に関して自由に質問したり、個人的に教わったり
できる場所として 'debian-mentors' メーリングリストも存在している。
もうひとつの重要な問題は開発者を長期間アクティブに維持することである。
これは問題として認識されてはいるが、まだ解決策は見つかっていない。

> There are almost no enforced reviews or strictly enforced check
> points, but there is a very strong culture of peer reviews. Even
> though change management and configuration control are rather
> informal I still consider the achieved result to be at least as
> good as in many commercial organizations. This is mainly due to
> very strong commitment to quality in Debian and community effort
> in doing the work.

現在、パッケージに関してレビューの強制や、厳密なチェックの強制は
存在しないが、非常に強いピアレビュー (開発者間の相互批評) の文化が
存在する。変化の管理や構成のコントロールが例え非公式なものであったと
しても、それによって達成されている結果はすくなくとも多くの商業組織と
同じ程度には良いと私は考える。これは主に Debian において品質が非常に
重視されていることと、コミュニティによる作業努力の結果である。

# 訳者注: 2 番目の文の前半は意味不明。

> There has been several times discussion on 'debian-test' list about
> testing framework and requiring developers to supply some
> regression tests or at least list of functionality to test, but
> this has not yet led to any concrete requirements for developers.
> There is an open policy proposal, however.

メーリングリスト 'debian-test' では、テストについての枠組と、
開発者に回帰試験 (RT) または少なくともテストするための機能の
リストを提供するよう要求することについて、何度か議論が行なわれたが、
これはまだ開発者に対する具体的な要求に結びついていない。
しかしながら、ポリシーについての公開提案は存在する。

> Defined processes for quality
> =============================

品質に対して定義された手順

> Debian tries to be *very anti-bureaucratic*, but some processes
> have been defined. Most important for quality are probably these:

Debian はできる限り「反・官僚的」たろうとしているが、いくつかの
手順については既に定義されたものが存在する。品質にとって最も
重要なものは、おそらく以下のものである:

> - accepting and purging maintainers
>    these try to ensure commitment to free software, not any
>    skill set or experience level, motivation is considered
>    proven by application to voluntary organization

* 開発者の受け入れと追放

    これらはフリーソフトウェアへの誓約を保証しようとするためのものであり、
    開発スキルや経験のレベルを保証しようとするためのものではない。
    やる気はボランティアベースの組織へ参加を申し込むことによって証明された
    ものと見なされる。

> - adopting and orphaning packages
>    if there are more than one applicant then previous
>    maintainer or other respected person selects; if maintainer
>    cannot maintain the package he eventually orphans package

* パッケージの採用と削除 (オーファン)

     複数の志願者がいた場合、前メンテナーまたはしかるべき人物が
     選定する。メンテナーがパッケージを保守できなければ、その
     パッケージを削除 (オーファン) することになる。

> - non-maintainer uploads
>    for critical bugs or packages that are not maintained

* ノン・メンテナー・アップロード

     致命的なバグの修正や、保守されていないパッケージのために実行される

> - uploading packages
>    includes authentication, quality control and bug handling

* パッケージのアップロード

     認証、品質管理、バグの対処などを含む。

> - making releases and point releases of Debian distribution
>    stable release, freeze, release critical issues,
>    distribution testing

* Debian ディストリビューションのリリースおよびポイントリリースの作成

     安定版リリース、フリーズ、リリースクリティカル問題、
     ディストリビューションテスト

> - bug handling
>    recommended response times, proper bug closing

* バグへの対処

     推奨される反応時間、適切なバグのクローズ

> - resolving technical disputes
>    discussion on relevant list, if no consensus then resolution by
>    technical committee or by general vote

* 技術的な議論の解決

    関連するリストでの議論、もし合意が得られない場合には
    技術委員会または全体投票による解決


> Other resources
> ===============

「その他の資源」

> There is no single list or web site for QA (in the modern sense)
> but here are some of the most relevant ones:
> 
> Debian QA group:
>  mailing list 'debian-qa'
>  web sites:
>   http://qa.debian.org/
>   http://tux.u-strasbg.fr/~raphael/debian/qa.html
> Debian Test group
>  list 'debian-testing' in the 'Other' section of the mailing
>   lists page.
> Debian Policy group
>  list 'debian-policy'
>  proposals are tracked in Bug Tracking System

    (現代的な意味での) QA のための単独のリストや Web サイトは
    存在しないが、最も関連の深いものを以下に挙げる:

    Debian QA グループ:
    メーリングリスト 'debian-qa'
    ウェブサイト:
     http://qa.debian.org/
     http://tux.u-strasbg.fr/~raphael/debian/qa.html
    Debian Test グループ
     メーリングリスト 'debian-testing' はメーリングリストページの
     'Other' セクションにある
   Debian Policy group
    メーリングリスト 'debian-policy'
    提案はバグ追跡システムに登録済である

(訳者注: 以下は省略)

> Closing comments
> ================
> 
> Perhaps you would briefly summarize the difference in QA and QC.
> There are different wievs on that, and it would be nice to know
> your standpoint.
> 
> Please note, that almost all of the activities (check ...) are
> actually guidelines for selecting where the improvement work
> should be directed, not what I'd call pure quality control.
> 
> As you have noticed, there is no QA reference model, but if
> somebody (you?) is willing to take the initiative he will
> certainly receive support from many smart, motivated and
> knowledgeable persons.
> 
> There is no (and probably cannot be any) design control at package
> level, but there has been quite a lot of effort at distribution
> level. Mostly that is codified in Policy and Developers Reference.
> 
> Even if the title Quality Assurance is not totally accurate it
> probably should be preserved for historical reasons. Also
> activities can always be extended in the right direction, if
> volunteers are available.
> 
> 
> 
> Disclaimer:
>  I have been hanging around and reading many
>  lists since '95, but I'm not a developer, so treat this as
>  an informed opinion but without any authority.
> 
> t.aa
> 
> Giovanni Biscuolo <teknofin@libero.it> Wed Nov 10, 1999 3:22 PM
> > 
> > I'm reading your page (http://www.debian.org/distrib/) about
> > QA in Debian and was very
> > excited reading the title Quality Assurance for I am an
> > enthusiast of Quality culture. I think it's a great thing
> > for GNU Software.
> > 
> > Anyway, I would like to point out that all the activities you
> > mention there (check ...) are about Quality Control, not
> > Assurance. It's not my intention to teach you the difference
> > - I have nothing to teach - but the difference is big.
> > I'm very interested, for example, to know your QA reference
> > model (ISO 9001 i.e.), how do you plan design control and,
> > why not, if you are going  to develop
> > and publish a GNU/Debian QA Manual.
> > I think your WWW page should specify deeper the activities 
> > and documents about Quality Assurance
> > or you should change the title to "Quality Control".
> > 
> > Last but not least: is there a mailing list about this topic?


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