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, thus acquiring more responsibilities within the project.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

TOOL 開発者データベース

Debian にはプロジェクトに登録されているすべての開発者と開発者に関連する情報 (アドレス、電話番号、緯度と経度といった地理座標など) のデータベースがあります。一部の情報 (姓名、国籍、プロジェクト内でのユーザ名、IRC ユーザ名、GnuPG 鍵など) は公開されておりウェブから入手することが可能です。

→ https://db.debian.org/

この地理座標を使えば、世界中にいる開発者全員の位置を載せた地図が作れます。Debian は本当の意味で国際的なプロジェクトです。つまり、すべての大陸に開発者がいます (しかしその大部分は「欧米」です)。

図 1.1 世界的に広がる Debian 開発者

パッケージメンテナンスは比較的厳格に管理された活動で、明確に文書化されており、もっと言えばルールが決められています。事実上、パッケージメンテナンスに関連するルールは Debian ポリシーの定めるすべての基準と適合します。幸いなことに、パッケージメンテナンスの作業を手助けする多くのツールが存在します。それゆえ、開発者は担当パッケージに固有の作業やたとえばバグ修正などのより複雑な作業に集中することが可能です。

→ https://www.debian.org/doc/debian-policy/

BACK TO BASICS パッケージメンテナンス、開発者の作業

パッケージメンテナンスとはまず初めにあるプログラムを「パッケージング」することを必要とします。具体的に言うと、パッケージングとはあるプログラムをインストールする方法を定義することを意味しています。パッケージングすることにより、プログラムはインストール後すぐに動作するようになり、Debian プロジェクトが自身のために設定したルールを遵守するでしょう。この操作の結果が .deb ファイルに保存されています。事実上、プログラムのインストールに必要な作業とは、圧縮されたアーカイブを展開すること、インストール前およびインストール後にスクリプトを実行すること、だけです。

パッケージングという最初の段階の後、メンテナンスサイクルが本当に始まります。ここでメンテナンスとは、Debian ポリシーの最新版に従うように更新を準備すること、ユーザから報告を受けたバグを修正すること、プログラムの新しい「上流」バージョン (開発を自然に継続したバージョン) を含めること、です。たとえば、最初のパッケージングの際、プログラムのバージョンが 1.2.3 だったとしましょう。数カ月の開発の後、オリジナルの作者は新しい安定版バージョン 1.4.0 を発表しました。この時点で、Debian メンテナはパッケージを更新するべきです。そうすればユーザは最新安定版の恩恵を受けられるようになります。

Debian プロジェクトの重要な要素である Debian ポリシーはパッケージの品質と Debian ディストリビューションの完全な相互運用性の両方を確保するための規範を定めています。Debian ポリシーのおかげで、Debian は巨大であるにも関わらずその一貫性を保っています。Debian ポリシーは不変の原則というわけではなく、debian-policy@lists.debian.org メーリングリストに寄せられた提案を練ることで絶え間なく進化しています。関係者全員からの同意を得られた修正は承認され、編集責任を持たないメンテナの小集団がこれを文章に反映します (この小集団ができることは、上に挙げたメーリングリストのメンバーである Debian 開発者から同意を得られた修正を反映させることだけです)。現在寄せられている修正の提案を読むにはバグ追跡システムをご確認ください。

→ https://bugs.debian.org/debian-policy

COMMUNITY ポリシー編集手続き

Anyone can propose an amendment to the Debian Policy just by submitting a bug report with a severity level of “wishlist” against the debian-policy package. The process that then starts is documented in https://www.debian.org/doc/debian-policy/ap-process.html: if it is acknowledged that the problem revealed must be resolved by creating a new rule in the Debian Policy, a discussion begins on the debian-policy@lists.debian.org mailing list until consensus is reached and a proposal issued. Someone then drafts a desired amendment and submits it for approval (in the form of a patch to review). As soon as two other developers approve the fact that the proposed amendment reflects the consensus reached in the previous discussion (they “second” it), the proposal can be included in the official document by one of the debian-policy package maintainers. If the process fails at one of these steps, the maintainers close the bug, classifying the proposal as rejected.

DEBIAN POLICY 文書

各パッケージに関する文書は /usr/share/doc/package/ に保存されています。多くの場合このディレクトリには README.Debian ファイルが含まれています。このファイルにはパッケージメンテナが行った Debian 特有の修正について説明が書かれています。つまり、メンテナの経験から恩恵を受けるためには、設定の前にこのファイルを読むことが賢明です。また、このディレクトリに含まれる changelog.Debian.gz ファイルにはあるバージョンから次のバージョンに更新した際に Debian メンテナが行った変更についての説明が書かれています。このファイルを changelog.gz ファイル (または同等のファイル、上流開発者が行った変更に関する説明が書かれたファイル) と混同してはいけません。copyright ファイルにはソフトウェアの作者とそのライセンスに関する情報が書かれています。最後に、このディレクトリに含まれる NEWS.Debian.gz と名付けられたファイルには Debian 開発者からの更新に関する重要な情報が含まれています。また、apt-listchanges がインストール済みの場合、パッケージのインストール時に changelog.Debian.gz および NEWS.Debian.gz に書かれた最新のエントリが自動的に表示されます。その他のファイルはここで注目しているソフトウェアに固有のファイルです。特に注目すべきは examples サブディレクトリで、ここには設定ファイルの例が含まれています。

Debian ポリシーはパッケージングの技術的側面の大部分をカバーしています。Debian プロジェクトの大きさは組織の問題を引き起こします。この種の問題は Debian 憲章に即して対処されます。Debian 憲章は組織体制と意思決定の手段を定めています。これは言い換えれば、組織的な管理システムと言えます。

Debian 憲章はいくつかの役割と役職、併せてそれぞれに対する責任と権限を定義しています。特筆すべきは Debian 開発者は一般決議に投票することで最終決定を行う権限を常に持っているということです、重大な変化 (基本文書に影響をおよぼすような変化) を起こすには特定多数の 4 分の 3 (75%) が投票すること必要です。しかしながら、Debian 開発者は会議で自分たちを代表し、さまざまなチーム間の連携を確保する「Debian プロジェクトリーダー (DPL)」を毎年選びます。リーダーの選挙は常に活発な議論になります。リーダーの役割は何かの文書で正式に定義されているわけではありません。なぜなら通常、リーダー職の候補者はその役割を自分自身で定義し、それを提案するからです。実際のところ、リーダーの役割には開発者からの共感を得るように、メディアに対する代表者として働くこと、「内部」チーム間の連携をとること、プロジェクトに対する包括的な指導を提供すること、が含まれています。そして、DPL の見解は大多数のプロジェクトメンバーから暗黙のうちに容認されています。

具体的に言えば、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, Mehdi Dogguy, Chris Lamb and Sam Hartman.

Debian 憲章では「技術委員会」もまた定義されています。技術委員会の本質的な役割とは、ある技術的な事柄に関して関係する開発者の間で合意に達しなかった場合に、その技術的な事柄の決裁を下すことです。また技術委員会の他の役割として、責任を負っている決定で間違いを犯す開発者に対する顧問役があります。ただし、技術委員会は問題になっているグループの一員から参加するように求められた場合のみ議論に参加するということに注意しなければいけません。

最後に、Debian 憲章では「プロジェクト秘書」の役職も定義しています。プロジェクト秘書はさまざまな選挙と一般決議に関連する投票の運営に責任を負っています。

「一般決議」の手続きは Debian 憲章の中で最初の議論期間から最後の開票まで詳細に説明されています。この手続の最も興味深い側面は、現行の投票に関して言えば、開発者はさまざまな投票選択肢に対して選好の順序を付けなければいけないということと、コンドルセ方式 (より正確に言えば、シュルツ方式) に基づいて勝者が選ばれるということです。より詳しい情報は以下のページを参照してください。

→ http://www.debian.org/devel/constitution.en.html

CULTURE ののしり合戦、炎上する議論

「ののしり合戦」とは極めて熱のこもった討論であり、多くの場合、合理的な議論が出尽くした後、双方が互いを攻撃して終わります。テーマによっては他のテーマに比べてより頻繁に論争を引き起こす場合があります (エディタの選択、「vi と emacs のどっちが好き?」、は昔からよく議論の的にされてきました)。あるテーマに対して一家言ある人々が非常に多いこと (参加者全員がそうである場合もあります) や質問内容が極めて個人的なものであることが原因で、多くの場合極めて素早く電子メールが交換されることになります。

ののしり合戦からは一般的で特に有益な結論は何一つ生まれません。従って一般的には、ののしり合戦に関わらないこと、必要なら議論の内容を素早く流し読みするだけに留めておくこと (すべての内容を読むことは多大な時間を必要としすぎるでしょうから)、をお勧めします。

たとえ Debian 憲章の規定する民主制が名ばかりのようなものであったとしても、毎日の現実は全く違ったものです。なぜなら Debian は当然ながらフリーソフトウェアにおける能動主義 (do-ocracy) のルールに従い、物事はそれを行った者がどのように行うかを決めるからです。問題に対処するさまざまな方法のそれぞれの価値を議論することは多くの時間を無駄にする可能性があります。つまり議論の結果最終的に選ばれるのは、現実的かつ要件を満足できる最初に提案された解決策になることでしょう…。このような解決策は、一人の有能な人物が時間をかけて努力しなければ、導き出されるものではありません。

Debian プロジェクト内で自分の地位を高めるにはたった一つの方法しかありません。すなわち、何か有益なことをして、それがうまくいったことを示すことです。多くの Debian「管理」チームはチーム内メンバーからの推薦で新メンバーを採用します。つまり、これまでの貢献が効果を挙げており、本人の能力が証明されているボランティアを好むということです。これらのチームの作業は公開されており、新しい貢献者がその作業を観察し手助けを開始するのに特権を必要としません。そのため、Debian は「業績主義」と言われています。

CULTURE 業績主義、知識の統治

業績主義とは、最も高い業績をもつものが権力を行使するという政治の形態です。Debian においては、業績は能力を測る物差しであり、能力はプロジェクトの単独または複数のメンバーが過去の行動を観察して評価されます (元プロジェクトリーダーの Stefano Zacchiroli は「do-ocracy」の意味は「物事を成し遂げた人に与えられる権力」を意味すると言っています)。単に業績があるということで能力が一定のレベルに達していることを証明するのです。そして、一般に成果とはソースコードが入手できるフリーソフトウェアに対するもので、同業者はソースコードから成果の品質を評価することが容易に可能です。

この効果的な運営方法のおかげで「重要な」Debian チーム内では貢献者の品質が保証されています。この方法は決して完璧ではありませんし、時々この運営方法を受け入れられない人もいます。チーム内で採用されている開発者の選択基準は少し気まぐれかもっと言えば不公平なものに見えるかもしれません。その上、チームから受けられるサービスに関して全員が同じ定義を共有しているとも限りません。新しい Debian パッケージを含めるのに 8 日間待たなければいけないのは受け入れがたいという人もいれば、なんの問題もなく 3 週間気長に待つという人もいます。そんなわけで、いくつかのチームが提供する「サービス品質」には常に不満の声が上げられています。

COMMUNITY 新しいメンテナの参加

新しい開発者の受け入れに責任を持つチームは最も定期的に批判されているチームです。ここ数年 Debian プロジェクトにはさらに多くの開発者が必要になっており、そのため今後 Debian プロジェクトは多くの開発者を受け入れることになるでしょう。われわれはこの方針を認めなければいけません。一部の人々はこの方針に不公平さを感じるかもしれません。しかし、Debian は自身がユーザに向けて作り出したすべての物に対して品質と整合性を保証するという原則を考慮すると、これが初めは小さな挑戦だったとしても 1,000 人を超えるコミュニティ内でその挑戦はより大きなものになります。われわれはこの点について自覚しなければいけません。

その上、受け入れ手続きの最終的な判断は小さなチームである Debian アカウントマネージャによる立候補者の審査に委ねられています。マネージャはボランティアを Debian 開発者コミュニティに受け入れるか拒否するかについて最終的な決定権を持っているため、特に批判を浴びるのです。実際問題として、マネージャはある候補者がプロジェクトの活動についてより多くを学ぶまでの間、その候補者の受け入れを遅らせなければならないことがあります。もちろん、候補者は現在の開発者を支援することで、公式開発者として受け入れられる前に Debian に対して貢献することも可能です。

1.3.2. ユーザの積極的役割

One might wonder if it is relevant to mention the users among those who work within the Debian project, but the answer is a definite yes: they play a critical role in the project. Far from being “passive”, some users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit ideas for improvements, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see 第 1.3.2.3 節「Sending fixes」).

1.3.2.1. Reporting bugs

The fundamental tool for submitting bugs in Debian is the Debian Bug Tracking System (Debian BTS), which is used by large parts of the project. The public part (the web interface) allows users to view all bugs reported, with the option to display a sorted list of bugs selected according to various criteria, such as: affected package, severity, status, address of the reporter, address of the maintainer in charge of it, tag, etc. It is also possible to browse the complete historical listing of all discussions regarding each of the bugs.

Debian バグ追跡システム (Debian BTS) はプロジェクトで広く使われています。公開部分 (ウェブインターフェース) を使ってユーザは報告されたバグをすべて見ることが可能です、必要であれば、さまざまな基準に従ってソート済みのバグリストを表示することが可能です。ここで基準とは、影響を受けるパッケージ、重要度、状態、報告者のアドレス、パッケージの責任を負うメンテナのアドレス、タグなどです。あるバグに関連するすべての議論の完全な履歴リストを閲覧することも可能です。

内部的には Debian BTS は電子メールを基礎に使っています。すなわち、BTS に保存されているすべての情報は関係するさまざまな人が送信したメッセージに基づいています。12345@bugs.debian.org 宛に送信された電子メールはバグ番号 12345 のバグに関する連絡履歴に割り当てられます。議論を終わらせる理由を説明したメッセージを 12345-done@bugs.debian.org 宛に書くことで、権限のある人がバグを「閉じる」ことがあります (バグを閉じるのは、報告された問題が解決されたか、もはやその問題に意味がない場合です)。新しいバグを報告するには、問題になっているパッケージの特定に必要である特殊な書式に従い、submit@bugs.debian.org 宛に電子メールを送ってください。アドレス control@bugs.debian.org はあるバグに関連するすべての「メタ情報」を編集するために設けられています。

Debian BTS には他にも機能的特色 (バグにラベル付けするための便利なタグ機能など) があります。詳しい情報を見るには以下の URL を参照してください。

→ https://www.debian.org/Bugs/

VOCABULARY バグの重要度

バグの重要度とは堅苦しく言うと報告された問題の重要性の度合いを意味しています。現実的には、すべてのバグの重要性は同一ではありません。たとえばマニュアルの誤植とサーバソフトウェアのセキュリティ脆弱性の重要度は全く違います。

Debian はバグの重要度を類型化するために等級の意味を拡大して使用しています。それぞれのレベルは、重要度の選択がしやすいよう、明確に定義されています。

→ https://www.debian.org/Bugs/Developer#severities

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. Translation and documentation

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

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

BACK TO BASICS i18n (国際化) と l10n (地域化) とは?

「i18n」と「l10n」は「internationalization (国際化)」と「localization (地域化)」の略語です。それぞれの単語の最初と最後の文字を取って、両者に挟まれた文字をその文字数で表しています。

あるプログラムの「国際化を行う」ということは、そのプログラムを翻訳 (地域化) できるように変更を加えることを含んでいます。これは最初ある言語で動くように書かれたプログラムを一部書き換えて、どんな言語でも動くようにすることを伴います。

あるプログラムの「地域化を行う」ということは、元のメッセージ (英語の場合が多い) を他の言語に翻訳することを含んでいます。地域化を行うには先にプログラムを国際化しておかなければいけません。

まとめると、国際化とはソフトウェアを翻訳するための準備で、翻訳することにより地域化が行われます。

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program sending a patch.

パッチとは単独または複数のファイルに対する変更内容を記述したファイルです。具体的に言うと、パッチはコードを修正後の内容に置き換えるために、コードから削除された行と追加された行と (時々) それらの行位置の目印となるテキスト (これは行番号が変わった場合に変更の場所を特定するためのものです) のリストを含んでいます。

パッチファイルの提供する修正を適用するためのツールは 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 と全く同じものになります。

TOOL Git, the preferred way to send patches

Git is a version-control system designed for coordinating work among developers and track their changes. It was programmed by Linus Torvalds (the creator of Linux) in 2005 to coordinate the development of the Linux kernel.

Nowadays, it is common to send patches using Git. Many Debian projects using Git can be found on https://salsa.debian.org/.

To send a patch using Git, you must download a copy of the repository, make the fixes, add them to the stage area, commit the changes, upload your changes, and request the maintainer to accept your changes. It is beyond the scope of this book to provide a detailed explanation about Git, for that you can refer to the Pro Git book (https://git-scm.com/book/).

Below is an example of the commands needed to submit a patch to this book. You can use GitLab's web interface to make the pull request; another option is to use the command git request-pull and send its output to the developers.

$ git clone https://salsa.debian.org/youruser/debian-handbook/
Cloning into 'debian-handbook'...
remote: Enumerating objects: 20838, done.
remote: Counting objects: 100% (20838/20838), done.
remote: Compressing objects: 100% (4510/4510), done.
remote: Total 20838 (delta 16316), reused 20809 (delta 16307)
Receiving objects: 100% (20838/20838), 139.41 MiB | 131.00 KiB/s, done.
Resolving deltas: 100% (16316/16316), done.
Checking out files: 100% (1351/1351), done.
$ editor file
$ git add file
$ git commit -m "Correct typo in chapter 3"
[buster/master ca5a0039] Update chapter 1
 1 file changed, 98 insertions(+), 54 deletions(-)
$ git push
Username for 'https://salsa.debian.org': youruser
Password for 'https://youruser@salsa.debian.org': yourpasswd
Enumerating objects: 96, done.
Counting objects: 100% (96/96), done.
Delta compression using up to 2 threads
Compressing objects: 100% (80/80), done.
Writing objects: 100% (80/80), 456.23 KiB | 3.83 MiB/s, done.
Total 80 (delta 59), reused 2 (delta 0)
To https://salsa.debian.org/youruser/debian-handbook.git/
   18e0e26c..ca5a0039  buster/master -> buster/master

It is a good practice to review the changes before executing git add. You can execute git diff for that. It will open the default pager (usually less) to display the differences. The lines starting with - are the removed lines, whereas the lines starting with + show added lines.

1.3.2.4. Other ways of contributing

ユーザの行動の仕方によって、上で述べたすべての貢献の仕組みはさらに効果的なものになります。孤立したユーザの集合体から一歩進んで、ユーザ間の交流が数多く起こるコミュニティこそが本物のコミュニティなのです。ユーザ議論用のメーリングリストである debian-user@lists.debian.org では素晴らしい活動がなされています (第 7 章「問題の解決と関連情報の探索」ではこの件に関して詳細に議論しています)。

ユーザは自分に直接影響をおよぼす技術的な問題について互いに助け合ったり、技術的な問題を抱える誰かを助けたりするだけでなく、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 はウェブサイトでこの宣伝資料を無制限に提供しています。

→ https://www.debian.org/events/material

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

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

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

人それぞれ好みの Debian があります! サブプロジェクトは Debian を特定のニーズに適応させることに興味を持つボランティアのグループです。特定の領域 (教育、医療、マルチメディア制作など) を対象としたプログラム群の選定にとどまらず、サブプロジェクトは既存パッケージの改良、不足ソフトウェアのパッケージング、インストーラの適応作業、特定文書の作成などにも従事しています。

VOCABULARY サブプロジェクトと派生ディストリビューション

派生ディストリビューションの開発工程とは、Debian の特定のバージョンを土台としてそれにたくさんの変更を加えることです。派生ディストリビューションを支える基礎構造は Debian プロジェクトとは全く別物です。また、Debian のように改良に貢献するポリシーを定める必要はありません。この違いは、派生ディストリビューションが Debian から「分岐」した理由、派生ディストリビューションが開発の上流側でなされた改良の恩恵を受けるために Debian と自身のソースを定期的に再同期しなければいけない理由、を説明します。

一方でサブプロジェクトは分岐できません、なぜなら特定の目的に対して適用するためにサブプロジェクトで行ったすべての作業は直接的に Debian の改善になるからです。

Debian から派生したディストリビューションはたくさんありますが、最も知られているものは間違いなく Ubuntu でしょう。派生ディストリビューションの詳細と Debian との関連性における立ち位置について学ぶには付録 A「派生ディストリビューション」をご覧ください。

以下は現存するサブプロジェクトを一部抜粋したものです。

Debian Jr., 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 world;
Debian Med。これは Andreas Tille によって作成され、医療分野に特化しています。
Debian Multimedia。これは音声およびマルチメディア制作を取り扱います。
Debian GIS。これは地理情報システムのアプリケーションとユーザの面倒を見ています。
Debian Accessibility, improving Debian to match the requirements of people with disabilities;
Debian Science, finally, working on providing researchers and scientists a better experience using Debian.
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 sub-projects. 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. 管理チーム

多くの管理チームは比較的閉鎖的で新メンバーの採用は現メンバーからの選出で決まります。管理チームの一員になる最良の手段は現在のメンバーを賢明に手伝うこと、つまり自分が管理チームの目標と流儀を理解していることをはっきり示すことです。

ftpmaster は Debian パッケージの公式アーカイブの責任者です。ftpmaster はあるプログラムのメンテナンスを担当しており、このプログラムは開発者が送信したパッケージを受け取り、いくつかの事項を確認した後にパッケージを自動的に参照基準サーバ (ftp-master.debian.org) に保存しています。

ftpmaster はまた、パッケージデータベースの中に新しいパッケージを追加する前に、Debian がこのパッケージを配布しても問題ないことを確認するために、このパッケージのライセンスを確認します。開発者がパッケージの削除を希望する場合、開発者はバグ追跡システムから ftp.debian.org「擬似パッケージ」に対してバグ報告を行い、ftpmaster と連絡を取ります。

VOCABULARY 擬似パッケージ、監視ツール

バグ追跡システムは、当初バグ報告を Debian パッケージと関連付けるために設計されましたが、その他の問題の管理にも非常に実用的であると証明し続けています。ここでその他の問題の管理とは、特定の Debian パッケージに関係しない解決すべき問題をリストアップしたり、作業を管理することです。一部のチームでは「擬似パッケージ」を使うことで、チームが実在のパッケージに関連がなくとも、バグ追跡システムを使うことができています。誰でも対処が必要な問題を報告できます。たとえば、BTS の ftp.debian.org エントリは、公式パッケージアーカイブに関する問題を報告し追跡するため、もしくはパッケージの削除要求を出すために利用されます。同様に、www.debian.org 擬似パッケージは Debian ウェブサイトの誤りを指摘するためのもので、lists.debian.org ではメーリングリストに関するすべての問題を扱います。

TOOL GitLab、Git リポジトリのホスティングなど

Debian は Git パッケージ化リポジトリをホストする目的で salsa.debian.org という GitLab インスタンスを使っていますが、これにはホスティング機能以外にも様々な機能が備わっています。GitLab を使うことで Debian 貢献者は継続的インテグレーション機能 (プッシュのたびに、テストを実行したりパッケージをビルドする機能) を簡単に使えますし、十分に理解されているマージリクエストプロセス (GitHub のプルリクエストのようなもの) のおかげで貢献ワークフローの見通しが良くなります。

現在、共同パッケージメンテナンスサービスには GitLab が使われており (alioth.debian.org では FusionForge を使っていました)、Alexander Wirt、Bastian Blank、Jörg Jaspert がこのサービスを管理しています。

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

Debian システム管理者 (DSA) チーム (debian-admin@lists.debian.org) は、読者の皆様の予想通り、Debian プロジェクトが利用する多くのサーバのシステム管理に対して責任があります。DSA チームは、すべての基盤サービス (DNS、ウェブ、電子メール、シェルなど) を最適に機能させること、Debian 開発者から要求のあったソフトウェアをインストールすること、セキュリティ関連の予防策を適用すること、を保証します。

→ https://dsa.debian.org

TOOL Debian パッケージトラッカー

Debian パッケージトラッカーは Raphaël の業績の一つです。Debian パッケージトラッカーの基本的な考え方は、あるパッケージに対して、可能な限り多くの情報を単一のページに集中させることです。こうすることで、ユーザは素早くプログラムの状態を確認し、完了させなければいけない作業を特定し、プログラムの開発に支援を申し出ることが可能です。そのため、このページには、すべてのバグ統計、それぞれのディストリビューションで利用できるバージョン、テスト版ディストリビューションにおけるパッケージの作業進行状況、パッケージ説明文と debconf テンプレートの翻訳状況、新しい上流開発版を入手できるか否か、最新の Debian ポリシーに対する違反通知、メンテナに関する情報、その他メンテナが含めたいと望んだ情報、が集められています。

→ https://tracker.debian.org/

電子メール購読サービスがこのウェブインターフェースを完全なものにします。電子メール購読サービスは情報を選別して自動的に送信します。ここで情報とは、バグおよびバグに関連する議論、Debian サーバから新しいバージョンが利用できるか否か、査読待ちの新しい翻訳などを指します。

熟練ユーザは一度パッケージ追跡システムの機能を十分よく理解したら、すべての情報をしっかりと追いかけ、より一層 Debian プロジェクトに貢献することが可能です。

もう一つのウェブインターフェースは Debian Developer's Packages Overview (DDPO) として知られています。DDPO はある開発者が責任を持つすべての Debian パッケージの概要を提供します。

→ https://qa.debian.org/developer.php

Debian パッケージトラッカーと Debian 開発者のパッケージ一覧は Debian の品質保証に責任を負うグループ (このグループは Debian QA として知られています) によって開発および管理されているツールです。

listmaster はメーリングリストを運営する電子メールサーバを管理します。新しいメーリングリストを作成し、宛先が不明なメールを処理 (配送失敗通知) し、スパムフィルタ (迷惑メールフィルタ) をメンテナンスするのは listmaster の役目です。

Debian が提供する各サービスには専属の管理チームがあり、ほとんどの場合そのサービスを設置したボランティア (しばしばサービスで利用しているツールをプログラムしたボランティア) がチームのメンバーになっています。これに当てはまるケースとして、バグ追跡システム (BTS)、パッケージトラッカー、salsa.debian.org (GitLab サーバ、補注「TOOL GitLab、Git リポジトリのホスティングなど」を参照してください)、qa.debian.org で利用できるサービス、lintian.debian.org、buildd.debian.org、cdimage.debian.org などがあります。

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

管理チームとは異なり、開発チームの門戸は外部の貢献者に向けてかなり大きく開かれています。Debian の使命がソフトウェアを作成することではないとしても、Debian プロジェクトは目標を達成するために特定のプログラムを必要としています。もちろん、フリーソフトウェアライセンスの下で開発されたそれらのソフトウェアはフリーソフトウェア世界の他の場所で保証されている方法を活用します。

CULTURE Git

Git は複数のファイルに対して共同で作業を行う際のツールで、同時に変更の履歴を管理するツールでもあります。通常 Git が管理対象とするファイルはプログラムのソースコードなどのテキストファイルです。もし数人が同じファイルに対して一緒に作業を行った場合、git がマージできるのは、同じファイルの別の場所に行われた修正だけです。それ以外の場合、手作業で「衝突」を解決しなければいけません。

Git is a distributed system where each user has a repository with the complete history of changes. Central repositories are used to download the project (git clone) and to share the work done with others (git push). The repository can contain multiple versions of the files but only one version can be worked on at a given time: it's called the working copy (it can be changed to point to another version with git checkout). Git can show you the modifications made to the working copy (git diff), can add (git add) the selected files for inclusion in a new entry in the repository, with the added files it can create a new entry in the versions history (git commit), it can update the working copy to include modifications made in parallel by other users (git pull), and can record a particular configuration in the history in order to be able to easily extract it later on (git tag).

Git を使うことで、あるプロジェクトの各バージョン同士を干渉させることなく、複数の並行バージョンを簡単に取り扱うことが可能になります。これはブランチ (枝) と呼ばれています。このように木で例えることはかなり正確です、なぜならプログラムは同じトランク (幹) に対して開発が始まっているからです。節目 (バージョン 1.0 など) に到達したら、2 つのブランチで開発が続けられます。具体的に言えば、開発ブランチでは次のメジャーリリースを準備し、メンテナンスブランチではバージョン 1.0 に対する更新と修正を管理します。

Git は現在最も人気のあるバージョン管理システムですが、Git 以外にバージョン管理システムの選択肢がないというわけではありません。歴史的に言えば、CVS (並行バージョンシステム) が初めて広く使われたツールでした。しかし、CVS にあった数多くの制限により、さらに現代的で自由なバージョン管理システムが開発されることになりました。これらの中では特に subversion (svn)、git、bazaar (bzr)、mercurial (hg) が有名です。

→ http://www.nongnu.org/cvs/

→ http://subversion.apache.org/

→ http://git-scm.com/

→ http://bazaar.canonical.com/

→ http://mercurial.selenic.com/

Debian は自分用に小さなソフトウェアを開発し続けていますが、一部のプログラムは重要な役割を担っており、そのようなプログラムの名声は Debian プロジェクトよりも大きく広がっています。Debian パッケージ管理プログラムの dpkg (実際のところ、これは Debian PacKaGe の略称で、「dee-package」と発音されます) と、任意の Debian パッケージとそのパッケージが依存しているパッケージを、更新後のシステムの継続性を保障しながら、自動的にインストールする apt (名前は Advanced Package Tool の頭字語) がそのよい例です。一方で、これらのプログラムの働きを全面的に理解するには極めて高いプログラミング能力が必要であるため、チームの規模は極めて小さなものです。

Debian インストールプログラム debian-installer の開発チームは最も重要なチームです。2001 年の構想以来ずっと、開発チームは極めて重要度の高い作業を達成し続けています。たくさんの異なるアーキテクチャに Debian をインストールできるたった 1 つのプログラムを書くのは難しいため、数多くの貢献者が必要でした。それぞれのアーキテクチャではそれぞれ異なる起動メカニズムと異なるブートローダを使っています。この作業のすべては Cyril Brulebois の指揮の下 debian-boot@lists.debian.org メーリングリストで組織的に行われています。

→ http://www.debian.org/devel/debian-installer/

→ http://joeyh.name/blog/entry/d-i_retrospective/

debian-cd プログラム (とても小さい) のチームはさらにいっそう控えめな目的を持っています。数多くの「小」貢献者は自分が担当しているアーキテクチャに対して責任を負っています。なぜなら主開発者はアーキテクチャに固有のすべての細かな差異や CD-ROM からインストーラを起動する正確な方法を知ることはできないからです。

多くのチームは他のチームと一緒にパッケージングを行わなければいけません。たとえば debian-qa@lists.debian.org は Debian プロジェクトのあらゆるレベルで品質を保証しようと試みます。debian-policy@lists.debian.org メーリングリストはあちこちからの提案に従って Debian ポリシーを成長させます。アーキテクチャごとの違いに対して責任を負うチーム (debian-architecture@lists.debian.org) はすべてのパッケージをコンパイルし、必要ならばパッケージを自分たちが担当しているアーキテクチャに適合するよう書き換えます。

メンテナンスを保証する際に 1 チームの負担が大きくなりすぎないよう、最も重要なパッケージに対しては別のチームが管理しています。そのようなケースとして、C ライブラリと debian-glibc@lists.debian.org、C コンパイラと debian-gcc@lists.debian.org、Xorg と debian-x@lists.debian.org (このグループは X Strike Force としても知られています) の関係が挙げられます。