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

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

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

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

重要度を「wishlist」にして debian-policy パッケージにバグ報告を投稿することにより、誰でも Debian ポリシーに修正を提案できます。その後の手続きは /usr/share/doc/debian-policy/Process.html に書かれています。すなわち Debian ポリシーに新しいルールを作ることで投稿された問題を解決しなければいけないと認知された場合、合意に達して提案が公表されるまで debian-policy@lists.debian.org メーリングリストで議論されます。この後、誰かが要求された修正に対する草稿を書いて、承認を求めるために (パッチレビューの形で) 投稿します。2 人の他の開発者が、提案された修正は以前の議論で達せられた合意を反映したものであると承認したら (彼らが修正に「賛同」したら) すぐに、debian-policy パッケージメンテナの 1 人がこの提案を公式文書に反映させます。これらの手続きのどれか 1 つでも失敗したら、メンテナは提案を却下に分類して、バグを閉じます。

各パッケージに関する文書は /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 サブディレクトリで、ここには設定ファイルの例が含まれています。

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

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

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

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

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

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 を参照してください。

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

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

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

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

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

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

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

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

reportbug ツールは Debian パッケージに対するバグ報告を簡単に送信できるようにするためのものです。reportbug は問題になっているバグが既に報告されていないかを確認する際に役立ち、同じバグがシステムに報告されることを防いでいます。reportbug はユーザに可能な限り正確な報告をさせるために、重要度の定義を表示します (開発者は後から必要になればいつでもレベルを微調整することが可能です)。reportbug はバグ報告を適切な書式に整形する機能と内容をユーザが編集できる機能を提供しているので、reportbug を使えばユーザはバグ報告の正確な書式を知らなくても完全なバグ報告を書くことが可能です。その後、この報告は電子メールサーバを経由して送信されます (デフォルトでは Debian が運営するリモートサーバを使いますが、reportbug はローカルサーバを使うことも可能です)。

reportbug はどちらかと言えば開発版で使用すべきツールです。なぜなら、報告されたバグは開発版で修正されるからです。実際のところ、Debian の安定版では、セキュリティ更新やその他の重要な更新 (たとえば、あるパッケージが全く動かない) などのごく少数の例外を除いて、修正を歓迎しません。そんなわけで Debian パッケージの深刻でないバグの修正は次の安定版まで待たなければいけません。