Debian プロジェクトによるたくさんの最終結果は、経験豊富な Debian 開発者によるインフラ整備作業、Debian パッケージに対する個人または共同作業、そしてユーザからのフィードバックの同時進行により成り立っています。
Debian 開発者には公式プロジェクトメンバーとしてのさまざまな責任があります。またプロジェクトの正式なメンバーとして、Debian 開発者はプロジェクトの方針に重大な影響をおよぼします。伝統的に一般に Debian 開発者は最低 1 つのパッケージに対して責任がありますが、時間に余裕がありそうしたいと思えば、多数のチームとプロジェクトに参加することでプロジェクト内でより重い責任を負うことも自由にできます。
パッケージメンテナンスは比較的厳格に管理された活動で、明確に文書化されており、もっと言えばルールが決められています。事実上、パッケージメンテナンスに関連するルールは
Debian ポリシーの定めるすべての基準と適合します。幸いなことに、パッケージメンテナンスの作業を手助けする多くのツールが存在します。それゆえ、開発者は担当パッケージに固有の作業やたとえばバグ修正などのより複雑な作業に集中することが可能です。
Debian プロジェクトの重要な要素である Debian ポリシーはパッケージの品質と Debian ディストリビューションの完全な相互運用性の両方を確保するための規範を定めています。Debian ポリシーのおかげで、Debian は巨大であるにも関わらずその一貫性を保っています。Debian ポリシーは不変の原則というわけではなく、
debian-policy@lists.debian.org メーリングリストに寄せられた提案を練ることで絶え間なく進化しています。関係者全員からの同意を得られた修正は承認され、編集責任を持たないメンテナの小集団がこれを文章に反映します (この小集団ができることは、上に挙げたメーリングリストのメンバーである Debian 開発者から同意を得られた修正を反映させることだけです)。現在寄せられている修正の提案を読むにはバグ追跡システムをご確認ください。
Debian ポリシーはパッケージングの技術的側面の大部分を網羅しています。Debian プロジェクトの大きさは組織の問題を引き起こします。この種の問題は Debian 憲章に即して対処されます。Debian 憲章は組織体制と意思決定の手段を定めています。これは言い換えれば、組織的な管理システムと言えます。
Debian 憲章はいくつかの役割と役職、併せてそれぞれに対する責任と権限を定義しています。特筆すべきは Debian 開発者は一般決議に投票することで最終決定を行う権限を常に持っているということです、重大な変化 (基本文書に影響をおよぼすような変化) を起こすには特定多数の 4 分の 3 (75%) が投票すること必要です。しかしながら、Debian 開発者は会議で自分たちを代表し、さまざまなチーム間の連携を確保する「Debian プロジェクトリーダー (DPL)」を毎年選びます。リーダーの選挙は常に活発な議論になります。Debian プロジェクトリーダー
DPLの役割は何かの文書で正式に定義されているわけではありません。なぜなら通常、リーダー職の候補者はその役割を自分自身で定義し、それを提案するからです。実際のところ、リーダーの役割には開発者からの共感を得るように、メディアに対する代表者として働くこと、「内部」チーム間の連携をとること、プロジェクトに対する包括的な指導を提供すること、が含まれています。そして、DPL の見解は大多数のプロジェクトメンバーから暗黙のうちに容認されています。
具体的に言えば、Debian プロジェクトリーダーは本当の意味での権力を持っています。さらに、賛否同数の場合にはリーダーの投票が決定票となります。その上、リーダーはまだ誰の権限下にもなっていない案件に判決を下したり、自身の権限の一部を委任したりすることが可能です。
Debian が始まって以来ずっと Debian プロジェクトは止まることなく Debian プロジェクトリーダーに先導されてきました。現在までに DPL の職に就いた人は 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、Neill McGovern、Mehdi Dogguy、Chris Lamb、Sam Hartman、Jonathan Carter、Andreas Tille です。
Debian 憲章では「技術委員会」もまた定義されています。技術委員会の本質的な役割とは、ある技術的な事柄に関して関係する開発者の間で合意に達しなかった場合に、その技術的な事柄の決裁を下すことです。また技術委員会の他の役割として、責任を負っている決定で間違いを犯す開発者に対する顧問役があります。ただし、技術委員会は問題になっているグループの一員から参加するように求められた場合のみ議論に参加するということに注意しなければいけません。
最後に、Debian 憲章では「プロジェクト秘書」の役職も定義しています。プロジェクト秘書はさまざまな選挙と一般決議に関連する投票の運営に責任を負っています。
「一般決議」(
GR) の手続きは Debian 憲章の中で最初の議論期間から最後の開票まで詳細に説明されています。この手続の最も興味深い側面は、現行の投票に関して言えば、開発者はさまざまな投票選択肢に対して選好の順序を付けなければいけないということと、
コンドルセ方式 (より正確に言えば、シュルツ方式) に基づいて勝者が選ばれるということです。より詳しい情報は以下のページを参照してください。
たとえ Debian 憲章の規定する民主制が名ばかりのようなものであったとしても、毎日の現実は全く違ったものです。なぜなら Debian は当然ながらフリーソフトウェアにおける能動主義 (do-ocracy) のルールに従い、物事はそれを行った者がどのように行うかを決めるからです。問題に対処するさまざまな方法のそれぞれの価値を議論することは多くの時間を無駄にする可能性があります。つまり議論の結果最終的に選ばれるのは、現実的かつ要件を満足できる最初に提案された解決策になることでしょう…。このような解決策は、一人の有能な人物が時間をかけて努力しなければ、導き出されるものではありません。
Debian プロジェクト内で自分の地位を高めるにはたった一つの方法しかありません。すなわち、何か有益なことをして、それがうまくいったことを示すことです。多くの Debian「管理」チームはチーム内メンバーからの推薦で新メンバーを採用します。つまり、これまでの貢献が効果を挙げており、本人の能力が証明されているボランティアを好むということです。これらのチームの作業は公開されており、新しい貢献者がその作業を観察し手助けを開始するのに特権を必要としません。そのため、Debian は「業績主義」と言われています。
この効果的な運営方法のおかげで「重要な」Debian チーム内では貢献者の品質が保証されています。この方法は決して完璧ではありませんし、時々この運営方法を受け入れられない人もいます。チーム内で採用されている開発者の選択基準は少し気まぐれかもっと言えば不公平なものに見えるかもしれません。その上、チームから受けられるサービスに関して全員が同じ定義を共有しているとも限りません。新しい Debian パッケージを含めるのに 8 日間待たなければいけないのは受け入れがたいという人もいれば、なんの問題もなく 3 週間気長に待つという人もいます。そんなわけで、いくつかのチームが提供する「サービス品質」には常に不満の声が上げられています。
読者の皆様の中には Debian プロジェクト内で働く人の中でも特にユーザに言及する必要があるのではないかと感じる方がいらっしゃるかもしれません。これはごく当たり前の感覚です。なぜなら Debian プロジェクトではユーザが重要な役割を果たしているからです。「受け身」の状態から一歩進んで、Debian の開発版を使い、バグ報告を提出して問題を指摘するユーザもいます。さらに深く立ち入り、重要度「wishlist」のバグ報告を提出することで改善案を投稿したり、「パッチ」と呼ばれるソースコードの修正を投稿するユーザもいます (補注
第 1.3.2.3 節「修正の送信」をご覧ください)。
Debian においてバグを報告するための基本的なツールは Debian バグ追跡システム (Debian BTS) であり、プロジェクトで広く使われています。公開部分 (ウェブインターフェース) を使ってユーザは報告されたバグをすべて見ることが可能です、必要であれば、さまざまな基準に従ってソート済みのバグリストを表示することが可能です。ここで基準とは、影響を受けるパッケージ、重要度、状態、報告者のアドレス、パッケージの責任を負うメンテナのアドレス、タグなどです。あるバグに関連するすべての議論の完全な履歴リストを閲覧することも可能です。
Debian BTS には他にも機能的特色 (バグにラベル付けするための便利なタグ機能など) があります。詳しい情報を見るには以下の URL を参照してください。
ユーザは reportbug ツールによって Debian パッケージに対するバグ報告をコマンドラインですることもできます。問題になっているバグが既に報告されていないかを確認する際に役立ち、同じバグがシステムに報告されることを防いでいます。reportbug はユーザに可能な限り正確な報告をさせるために、重要度の定義を表示します (開発者は後から必要になればいつでもレベルを微調整することが可能です)。bts はバグ報告を適切な書式に整形する機能と内容をユーザが編集できる機能を提供しているので、reportbug を使えばユーザはバグ報告の正確な書式を知らなくても完全なバグ報告を書くことが可能です。その後、この報告は電子メールサーバを経由して送信されます (デフォルトでは Debian が運営するリモートサーバを使いますが、reportbug はローカルサーバを使うことも可能です)。
reportbug はどちらかと言えば開発版で使用すべきツールです。なぜなら、報告されたバグは開発版で修正されるからです。実際のところ、Debian の安定版では、セキュリティ更新やその他の重要な更新 (たとえば、あるパッケージが全く動かない) などのごく少数の例外を除いて、修正を歓迎しません。そんなわけで Debian パッケージの深刻でないバグの修正は次の安定版まで待たなければいけません。
加えて、Debian の提供するサービスに満足している数多くのユーザが彼ら自身の手でプロジェクトに貢献をしたいと思っています。プログラミングに関する専門知識のレベルが十分でない人は翻訳や文書のレビューを行うことで手助けを行うことを選ぶかもしれません。このような作業を行うために各言語に特有の問題を議論するためのメーリングリストがあります。
より高度なユーザはパッチを送ることによってプログラムへの修正を提供できるでしょう。
パッチとは単独または複数のファイルに対する変更内容を記述したファイルです。具体的に言うと、パッチはコードを修正後の内容に置き換えるために、コードから削除された行と追加された行と (時々) それらの行位置の目印となるテキスト (これは行番号が変わった場合に変更の場所を特定するためのものです) のリストを含んでいます。
パッチファイルの提供する修正を適用するためのツールは patch と呼ばれています。パッチファイルを作成するためのツールは diff と呼ばれており、以下のように使います。
$ diff -u file.old file.new >file.patch
file.patch ファイルには file.old の内容を file.new の内容に変更するための指示が含まれています。われわれはこのパッチファイルを送信することができ、受け取った人はパッチファイルを適用して file.new を再作成することが可能です、これを行うには以下のようにします。
$ patch -p0 file.old <file.patch
こうすることで file.old ファイルは file.new と全く同じものになります。
実際には、多くのソフトウェアは現在 Git レポジトリでメンテナンスされており、したがって貢献者はソースコードを取得し変更を提案するのに git を使うことが多いでしょう。git diff は diff -u と同じ形式のファイルを生成し git apply で patch と同じことができます。
git diff というコマンドの出力は他の開発者と共有のファイルに展開されますので、通常は他のよりよい方法を使って変更を送信します。 もし、開発者がメールでパッチを入手したい場合、git format-patch は直接パッチを生成するコマンドで、git am はリポジトリにあるパッチを直接統合するコマンドです。これを行えば、コミットしたメタデータも保存され、同時に共有されます。
このメールベースのワークフローは今でも人気がありますが、ソフトウェアが GitHub や GitLab などのプラットフォームでホストされている場合は、マージ リクエスト (または プル リクエスト) に置き換えられる傾向があります。Debian は salsa.debian.org サーバーで GitLab を使用しています。これらのシステムでは、作成したアカウント上にリポジトリを フォーク して、実質的に自分のアカウントにリポジトリのコピーを作成し、そのリポジトリをクローンして自分の変更をプッシュすることができます。そこから、Web インターフェイスがマージ リクエストを送信するように提案し、開発者に変更を通知して、開発者が 1 回のクリックで変更を確認して承認できるようにします。
ユーザは自分に直接影響をおよぼす技術的な問題について互いに助け合ったり、技術的な問題を抱える誰かを助けたりするだけでなく、Debian プロジェクトに貢献するための最良の方法を話し合い、Debian プロジェクトを前進させる手助けをしています。このような議論はしばしば改良を提案するものとなります。
Debian は自己アピールによる普及キャンペーンに資金を使わないため、Debian のユーザは Debian の普及に重要な役割を果たし、Debian の評判は口コミで伝わることが保障されています。
この方法は極めてうまくいきます。なぜならフリーソフトウェアコミュニティのあらゆる層に Debian の支持者がいるからです。すなわち、地域の
LUG「Linux ユーザグループ」が企画したインストールパーティ (ベテランユーザが新しいユーザにシステムのインストールの補助を行うワークショップ) から、Linux などについて取り扱う大きな技術会議のアソシエーションブースにまで、Debian の支持者がいるということです。
ボランティアがポスター、パンフレット、ステッカーなどのプロジェクトの宣伝に役立つ資料を作っています。この宣伝資料は誰もが利用できるようにされており、Debian はウェブサイトでこの宣伝資料を無制限に提供しています。
Debian は当初から、ソースパッケージの概念を中心に組織化され続けており、ソースパッケージにはそのメンテナとメンテナのグループがいます。多くの作業チームは長い時間をかけて生まれ続けており、最近サブプロジェクトとブレンドの周りで成長している最新の一連のチームとともに、インフラの運営および特定のパッケージに依存しないタスク (品質保証、Debian ポリシー、インストーラなど) の管理を保証しています。
1.3.3.1. 現存する Debian サブプロジェクトとブレンド
人それぞれ好みの Debian があります! サブプロジェクトは Debian を特定のニーズに適応させることに興味を持つボランティアのグループです。特定の領域 (教育、医療、マルチメディア制作など) を対象としたプログラム群の選定にとどまらず、サブプロジェクトは既存パッケージの改良、不足ソフトウェアのパッケージング、インストーラの適応作業、特定文書の作成などにも従事しています。「ブレンド」は完全に同じではないかもしれませんが、非常に似た仕組みで、特定の分野でDebianを利用しようとするグループに最適解を提供することを目指しています。「Debian Pure Blends」は、サブプロジェクトの後継と言えるでしょう。
以下は現存するサブプロジェクトと公式ブレンドを一部抜粋したものです。
Debian Juniorは、子供向けに魅力的で使いやすい Debian システムを提供しています。
Debian Eduは、学校教育用向けに特化したディストリビューションの作成を重視しています。
Debian Medは、医療分野に特化しています。
Debian Multimediaは、音声およびマルチメディア制作を取り扱います。
Debian GISは、地理情報システムのアプリケーションとユーザに向けて開発されています。
Debian Astroは、天体観測に特化されています;
Debian Scienceは、Debianを科学研究用に特化しています;
Freedomboxは、個人用サーバの開発とフリーソフトの開発に特化しています;
Debian Gamesは、Debianに収録されているアーケードから戦略シミュレーションまで多岐にわたるゲームを提供しています;
DebiChemは、化学研究者用に便利な一連のアプリケーションを取り揃えています。
Debian サブプロジェクトの数は時間が経過するに従って増え続け、Debian 公式ブレンドの良さを再認識すること間違いありません。既存の Debian のインフラはサブプロジェクトを完全にサポートしているので、実質的にサブプロジェクトが真の付加価値を上げるための作業に集中することを可能にしています。サブプロジェクトは Debian プロジェクト内で開発しているため Debian との同期について心配することはありません。
多くの管理チームは比較的閉鎖的で新メンバーの採用は現メンバーからの選出で決まります。管理チームの一員になる最良の手段は現在のメンバーを賢明に手伝うこと、つまり自分が管理チームの目標と流儀を理解していることをはっきり示すことです。
ftpmaster は Debian パッケージの公式アーカイブの責任者です。ftpmaster はあるプログラムのメンテナンスを担当しており、このプログラムは開発者が送信したパッケージを受け取り、いくつかの事項を確認した後にパッケージを自動的に参照基準サーバ (ftp-master.debian.org) に保存しています。
ftpmaster はまた、パッケージデータベースの中に新しいパッケージを追加する前に、Debian がこのパッケージを配布しても問題ないことを確認するために、このパッケージのライセンスを確認します。開発者がパッケージの削除を希望する場合、開発者はバグ追跡システムから ftp.debian.org「擬似パッケージ」に対してバグ報告を行い、ftpmaster と連絡を取ります。
Debian システム管理者 (
DSA) チーム (
debian-admin@lists.debian.org) は、読者の皆様の予想通り、Debian プロジェクトが利用する多くのサーバのシステム管理に対して責任があります。DSA チームは、すべての基盤サービス (DNS、ウェブ、電子メール、シェルなど) を最適に機能させること、Debian 開発者から要求のあったソフトウェアをインストールすること、セキュリティ関連の予防策を適用すること、を保証します。
listmaster はメーリングリストを運営する電子メールサーバを管理します。新しいメーリングリストを作成し、宛先が不明なメールを処理 (配送失敗通知) し、スパムフィルタ (迷惑メールフィルタ) をメンテナンスするのは listmaster の役目です。
Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case for the bug tracking system (BTS), the package tracker,
salsa.debian.org (GitLab server, see sidebar
「TOOL GitLab、Git リポジトリのホスティングなど」), the services available on
qa.debian.org,
lintian.debian.org,
buildd.debian.org,
cdimage.debian.org, etc.
管理チームとは異なり、開発チームの門戸は外部の貢献者に向けてかなり大きく開かれています。Debian の使命がソフトウェアを作成することではないとしても、Debian プロジェクトは目標を達成するために特定のプログラムを必要としています。もちろん、フリーソフトウェアライセンスの下で開発されたそれらのソフトウェアはフリーソフトウェア世界の他の場所で保証されている方法を活用します。
Debian は自分用に小さなソフトウェアを開発し続けていますが、一部のプログラムは重要な役割を担っており、そのようなプログラムの名声は Debian プロジェクトよりも大きく広がっています。Debian パッケージ管理プログラムの dpkg (実際のところ、これは Debian PacKaGe の 略称で、「dee-package」と発音されます) と、任意の Debian パッケージとそのパッケージが依存しているパッケージを、更新後のシステムの継続性を保障しながら、自動的にインストールする apt (名前は Advanced Package Tool の頭字語) がそのよい例です。一方で、これらのプログラムの働きを全面的に理解するには極めて高いプログラミング能力が必要であるため、チームの規模は極めて小さなものです。
The most important team is probably that for the Debian installation program,
debian-installer, which has accomplished a work of momentous proportions since its conception in 2001. Numerous contributors were needed, since it is difficult to write a single program able to install Debian on a dozen different architectures. Each one has its own mechanism for booting and its own bootloader. All of this work is coordinated on the
debian-boot@lists.debian.org mailing list, under the direction of Cyril Brulebois.
debian-cd プログラム (とても小さい) のチームはさらにいっそう控えめな目的を持っています。数多くの「小」貢献者は自分が担当しているアーキテクチャに対して責任を負っています。なぜなら主開発者はアーキテクチャに固有のすべての細かな差異や CD-ROM からインストーラを起動する正確な方法を知ることはできないからです。
