第3章 Debian 開発者の責務

高品質のパッケージを不安定版 (unstable) へ提供するだけでは十分ではありません。多くのユーザは、パッケージが次期安定版 (stable) の一部としてリリースされた時にのみ、その恩恵を受けるからです。ですから、パッケージが次期の安定版 (stable) に含まれるようにリリースチームと上手く共同で作業することが期待されています。

より具体的には、パッケージがテスト版 (testing) に移行しているかどうかを見守る必要があります (「テスト版ディストリビューション」 参照) 。テスト期間後に移行が行われない場合は、その理由を分析してこれを修正する必要があります。(リリースクリティカルバグや、いくつかのアーキテクチャでビルドに失敗する場合) あなたのパッケージを修正するのが必要な場合もありますし、依存関係でパッケージが絡まっている状態からの移行を完了する手助けとして、他のパッケージを更新 (あるいは修正、またはテスト版 (testing) からの削除) が必要な事を意味する場合もあります。障害となる理由 (blocker) を判別できない場合は、リリースチームが先の移行に関する現在の障害に関する情報を与えてくれることでしょう。

パッケージメンテナの作業の大半は、パッケージの更新されたバージョンを不安定版 (unstable) へ放り込むことですが、現状の安定版 (stable) リリースのパッケージの面倒をみることも伴っています。

安定版 (stable) への変更は推奨されてはいませんが、可能です。セキュリティ問題が報告された時はいつでも、セキュリティチームと修正版を提供するように協力する必要があります (「セキュリティ関連バグの取扱い」 参照)。important (あるいはそれ以上) な重要度のバグが安定版 (stable) のバージョンのパッケージに報告されたら、対象となる修正の提供を検討する必要があります。安定版 (stable) リリースマネージャに、そのような更新を受け入れられるかどうかを尋ね、それから安定版 (stable) のアップロードを準備するなどができます (「特別な例: 安定版 (stable) と 旧安定版 (oldstable) ディストリビューションへアップロードする」 参照)。

大抵の場合、パッケージに対するバグ報告については 「バグの取扱い」で記述されているように対応する必要があります。しかしながら、注意を必要とする特別なカテゴリのバグがあります—リリースクリティカルバグ (RC bug) と呼ばれるものです。critical、grave、serious の重要度が付けられている全てのバグ報告によって、そのパッケージは次の安定版 (stable) リリースに含めるのには適切ではないとされます。そのため、(テスト版 (testing) にあるパッケージに影響する場合に) Debian のリリースを遅らせたり、(不安定版 (unstable) にあるパッケージにのみ影響する場合に) テスト版 (testing) への移行をブロックする可能性があります。最悪の場合は、パッケージの削除を招きます。これが RC バグを可能な限り素早く修正する必要がある理由です。

もし、何らかの理由で 2 週間以内に RC バグを修正できない場合 (例えば時間の制約上、あるいは修正が難しいなど)、明示的にバグ報告にそれを述べて、他のボランティアを招き入れて参加してもらうためにバグに help タグを打ってください。大量のパッケージがテスト版 (testing) へ移行するのを妨げることがあるので、RC バグは頻繁に Non-Maintainer Upload の対象になることに注意してください (「Non-Maintainer Upload (NMU)」 参照)。

RC バグへの関心の無さは、しばしば QA チームによって、メンテナが正しくパッケージを放棄せずに消えてしまったサインとして判断されます。MIA チームが関わることもあり、その場合はパッケージが放棄されます (「活動的でない、あるいは連絡が取れないメンテナに対応する」 参照)。

Debian メンテナとしての仕事のうちで重要な位置を占めるのは、開発元/上流 (upstream) の開発者との窓口であることです。Debian ユーザは、時折バグ報告システムに Debian 特有ではないバグを報告する事があります。Debian メンテナは、いつか上流のリリースで修正できるようにする為、このようなバグ報告を上流の開発者に転送しなくてはなりません。

Debian 固有ではないバグの修正はあなたの義務ではないとはいえ、できるなら遠慮なく修正してください。そのような修正を行った際は、上流の開発者にも送ってください。時折 Debian ユーザ／開発者が上流のバグを修正するパッチを送ってくる事があります。その場合は、あなたはパッチを確認して上流へ転送する必要があります。

ポリシーに準拠したパッケージをビルドするために上流のソースに手を入れる必要がある場合、以降の上流でのリリースにおいて手を入れなくても済むために、ここで含まれる修正を上流の開発者にとって良い形で提案する必要があります。必要な変更が何であれ、上流のソースからフォークしないように常に試みてください。

開発元の開発者らが Debian やフリーソフトウェアコミュニティに対して敵対的である、あるいは敵対的になってきているのを見つけた場合は、ソフトウェアを Debian に含める必要があるかを再考しなければならなくなるでしょう。時折 Debian コミュニティに対する社会的なコストは、そのソフトウェアがもたらすであろう利益に見合わない場合があります。

Debian 開発者に関する情報が含まれた LDAP データベースが https://db.debian.org/ にあります。ここに情報を入力して、情報に変更があった際に更新する必要があります。特に、あなたの debian.org アドレス宛メールの転送先アドレスが常に最新になっているのを必ず確認してください。debian-private の購読をここで設定した場合、そのメールを受け取るアドレスについても同様です。

データベースについての詳細は 「開発者データベース」 を参照してください。

秘密鍵の取扱いには十二分に注意してください。Debian サーバ (「Debian のマシン群」 参照) のような公開サーバや複数のユーザがいるマシンには置かないようにしてください。鍵をバックアップして、コピーはオフラインな場所に置きましょう。ソフトウェアの使い方については付属のドキュメントを参照してください。PGP FAQ を読みましょう。

鍵が盗難に対してだけではなく、紛失についても安全であることを保証する必要があります。失効証明書 (revocation certificate) を生成してコピーを作って下さい (紙にも出力しておくのがベストです)。これは鍵を紛失した場合に必要になります。

公開鍵に対して、署名したり身元情報を追加したりなどしたら、鍵を keyring.debian.org の鍵サーバに送付することで Debian key ring を更新できます。

まったく新しい鍵を追加したりあるいは古い鍵を削除したりする必要がある時は、別の開発者に署名された新しい鍵が必要になります。以前の鍵が侵害されたり利用不可能になった場合には、失効証明書 (revocation certificate) も追加する必要があります。新しい鍵が本当に必要な理由が見当たらない場合は、Keyring メンテナは新しい鍵を拒否することがあります。詳細は http://keyring.debian.org/replacing_keys.html で確認できます。

同様に鍵の取り出し方について 「Debian 開発者への登録を行う」 で説明されています。

Debian での鍵のメンテナンスについて、より突っ込んだ議論を debian-keyring パッケージ中のドキュメントで知ることができます。

Debian は本来の意味での民主主義ではありませんが、我々はリーダーの選出や一般投票の承認において民主主義的なプロセスを利用しています。これらの手続きについては、Debian 憲章で規程されています。

毎年のリーダー選挙以外には、投票は定期的には実施されず、軽々しく提案されるものではありません。提案はそれぞれ <debian-vote@lists.debian.org> メーリングリストでまず議論され、プロジェクトの書記担当者が投票手順を開始する前に複数のエンドースメントを必要とします。

書記担当者が <debian-devel-announce@lists.debian.org> 上で複数回投票の呼びかけを行うので、投票前の議論を追いかける必要はありません (全開発者がこのメーリングリストを購読することが求められています)。民主主義は、人々が投票に参加しないと正常に機能しません。これが我々が全ての開発者に投票を勧める理由です。投票は GPG によって署名／暗号化されたメールによって行われます。

(過去と現在の) 全ての提案リストが Debian 投票情報ページで閲覧できます。提案について、どの様に起案され、支持され、投票が行われたのかという関連情報の確認が可能になっています。

予定していた休暇にせよ、それとも単に他の作業で忙しいにせよ、開発者が不在になることがあるのはごく普通のことです。注意すべき重要な点は、他の開発者達があなたが休暇中であるのを知る必要があることと、あなたのパッケージについて問題が起こった場合やプロジェクト内での責務を果たすのに問題が生じたという様な場合は、必要なことを彼らが何であってもできるようにすることです。

通常、これはあなたが休暇中にあなたのパッケージが大きな問題 (リリースクリティカルバグやセキュリティ更新など) となっている場合に、他の開発者に対して NMU (「Non-Maintainer Upload (NMU)」 参照) を許可することを意味しています。大抵の場合はそれほど致命的なことはおきませんが、他の開発者に対してあなたが作業できない状態であることを知らせるのは重要です。

他の開発者に通知するために行わなければならないことが 2 つあります。まず、<debian-private@lists.debian.org> にサブジェクトの先頭に [VAC] と付けたメールを送り^[2]、いつまで休暇なのかを示しておきます。何か問題が起きた際への特別な指示を書いておくこともできます。

他に行うべき事は Debian developers' LDAP database 上 であなたを vacation とマークする事です (この情報は Debian 開発者のみがアクセスできます)。休暇から戻った時には vacation フラグを削除するのを忘れないように!

理想的には、休暇にあわせて GPG coordination pages に登録して、誰かサインを希望している人がいるかどうかをチェックします。開発者がまだ誰もいないけれども応募に興味を持っている人がいるようなエキゾチックな場所に行く場合、これは特に重要です。

Debian プロジェクトから去るのを決めた場合は、以下の手順に従ってください:

上記のプロセスに従うのは重要です。何故なら活動を停止している開発者を探してパッケージを放棄するのは、非常に時間と手間がかかることだからです。

リタイアした開発者のアカウントは、「脱退について」 の手続きが開始された際に「emeritus」であるとマークされ、それ以外の場合は「disabled」となります。「emeritus」アカウントになっているリタイアした開発者は、以下のようにすればアカウントを再度有効にできます:

リタイアした開発者で「disabled」アカウントの人は、NM をもう一度通り抜ける必要があります。