3. Debian 開発者の責務

3.1. パッケージメンテナの責務

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.

3.1.1. 次期安定版 (stable) リリースへの作業

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) を判別できない場合は、リリースチームが先の移行に関する現在の障害に関する情報を与えてくれることでしょう。

3.1.2. 安定版 (stable) にあるパッケージをメンテナンスする

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

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

3.1.3. リリースクリティカルバグに対処する

大抵の場合、パッケージに対するバグ報告については バグの取扱いで記述されているように対応する必要があります。しかしながら、注意を必要とする特別なカテゴリのバグがあります—リリースクリティカルバグ (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 チームが関わることもあり、その場合はパッケージが放棄されます (活動的でない、あるいは連絡が取れないメンテナに対応する 参照)。

3.1.4. 開発元/上流 (upstream) の開発者との調整

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 コミュニティに対する社会的なコストは、そのソフトウェアがもたらすであろう利益に見合わない場合があります。

3.2. 管理者的な責務

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

3.2.1. あなたの Debian に関する情報をメンテナンスする

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

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

3.2.2. 公開鍵をメンテナンスする

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 メンテナは新しい鍵を拒否することがあります。詳細は https://keyring.debian.org/replacing_keys.html で確認できます。

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

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

3.2.3. 投票をする

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

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

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

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

3.2.4. 優雅に休暇を取る

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

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

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

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

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

3.2.5. 脱退について

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

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

  • 一緒にメンテナンスしているパッケージやチームとしてメンテナンスしているパッケージのUploaders:フィールドから自身を削除してください。

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

  • Please remember to also retire from teams, e.g. remove yourself from team wiki pages or salsa groups.

  • Use the link https://nm.debian.org/process/emeritus to log in to nm.debian.org, request emeritus status and write a goodbye message that will be automatically posted on debian-private.

    Authentication to the NM site requires an SSO browser certificate. You can generate them on https://sso.debian.org.

    In the case you run into problems opening the retirement process yourself, contact NM front desk using nm@debian.org

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

3.2.6. リタイア後に再加入する

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

  • Get access to an salsa account (either by remembering the credentials for your old guest account or by requesting a new one as described at SSO Debian wiki page.

  • Mail nm@debian.org for further instructions.

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

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