Product SiteDocumentation Site

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

Debian プロジェクトによるたくさんの最終結果は、経験豊富な Debian 開発者によるインフラ整備作業、Debian パッケージに対する個人または共同作業、そしてユーザからのフィードバックの同時進行により成り立っています。

1.3.1. Debian 開発者

Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.
パッケージメンテナンスは比較的厳格に管理された活動で、明確に文書化されており、もっと言えばルールが決められています。事実上、パッケージメンテナンスに関連するルールは Debian ポリシーの定めるすべての基準と適合します。幸いなことに、パッケージメンテナンスの作業を手助けする多くのツールが存在します。それゆえ、開発者は担当パッケージに固有の作業やたとえばバグ修正などのより複雑な作業に集中することが可能です。
Debian プロジェクトの重要な要素である Debian ポリシーはパッケージの品質と Debian ディストリビューションの完全な相互運用性の両方を確保するための規範を定めています。Debian ポリシーのおかげで、Debian は巨大であるにも関わらずその一貫性を保っています。Debian ポリシーは不変の原則というわけではなく、 メーリングリストに寄せられた提案を練ることで絶え間なく進化しています。関係者全員からの同意を得られた修正は承認され、編集責任を持たないメンテナの小集団がこれを文章に反映します (この小集団ができることは、上に挙げたメーリングリストのメンバーである Debian 開発者から同意を得られた修正を反映させることだけです)。現在寄せられている修正の提案を読むにはバグ追跡システムをご確認ください。
The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.
This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.
具体的に言えば、Debian プロジェクトリーダーは本当の意味での権力を持っています。さらに、賛否同数の場合にはリーダーの投票が決定票となります。その上、リーダーはまだ誰の権限下にもなっていない案件に判決を下したり、自身の権限の一部を委任したりすることが可能です。
Since its inception, the project has been successively led by 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, and Jonathan Carter.
Debian 憲章では「技術委員会」もまた定義されています。技術委員会の本質的な役割とは、ある技術的な事柄に関して関係する開発者の間で合意に達しなかった場合に、その技術的な事柄の決裁を下すことです。また技術委員会の他の役割として、責任を負っている決定で間違いを犯す開発者に対する顧問役があります。ただし、技術委員会は問題になっているグループの一員から参加するように求められた場合のみ議論に参加するということに注意しなければいけません。
最後に、Debian 憲章では「プロジェクト秘書」の役職も定義しています。プロジェクト秘書はさまざまな選挙と一般決議に関連する投票の運営に責任を負っています。
The “general resolution” (GR) procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:
Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person put into it.
Debian プロジェクト内で自分の地位を高めるにはたった一つの方法しかありません。すなわち、何か有益なことをして、それがうまくいったことを示すことです。多くの Debian「管理」チームはチーム内メンバーからの推薦で新メンバーを採用します。つまり、これまでの貢献が効果を挙げており、本人の能力が証明されているボランティアを好むということです。これらのチームの作業は公開されており、新しい貢献者がその作業を観察し手助けを開始するのに特権を必要としません。そのため、Debian は「業績主義」と言われています。
この効果的な運営方法のおかげで「重要な」Debian チーム内では貢献者の品質が保証されています。この方法は決して完璧ではありませんし、時々この運営方法を受け入れられない人もいます。チーム内で採用されている開発者の選択基準は少し気まぐれかもっと言えば不公平なものに見えるかもしれません。その上、チームから受けられるサービスに関して全員が同じ定義を共有しているとも限りません。新しい Debian パッケージを含めるのに 8 日間待たなければいけないのは受け入れがたいという人もいれば、なんの問題もなく 3 週間気長に待つという人もいます。そんなわけで、いくつかのチームが提供する「サービス品質」には常に不満の声が上げられています。

1.3.2. ユーザの積極的役割

読者の皆様の中には Debian プロジェクト内で働く人の中でも特にユーザに言及する必要があるのではないかと感じる方がいらっしゃるかもしれません。これはごく当たり前の感覚です。なぜなら Debian プロジェクトではユーザが重要な役割を果たしているからです。「受け身」の状態から一歩進んで、Debian の開発版を使い、バグ報告を提出して問題を指摘するユーザもいます。さらに深く立ち入り、重要度「wishlist」のバグ報告を提出することで改善案を投稿したり、「パッチ」と呼ばれるソースコードの修正を投稿するユーザもいます (補注第 1.3.2.3 節「修正の送信」をご覧ください)。

1.3.2.1. バグの報告

Debian においてバグを報告するための基本的なツールは Debian バグ追跡システム (Debian BTS) であり、プロジェクトで広く使われています。公開部分 (ウェブインターフェース) を使ってユーザは報告されたバグをすべて見ることが可能です、必要であれば、さまざまな基準に従ってソート済みのバグリストを表示することが可能です。ここで基準とは、影響を受けるパッケージ、重要度、状態、報告者のアドレス、パッケージの責任を負うメンテナのアドレス、タグなどです。あるバグに関連するすべての議論の完全な履歴リストを閲覧することも可能です。
内部的には Debian BTS は電子メールを基礎に使っています。すなわち、BTS に保存されているすべての情報は関係するさまざまな人が送信したメッセージに基づいています。 宛に送信された電子メールはバグ番号 12345 のバグに関する連絡履歴に割り当てられます。議論を終わらせる理由を説明したメッセージを 宛に書くことで、権限のある人がバグを「閉じる」ことがあります (バグを閉じるのは、報告された問題が解決されたか、もはやその問題に意味がない場合です)。新しいバグを報告するには、問題になっているパッケージの特定に必要である特殊な書式に従い、 宛に電子メールを送ってください。アドレス はあるバグに関連するすべての「メタ情報」を編集するために設けられています。
Debian BTS には他にも機能的特色 (バグにラベル付けするための便利なタグ機能など) があります。詳しい情報を見るには以下の URL を参照してください。
Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps writing a complete bug report, without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug can also use a local server).
reportbug はどちらかと言えば開発版で使用すべきツールです。なぜなら、報告されたバグは開発版で修正されるからです。実際のところ、Debian の安定版では、セキュリティ更新やその他の重要な更新 (たとえば、あるパッケージが全く動かない) などのごく少数の例外を除いて、修正を歓迎しません。そんなわけで Debian パッケージの深刻でないバグの修正は次の安定版まで待たなければいけません。

1.3.2.2. 翻訳と文書化

加えて、Debian の提供するサービスに満足している数多くのユーザが彼ら自身の手でプロジェクトに貢献をしたいと思っています。プログラミングに関する専門知識のレベルが十分でない人は翻訳や文書のレビューを行うことで手助けを行うことを選ぶかもしれません。このような作業を行うために各言語に特有の問題を議論するためのメーリングリストがあります。

1.3.2.3. 修正の送信

より高度なユーザはパッチを送ることによってプログラムへの修正を提供できるでしょう。
パッチとは単独または複数のファイルに対する変更内容を記述したファイルです。具体的に言うと、パッチはコードを修正後の内容に置き換えるために、コードから削除された行と追加された行と (時々) それらの行位置の目印となるテキスト (これは行番号が変わった場合に変更の場所を特定するためのものです) のリストを含んでいます。
パッチファイルの提供する修正を適用するためのツールは 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 と全く同じものになります。
In practice, most software is currently maintained in Git repositories and contributors are thus more likely to use git to retrieve the source code and propose changes. git diff will generate a file in the same format as what diff -u would do and git apply can do the same as patch.
While the output of git diff is a file that can be shared with other developers, there are usually better ways to submit changes. If the developers prefer to get patches by email, they usually want patches generated with git format-patch so that they can be directly integrated in the repository with git am. This preserves commits meta-information and makes it possible to share multiple commits at once.
This email-based workflow is still popular but it tends to be replaced by the usage of merge requests (or pull requests) whenever the software is hosted in a platform like GitHub or GitLab — and Debian is using GitLab on its salsa.debian.org server. On those systems, once you have created an account, you fork the repository, effectively creating a copy of the repository in your own account, and you can then clone that repository and push your own changes in it. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click.

1.3.2.4. Other ways of contributing

All of these contribution mechanisms are made more efficient by users' behavior. Far from being a collection of isolated persons, users are a true community within which numerous exchanges take place. We especially note the impressive activity on the user discussion mailing list, (第 7 章「問題の解決と関連情報の探索 discusses this in greater detail).
ユーザは自分に直接影響をおよぼす技術的な問題について互いに助け合ったり、技術的な問題を抱える誰かを助けたりするだけでなく、Debian プロジェクトに貢献するための最良の方法を話し合い、Debian プロジェクトを前進させる手助けをしています。このような議論はしばしば改良を提案するものとなります。
Debian は自己アピールによる普及キャンペーンに資金を使わないため、Debian のユーザは Debian の普及に重要な役割を果たし、Debian の評判は口コミで伝わることが保障されています。
This method works quite well, since Debian fans are found at all levels of the free software community: from install parties (workshops where seasoned users assist newcomers to install the system) organized by local LUGs or “Linux User Groups”, to association booths at large tech conventions dealing with Linux, etc.
ボランティアがポスター、パンフレット、ステッカーなどのプロジェクトの宣伝に役立つ資料を作っています。この宣伝資料は誰もが利用できるようにされており、Debian はウェブサイトでこの宣伝資料を無制限に提供しています。

1.3.3. Teams, Blends, and Sub-Projects

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.

1.3.3.1. Existing Debian Sub-Projects and Blends

To each their own Debian! A sub-project is a group of volunteers interested in adapting Debian to specific needs. Beyond the selection of a sub-group of programs intended for a particular domain (education, medicine, multimedia creation, etc.), sub-projects are also involved in improving existing packages, packaging missing software, adapting the installer, creating specific documentation, and more. While a "blend" might not be exactly the same, it works quite similar and also tries to provide a solution for groups of people intending to use Debian for a particular domain. One could say that "Debian Pure Blends" is the successor of sub-projects.
Here is a small selection of current released Debian Pure Blends:
  • Debian Junior, by Ben Armstrong, offering an appealing and easy to use Debian system for children;
  • Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic and educational world;
  • Debian Med。これは Andreas Tille によって作成され、医療分野に特化しています。
  • Debian Multimedia, which deals with audio and multimedia work;
  • Debian GIS, which takes care of Geographical Information Systems applications and users;
  • Debian Astro, for both professionals and hobby astronomers;
  • Debian Science, working on providing researchers and scientists a better experience using Debian;
  • Freedombox, made to develop, design and promote personal servers running free software for private, personal communications;
  • Debian Games, providing games in Debian from arcade and adventure to simulation and strategy;
  • DebiChem, targeted at Chemistry, provides chemical suites and programs.
The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian Pure Blends. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.

1.3.3.2. 管理チーム

Most administrative teams are relatively closed and recruit only by co-optation. The best means to become a part of one is to intelligently assist the current members, demonstrating that you have understood their objectives and methods of operation.
The ftpmasters are in charge of the official archive of Debian packages. They maintain the program that receives packages sent by developers and automatically stores them, after some checks, on the reference server (ftp-master.debian.org).
ftpmaster はまた、パッケージデータベースの中に新しいパッケージを追加する前に、Debian がこのパッケージを配布しても問題ないことを確認するために、このパッケージのライセンスを確認します。開発者がパッケージの削除を希望する場合、開発者はバグ追跡システムから ftp.debian.org「擬似パッケージ」に対してバグ報告を行い、ftpmaster と連絡を取ります。
The Debian System Administrators (DSA) team (), as one might expect, is responsible for system administration of the many servers used by the project. They ensure optimal functioning of all base services (DNS, Web, e-mail, shell, etc.), install software requested by Debian developers, and take all precautions in regards to security.
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.

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

管理チームとは異なり、開発チームの門戸は外部の貢献者に向けてかなり大きく開かれています。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 mailing list, under the direction of Cyril Brulebois.
debian-cd プログラム (とても小さい) のチームはさらにいっそう控えめな目的を持っています。数多くの「小」貢献者は自分が担当しているアーキテクチャに対して責任を負っています。なぜなら主開発者はアーキテクチャに固有のすべての細かな差異や CD-ROM からインストーラを起動する正確な方法を知ることはできないからです。
多くのチームは他のチームと一緒にパッケージングを行わなければいけません。たとえば は Debian プロジェクトのあらゆるレベルで品質を保証しようと試みます。 メーリングリストはあちこちからの提案に従って Debian ポリシーを成長させます。アーキテクチャごとの違いに対して責任を負うチーム () はすべてのパッケージをコンパイルし、必要ならばパッケージを自分たちが担当しているアーキテクチャに適合するよう書き換えます。
メンテナンスを保証する際に 1 チームの負担が大きくなりすぎないよう、最も重要なパッケージに対しては別のチームが管理しています。そのようなケースとして、C ライブラリと 、C コンパイラと 、Xorg と (このグループは X Strike Force としても知られています) の関係が挙げられます。