Product SiteDocumentation Site

1.3. Debian プロジェクトの内部の仕組み

Debian プロジェクトの優れた最終結果は、Debian 開発経験者によるインフラ整備作業と Debian パッケージの個々またはグループ開発者の作業の集約、そしてユーザからのフィードバックの同時進行により成り立っています。

1.3.1. Debian 開発者

Debian 開発者には公式プロジェクトメンバーとしてのさまざまな責任があります。彼らはプロジェクトの方針に重大な影響を与えます。一般に Debian 開発者は最低一つのパッケージに対して責任がありますが、時間がありそうしたいと思えば、多数のチームに参加することでプロジェクト内でより重い責任を負うことも自由にできます。
パッケージ管理は比較的厳格に管理された活動で、よく文書化されており、もっと言えばルールが決められています。事実上、パッケージ管理に関連するルールは Debian ポリシーの定めるすべての基準と適合します。幸いなことに、パッケージ管理の仕事を手助けする多くのツールが存在します。それゆえ、開発者は担当パッケージに固有の作業やたとえばバグ修正などのより複雑な作業に集中することが可能です。
Debian プロジェクトの重要な要素である Debian ポリシーはパッケージの品質とディストリビューションの完全な相互運用性の両方を確保するための規範を定めています。このポリシーのおかげで、Debian は巨大にも関わらずその一貫性を保っています。このポリシーは決定事項ではありません、 メーリングリストに寄せられた提案を練ることで絶え間なく進化しています。関係者全員からの同意を得た修正は承認され、編集責任を持たないメンテナの小集団がこれを文章に反映します (上に挙げたメーリングリストのメンバーである Debian 開発者ができるのは、同意された修正を盛り込むことだけです)。現在寄せられている修正の提案を読むにはバグ追跡システムをご確認ください。
Debian ポリシーはパッケージ化の技術的側面の大部分をカバーしています。Debian プロジェクトの大きさは組織の問題を引き起こします。それに対して、問題は Debian 憲章に即して対処されます。Debian 憲章は組織体制と意思決定の手段を定めています。これは言い換えれば、組織的な管理システムと言えます。
Debian 憲章は一定の役割と役職、併せてそれぞれに対する責任と権限を定義しています。特筆すべきは Debian 開発者は一般決議に投票することで最終決定を行う権限を常に持っているということです、重大な変化 (基本文書に影響を与えるようなもの) を起こすには特定多数の 4 分の 3 (75%) が投票すること必要です。しかしながら、開発者は会議で彼らを代表して、さまざまなチーム間の連携を確保する「リーダー」を毎年選びます。この選挙は常に活発な議論になります。リーダーの役割は何かの文書で正式に定義されているわけではありません。なぜなら通常、この役職の候補者は役割を自分自身で定義し、それを提案するからです。実際のところ、リーダーの役割には開発者からの共感を得るように、メディアに対する代表者として働くこと、「内部」チーム間の連携をとること、プロジェクトに対する包括的な指導を提供すること、が含まれています。そして、DPL の見解は大多数のプロジェクトメンバーから暗黙のうちに容認されています。
具体的に言えば、リーダーは本当の意味での権力を持っています。さらに、賛否同数の場合にはリーダーの投票が決定票となります。その上、リーダーはまだ誰の権限下にもなっていない案件に判決を下したり、自身の権限の一部を委任したりすることが可能です。
Debian が始まって以来ずっと、プロジェクトは Ian Murdock さん、Bruce Perens さん、Ian Jackson さん、Wichert Akkerman さん、Ben Collins さん、Bdale Garbee さん、Martin Michlmayr さん、Branden Robinson さん、Anthony Towns さん、Sam Hocevar さん、Steve McIntyre さん、Stefano Zacchiroli さん、Lucas Nussbaum さんに率いられてきました。
Debian 憲章では「技術委員会」もまた定義されています。技術委員会の本質的な役割とは、関係する開発者の間で合意に達しなかった場合に技術的な事柄を決定することです。技術委員会の他の役割として、責任を負っている決定で間違いを犯す開発者に対する顧問役があります。ただし、技術委員会は問題になっているグループの一員から参加するように求められた場合のみそこに参加するということに注意しなければいけません。
最後に、Debian 憲章では「プロジェクト秘書」の役職も定義しています、この役職はさまざまな選挙と一般決議に関連する投票の運営に責任を負っています。
「一般決議」手続きは Debian 憲章の中で最初の議論期間から最後の開票まで詳細に説明されています。より詳しい情報は以下のページを参照してください。
たとえ Debian 憲章の規定する民主制が名ばかりのようなものであったとしても、毎日の現実は全く違ったものです。なぜなら Debian は当然ながらフリーソフトウェアにおける能動主義 (do-ocracy) のルールに従い、物事はそれを行った者がどのように行うかを決めるからです。問題に対処するさまざまな方法のそれぞれの価値について議論することで、多くの時間が無駄にならないとも限りません。しかしながら、選ばれし解決策は機能性と要件満足度を両立する初めての解決策になるでしょう… このような解決策は、有能な人物が努力しなければ、導き出されるものではありません。
地位にふさわしい業績を上げるにはたった一つの方法しかありません。すなわち、何か有益なことをして、それがうまくいったことを示すことです。多くの Debian「管理」チームは実績を上げていない者を採用しません、つまり、これまでの貢献が効果を挙げており、本人の能力が証明されているボランティアを好むということです。これらのチームの仕事は公開されており、新しい貢献者がその仕事を観察し手助けを開始するのに特権を必要としません。そのため、Debian は「業績主義」と言われています。
この効果的な運営方法のおかげで「重要な」Debian チーム内では貢献者の品質が保証されています。この方法は決して完璧ではありませんし、時々この運営方法を受け入れられない人もいます。チーム内で採用されている開発者の選択基準は少し気まぐれかもっと言えば不公平なものに見えるかもしれません。その上、チームから受けられるサービスに関して全員が同じ定義を共有しているとも限りません。新しい Debian パッケージを含めるのに 8 日間待たなければいけないのは受け入れがたい人もいれば、なんの問題もなく 3 週間気長に待つ人もいます。そんなわけで、いくつかのチームからは「サービス品質」の不満に関する苦情が常に寄せられています。

1.3.2. ユーザの積極的役割

Debian プロジェクト内で働く人の中でもユーザに言及する必要があるのではないかと思うかもしれません、その答えは間違いなく yes です。なぜなら、ユーザは重要な役割を果たしているからです。「受け身」の状態から一歩進んで、Debian の開発版を使い、問題を説明するバグ報告を出すユーザもいます。さらに深く立ち入り、重要度「wishlist」のバグ報告を出すことで改善案を投稿したり、「patches」でソースコードの修正を投稿するユーザもいます (補注BACK TO BASICS パッチ、修正を送る方法」をご覧ください)。
加えて、Debian の提供するサービスに満足している数多くのユーザが彼ら自身の手でプロジェクトに貢献をしたいと思っています。プログラミングに関する専門知識のレベルが十分でない人は翻訳や文書のレビューを行うことで手助けを行うことを選ぶかもしれません。このような仕事を行うために各言語に特有の問題を議論するためのメーリングリストがあります。
ユーザの行動によって、上で述べたすべての貢献の仕組みはさらに効果的なものになります。孤立したユーザの集合体から一歩進んで、ユーザ間の交流が数多くの起こるコミュニティこそが本物のコミュニティなのです。ユーザが議論するメーリングリスト で行われる素晴らしい活動について触れておきます (第 7 章「問題の解決と関連情報の探索ではこの件に関する詳細な議論がなされています)。
ユーザ同士が本人に直接影響のある技術的な問題について互いに助け合う (または誰かが助ける) だけでなく、ユーザが Debian プロジェクトに貢献するための最良の方法を話し合い、プロジェクトが前進するための手助け — 高い頻度で改良が提案されるような議論を行います。
Debian は自己アピールによる普及キャンペーンに資金を使わないため、Debian のユーザは Debian の普及に重要な役割を果たし、Debian の評判は口コミで伝わることが保障されています。
この方法は極めてうまくいきます、なぜならフリーソフトウェアコミュニティのあらゆる層に Debian の支持者がいるからです。すなわち、地域の LUG「Linux ユーザグループ」が企画したインストールパーティ (ベテランユーザが新しいユーザにシステムのインストールの補助を行うワークショップ) から、Linux などについて取り扱う大きな技術会議のアソシエーションブースにも浸透しています。
ボランティアがポスター、パンフレット、ステッカーなどのプロジェクトの宣伝に役立つ資料を作り、彼らは宣伝資料を誰でも利用できるようにしており、Debian はウェブサイトで宣伝資料を無制限に提供しています。

1.3.3. チームとサブプロジェクト

Debian は最初からずっと、ソースパッケージの概念を中心に組織化され続けており、ソースパッケージにはそのメンテナとメンテナのグループがいます。チームが担当している仕事の多くは長い時間をかけて明らかにされてきました、確実にインフラを運営すること、特定のパッケージに依存しないタスク (品質保証、Debian ポリシー、インストーラなど) を管理すること、そして最近サブプロジェクトの周りで成長している数多くのチームと一緒にそれを行うことです。

1.3.3.1. 存在する Debian サブプロジェクト

人それぞれ好みの Debian があります! サブプロジェクトは Debian を特定のニーズに適応することに興味のあるボランティアのグループです。特定の領域 (教育、医療、マルチメディア制作など) を対象としたプログラム群の選定だけでなく、サブプロジェクトはまた、既存パッケージの改良、不足ソフトウェアのパッケージ化、インストーラの適応作業、特定文書の作成、などに従事しています。
以下は現在のサブプロジェクトを一部抜粋したものです。
  • Debian-Junior、Ben Armstrong さんが作成し、子供向けに魅力的で使いやすい Debian システムを提供しています。
  • Debian-Edu、Petter Reinholdtsen さんが作成し、学問の世界向けに特化したディストリビューションの作成を重視しています。
  • Debian Med、Andreas Tille さんが作成し、医療分野に特化しています。
  • Debian Multimedia、音声およびマルチメディア制作を取り扱います。
  • Debian-Desktop、デスクトップを重視しデフォルトテーマのアートワークを統合しています。
  • Debian GIS、地理情報システムのアプリケーションとユーザを引き受けています。
  • 最後に Debian Accessibility、障がいのある人々の要求に合致するよう Debian を改良しています。
このリストは時間が経過するに従って増え続け、Debian サブプロジェクトの良さに対する認識を改良し続けることは間違いありません。既存の Debian のインフラがサブプロジェクトを完全にサポートしているので、実質的に、サブプロジェクトは真の付加価値を上げるための仕事に集中しています。サブプロジェクトは Debian プロジェクト内で開発しているため Debian との同期について心配することはありません。

1.3.3.2. 管理チーム

ほとんどの管理チームは比較的閉鎖的で新メンバーの採用は現メンバーからの選出で決まります。チームの一員になる最良の手段は現在のメンバーを賢明に手伝うこと、つまり自分がチームの目標と流儀を理解していることをはっきり示すことです。
ftp 管理者は Debian パッケージの公式アーカイブの責任者です。管理者はあるプログラムのメンテナンスを担当しており、このプログラムは開発者が送信したパッケージを受け取り、何点か確認した後にパッケージを自動的に参照基準サーバ (ftp-master.debian.org) に保存しています。
管理者はまた、パッケージデータベースの中に新しいパッケージを追加する前に、Debian がこのパッケージを配布しても問題ないことを確認するために、このパッケージのライセンスを確認します。開発者がパッケージの削除を希望する場合、開発者はバグ追跡システムから ftp.debian.org「擬似パッケージ」に対してバグ報告を行い、管理者と連絡を取ります。
Debian システム管理者 (DSA) チーム () は、あなたの予想通り、プロジェクトが利用する多くのサーバのシステム管理に対して責任があります。チームは、すべての基盤サービス (DNS、ウェブ、電子メール、シェルなど) を最適に機能させること、Debian 開発者から要求のあったソフトウェアをインストールすること、セキュリティ関連の予防策を適用すること、を保証します。
listmasters はメーリングリストを運営する電子メールサーバを管理します。彼らが新しいメーリングリストを作成し、宛先が不明なメールを処理 (配送失敗通知) し、スパムフィルタ (迷惑メールフィルタ) をメンテナンスします。
それぞれのサービスには自身の管理チームがあり、ほとんどの場合サービスを設置したボランティア (しばしばサービスで利用しているツールをプログラムしたボランティア) がチームのメンバーになっています。これに当てはまるケースとして、バグ追跡システム (BTS)、パッケージトラッカー、alioth.debian.org (FusionForge サーバ、補注TOOL FusionForge、共同開発における万能ナイフ」を参照してください)、qa.debian.org で利用できるサービス、lintian.debian.orgbuildd.debian.orgcdimage.debian.org などがあります。

1.3.3.3. 開発チーム、横断チーム

管理チームとは異なり、開発チームの門戸は外部の貢献者に向けてかなり大きく開かれています。Debian の使命がソフトウェアを作成することではないとしても、目標を達成するためにはプロジェクトは特定のプログラムを必要としています。もちろん、フリーソフトウェアライセンスの下で開発されたそれらのソフトウェアはフリーソフトウェア世界の他の場所で保証されている方法を活用します。
Debian は自分用に小さなソフトウェアを開発し続けてきましたが、一部のプログラムは重要な役割を担っており、そのようなプログラムの名声は Debian プロジェクトよりも大きく広がっています。Debian パッケージ管理プログラムの dpkg (実際のところ、これは Debian PacKaGe の 略称で、「dee-package」と発音されます) と、任意の Debian パッケージとそのパッケージが依存しているパッケージを、更新後のシステムの継続性を保障しながら、自動的にインストールする apt (名前は Advanced Package Tool の頭字語) がそのよい例です。一方で、これらのプログラムの働きを全面的に理解するには極めて高いプログラミング能力が必要であるため、チームの規模は極めて小さなものです。
Debian インストールプログラム debian-installer の開発チームは最も重要なチームです。2001 年の構想以来ずっと、開発チームは極めて重要度の高い仕事を達成し続けています。たくさんの異なるアーキテクチャに Debian をインストールできるたった 1 つのプログラムを書くのは難しいため、数多くの貢献者が必要でした。それぞれのアーキテクチャではそれぞれ異なる起動メカニズムと異なるブートローダを使っています。この仕事のすべては Cyril Brulebois さんの指揮の下 メーリングリストで組織的に行われています。
debian-cd プログラム (とても小さい) のチームはさらにいっそう控えめな目的を持っています。数多くの「小」貢献者は彼らのアーキテクチャに対して責任を負います、なぜなら主開発者はすべての細かな差異や CD-ROM からインストーラを起動する正確な方法を知ることはできないからです。
多くのチームは他のチームと一緒にパッケージ化を行わなければいけません。たとえば は Debian プロジェクトのあらゆるレベルで品質を保証しようと試みます。 メーリングリストはあちこちからの提案に従って Debian ポリシーを成長させます。アーキテクチャごとの違いに対して責任を負うチームは () すべてのパッケージをコンパイルし、必要ならばそれらを自分たちのアーキテクチャに適合させます。
メンテナンスを保証する際に 1 チームの負担が大きくなりすぎないよう、最も重要なパッケージに対しては別のチームが管理しています。そのようなケースとして、C ライブラリと 、C コンパイラと 、Xorg と (このグループは X Strike Force としても知られています) の関係が挙げられます。