第3章 Debian 開発者の責務

目次

3.1. パッケージメンテナの責務
3.1.1. 次期安定版 (stable) リリースへの作業
3.1.2. 安定版 (stable) にあるパッケージをメンテナンスする
3.1.3. リリースクリティカルバグに対処する
3.1.4. 開発元/上流 (upstream) の開発者との調整
3.2. 管理者的な責務
3.2.1. あなたの Debian に関する情報をメンテナンスする
3.2.2. 公開鍵をメンテナンスする
3.2.3. 投票をする
3.2.4. 優雅に休暇を取る
3.2.5. 脱退について
3.2.6. リタイア後に再加入する

As a package maintainer, you're supposed to provide high-quality packages that are well integrated into the system and that adhere to the Debian Policy.

Providing high-quality packages in unstable is not enough; most users will only benefit from your packages when they are released as part of the next stable release. You are thus expected to collaborate with the release team to ensure your packages get included.

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

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

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

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

A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs that are not specific to Debian to our bug tracking system. These bug reports should be forwarded to the upstream developers so that they can be fixed in a future upstream release. Usually it is best if you can do this, but alternatively, you may ask the bug submitter to do it.

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

In cases where a bug report is forwarded upstream, it may be helpful to remember that the bts-link service can help with synchronizing states between the upstream bug tracker and the Debian one.

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

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

Debian のような大きさのプロジェクトは、あらゆる事を追いかけられる管理者用のインフラに依っています。プロジェクトメンバーとして、あらゆる物事が滞り無く進むように、あなたにはいくつかの義務があります。

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

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

Be very careful with your private keys. Do not place them on any public servers or multiuser machines, such as the Debian servers (see 「Debian のマシン群」). Back your keys up; keep a copy offline. Read the documentation that comes with your software; read the PGP FAQ and OpenPGP Best Practices.

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

公開鍵に対して、署名したり身元情報を追加したりなどしたら、鍵を keyring.debian.org の鍵サーバに送付することで Debian キーリングを更新できます。更新は少なくとも月に1度は debian-keyring パッケージメンテナによって実施されます。

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

同様に鍵の取り出し方について 「Registering as a Debian member」 で説明されています。

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

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

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

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

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

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

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

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

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

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

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

  1. 「パッケージを放棄する」 の記述に従って、全てのパッケージを放棄 (orphan) してください。

  2. GPG でサインされたメールを に投げてください。

  3. Notify the Debian key ring maintainers that you are leaving by opening a ticket in Debian RT by sending a mail to with the words "Debian RT" somewhere in the subject line (case doesn't matter).

  4. @debian.org メールアドレスの alias (例: press@debian.org) 経由でメールを受け取っていて削除したい場合、Debian システム管理者に対する RT チケットをオープンしてください。チケットをオープンするには、削除したい alias のアドレスから、 宛でサブジェクトのどこかに "Debian RT" と入れて送信します。

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

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

  • に連絡を取ります

  • 短縮された NM プロセスを通過します (リタイアした開発者が P&P および T&S の肝心な部分を覚えているのを確認するためです)。

  • アカウントに紐付けられた GPG 鍵を今でも管理していることを証明する、あるいは新しい GPG 鍵について、他の開発者から少なくとも 2 つの署名を受けることにより身分証明を行う。

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



[2] これは、休暇のメッセージを読みたくない人がメッセージを簡単に振り分け可能にするためです。