目次
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 メンテナとしての仕事のうち重要な位置を占めるのは、上流 (upstream) の開発者との窓口であることです。Debian ユーザは、時折バグ報告システムに Debian 特有ではないバグを報告する事があります。Debian メンテナは、いつか上流のリリースで修正できるようにする為、このようなバグ報告を上流の開発者に転送しなくてはなりません。
Debian 固有ではないバグの修正はあなたの義務ではないとはいえ、できるなら遠慮なく修正してください。そのような修正を行った際は、上流の開発者にも送ってください。時折 Debian ユーザ/開発者が上流のバグを修正するパッチを送ってくる事があります。その場合は、あなたはパッチを確認して上流へ転送する必要があります。
ポリシーに準拠したパッケージをビルドするために上流のソースに手を入れる必要がある場合、以降の上流でのリリースにおいて手を入れなくても済むために、ここで含まれる修正を上流の開発者にとって良い形で提案する必要があります。必要な変更が何であれ、上流のソースからフォークしないように常に試みてください。
開発元の開発者らが Debian やフリーソフトウェアコミュニティに対して敵対的である、あるいは敵対的になってきているのを見つけた場合は、ソフトウェアを Debian に含める必要があるかを再考しなければならなくなるでしょう。時折 Debian コミュニティに対する社会的なコストは、そのソフトウェアがもたらすであろう利益に見合わない場合があります。
大抵の場合、パッケージに対するバグ報告については 「バグの取扱い」で記述されているように対応する必要があります。しかしながら、注意を必要とする特別なカテゴリのバグがあります—リリースクリティカルバグ
(RC bug)
と呼ばれるものです。critical
、grave
、serious
の重要度が付けられている全てのバグ報告は、Debian
の次期安定版リリースからパッケージに含めるかどうかについての影響を持つと見なされています。これらのバグは Debian
のリリースを遅らせたり、フリーズ時にパッケージ削除の調整に使われるなどされることがあります。これが、これらのバグを可能な限り素早く修正する必要がある理由です。
品質保証
グループに所属している開発者はそのようなバグ全てを取扱い、何時でも可能な時に修正を試みます。どの様な理由であれ、2 週間の間でパッケージの RC
バグを修正出来なかったりする場合は品質保証 (QA) グループ <debian-qa@lists.debian.org>
にメールを送って協力を求めるか、困難な点を説明してどうやってそれを修正するつもりなのか、バグ報告に対してメールを送ってください。そうしない場合は、QA
グループのメンバーはあなたにコンタクトを試みた後で Non-Maintainer アップロード (「Non-Maintainer Upload (NMU)」 参照)
を行おうとします (BTS 上で最近の活動が見られない場合は、彼らは NMU を行う前にいつもの様には待とうとはしないでしょう)。
Debian プロジェクトから去るのを決めた場合は、以下の手順に従ってください:
「パッケージをみなしご化する」 の記述にしたがって、全てのパッケージをみなしご化 (orphan) してください。
何故プロジェクトを去るのかについて GPG でサインされたメールを <debian-private@lists.debian.org>
に投げてください。
'Debian RT' という単語 (大文字小文字は関係なし) がサブジェクトのどこかに入ったメールを <keyring@rt.debian.org>
に投げて
Debian RT でチケットをオープンして、あなたがプロジェクトを去るのを Debian key ring メンテナに知らせてください。