[draft-1] developers-reference 日本語訳 ch.3

[OHURA Makoto <Makoto.Ohura@xxxxxxxxxxxxxxxxx>]

  大浦です。

  第3章です。

----
<!--
    <chapt id="developer-duties">Debian Developer's Duties
-->
    <chapt id="developer-duties">Debian 開発者の務め

<!--
      <sect id="user-maint">Maintaining your Debian information
-->
      <sect id="user-maint">あなたの Debian における情報の管理する
	<p>
<!--
There's a LDAP database containing information about Debian developers at
<url id="&url-debian-db;">. You should enter your information there and
update it as it changes. Most notably, make sure that the address where your
debian.org email gets forwarded to is always up to date, as well as the
address where you get your debian-private subscription if you choose to
subscribe there.
-->
Debian の開発者に関する情報を含む LDAP のデータベースが
<url id="&url-debian-db;"> にあります。
あなたは、そこにあなたの情報を入力し、変更があった時には情報を
更新すべきです。
特に、debian-private に登録しているアドレスだけでなく、
あなたの debian.org のアドレスへのメールを転送しているアドレスを
いつも最新であることを確認して下さい。
	<p>
<!--
For more information about the database, please see <ref id="devel-db">.
-->
このデータベースに関する詳細は、<ref id="devel-db"> をご覧下さい。

<!--
      <sect id="key-maint">Maintaining your public key
-->
      <sect id="key-maint">あなたの公開鍵の管理する
	<p>
<!--
Be very careful with your private keys.  Do not place them on any
public servers or multiuser machines, such as the Debian servers
(see <ref id="server-machines">).  Back your keys up; keep a copy offline.
Read the documentation that comes with your software; read the <url
id="&url-pgp-faq;" name="PGP FAQ">.
-->
各自の秘密鍵の扱いについては十分に注意してください。
それを公開サーバや Debian のサーバ (<ref id="server-machines"> をご覧下さい。)
のようなマルチユーザのマシンに置いたりしてはいけません。
またそのバックアップを取り、その写しをオフラインで保持しておいてください。
さらに、お使いになるソフトウェアに付属する説明書や、
<url id="&url-pgp-faq;" name="PGP FAQ"> にも目を通してください。
	<p>
<!--
If you add signatures to your public key, or add user identities, you
can update the Debian key ring by sending your key to the key server at
<tt>&keyserver-host;</tt>.  If you need to add a completely new key,
or remove an old key, send mail to &email-debian-keyring;.  The same
key extraction routines discussed in <ref id="registering"> apply.
-->
あなたの公開鍵に署名を加えたり、ユーザ ID を加えたりした場合には
<tt>&keyserver-host;</tt> の鍵サーバ上へ公開鍵を送ることによって、
Debian の鍵の輪を更新することができます。
完全に新しい鍵を追加したり、古い鍵を削除したりする場合には、
&email-debian-keyring; に電子メールで送付する必要があります。
その鍵を取り出す方法については <ref id="registering">
で説明してあります。
	<p>
<!--
You can find a more in-depth discussion of Debian key maintenance in
the documentation of the <package>debian-keyring</package> package.
-->
Debian における鍵管理についてのより詳細な議論については、
<package>debian-keyring</package>
パッケージのドキュメントをご覧ください。

<!--
       <sect id="voting">Voting
-->
       <sect id="voting">投票する
	<p>
<!--
Even though Debian isn't really a democracy, we use a democratic
process to elect our leaders and to approve general resolutions.
These procedures are defined by the
<url id="&url-constitution;" name="Debian Constitution">.
-->
例え Debian が本当の民主主義的な団体ではないとしても、
私たちは、リーダを選び、一般的な決定を承認するために民主的なプロセスを
使います。
この手続きは <url id="&url-constitution;" name="Debian 憲章"> で
定義されています。
	<p>
<!--
Other than the yearly leader election, votes are not routinely held, and
they are not undertaken lightly. Each proposal is first discussed on
the &email-debian-vote; mailing list and it requires several endorsements
before the project secretary starts the voting procedure.
-->
毎年のリーダの選挙以外、投票は定期的に行われるのではありませんが、
軽く扱われるものでもありません。
それぞれの提案は、まず、&email-debian-vote; メーリングリストで議論されて、
プロジェクトの書記が投票の手続きを始める前に、いくつかの承認が必要になります。
	<p>
<!--
You don't have to track the pre-vote discussions, as the secretary will
issue several calls for votes on &email-debian-devel-announce; (and all
developers are expected to be subscribed to that list). Democracy doesn't
work well if people don't take part in the vote, which is why we encourage
all developers to vote. Voting is conducted via GPG-signed/encrypted emails
messages.
-->
書記が &email-debian-devel-announce; に何度か投票の呼掛けをだすので、
(さらに、すべての開発者はこのリストに登録していることになっているので、)
投票の前の議論を追跡する必要はありません。
民主主義は人々が投票に参加しなければ、うまく機能しません。
そのため、私たちは全ての開発者に投票するように勧めています。
投票は、GPG で署名され暗号化された電子メールで行われます。
	<p>
<!--
The list of all the proposals (past and current) is available on the
<url id="&url-vote;" name="Debian Voting Information"> page, along with
information on how to make, second and vote on proposals.
-->
(過去、及び、現在の)全ての提案は、
提案を提出し、それを支持し、それについて投票する方法と一緒に
<url id="&url-vote;" name="Debian 提案情報"> のページに、
記載されています。

<!--
      <sect id="inform-vacation">Going on vacation gracefully
-->
      <sect id="inform-vacation">優雅に休暇を取る
	<p>
<!--
It is common for developers to have periods of absence, whether those are
planned vacations or simply being buried in other work. The important thing
to notice is that the other developers need to know that you're on vacation
so that they can do whatever is needed if a problem occurs with your
packages or other duties in the project.
-->
休暇の計画であっても、単に他の仕事に没頭するだけであっても、
開発者が休みを取ることは普通のことです。
注意すべき重要なことは、あなたが休暇中なので、あなたのパッケージや
プロジェクトにおける他の務めに関して問題が起きた場合に、
他の人が何をしてもいい、ということを他の開発者に
伝えなければならないということです。
	<p>
<!--
Usually this means that other developers are allowed to NMU (see
<ref id="nmu">) your package if a big problem (release critical bugs,
security update, etc.) occurs while you're on vacation. Sometimes it's
nothing as critical as that, but it's still appropriate to let the others
know that you're unavailable.
-->
大抵、このことは、あなたが休暇中に大きな問題 (relese critical bug や
security update など) があった場合に、あなたのパッケージを NMU する
(<ref id="nmu"> をご覧下さい。) ことを他の開発者に許可することを意味します。
時には、それほど重要なことはないこともありますが、
それでも、他の人にあなたの手があいていないことを伝えることは
適切なことです。
	<p>
<!--
In order to inform the other developers, there's two things that you should do.
First send a mail to &email-debian-private; with "[VAC] " prepended to the
subject of your message<footnote>This is so that the message can be easily
filtered by people who don't want to read vacation notices.</footnote>
and state the period of time when you will be on vacation. You can also give
some special instructions on what to do if a problem occurs.
-->
他の開発者に知らせるために、あなたがすべきことが二つあります。
まず、&email-debian-private; にサブジェクトの最初に "[VAC] " と
書いたメールを送ります。
<footnote>これは、休暇に関するメールを読みたくない人が
用意にメールを振り分けることができるようにするためです。</footnote>
そして、休暇を取る期間を伝えます。
また、問題が起きた時にするべきことについて特別な指示を与えることもできます。
	<p>
<!--
The other thing to do is to mark yourself as "on vacation" in the
<qref id="devel-db">Debian developers' LDAP database</qref> (this
information is only accessible to Debian developers).
Don't forget to remove the "on vacation" flag when you come back!
-->
もう一つするべきことは、
<qref id="devel-db">Debian developers' LDAP database</qref> で
自分のところに "on vacation" と印を付けることです。
(この情報は Debian の開発者だけがアクセスすることができます。)
戻った時には、"on vacation" の印を外すことを忘れないでください。

<!--
      <sect id="upstream-coordination">Coordination with upstream developers
-->
      <sect id="upstream-coordination">上流の開発者との調整
	<p>
<!--
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
to the Bug Tracking System that are not specific to Debian.  You
must forward these bug reports to the upstream developers so that
they can be fixed in a future release.  It's not your job to fix
non-Debian specific bugs.  However, if you are able to do so, you are
encouraged to contribute to upstream development of the package by
providing a fix for the bug.  Debian users and developers will often
submit patches to fix upstream bugs, and you should evaluate and
forward these patches upstream.
-->
Debian メンテナとしての仕事の中で、上流の開発者と連絡を取り続けることは
大きな部分を占めています。
Debian のユーザは、時々、Debian 特有ではないバグをバグ追跡システムに
報告することがあります。
あなたは、将来のリリースで修正できるように、これらのバグの報告を
上流の開発者に送らなければなりません。
Debian 特有ではないバグを直すことはあなたの仕事ではありません。
でも、直せるのだったら、バグの修正を用意することによって
そのパッケージの上流の開発に貢献することをお勧めします。
Debian のユーザと開発者は、しばしば、上流のバグを修正するパッチを提出します。
そして、あなたは、そのパッチを評価し、上流に転送すべきです。
        <p>
<!--
If you need to modify the upstream sources in order to build a policy
compliant package, then you should propose a nice fix to the upstream
developers which can be included there, so that you won't have to
modify the sources of the next upstream version. Whatever changes you
need, always try not to fork from the upstream sources.
-->
ポリシーに合致したパッケージを構築するために上流のソースを
修正する必要がある場合、
次の上流のバージョンのソースを修正する必要がないように、
その修正を上流のソースに含めることができるような形で、
上流の開発者に良い修正を提案するべきです。
必要とする修正が何であれ、常に、上流のソースから分岐しないように
試みるべきです。

<!--
      <sect id="rc-bugs">Managing release-critical bugs
-->
      <sect id="rc-bugs">リリースクリティカルバグを処理する
        <p>
<!--
Generally you should deal with bug reports on your packages as described in
<ref id="bug-handling">. However, there's a special category of bugs that
you need to take care of &hyphen;&hyphen; the so-called release-critical bugs (RC bugs).
All bug reports that have severity <em>critical</em>, <em>grave</em> or
<em>serious</em> are considered to have an impact on whether the package can
be released in the next stable release of Debian.
Those bugs can delay the Debian release
and/or can justify the removal of a package at freeze time. That's why
these bugs need to be corrected as quickly as possible.
-->
一般的には、あなたのパッケージに対するバグリポートは、
<ref id="bug-handling"> に書かれているように扱うべきです。
しかし、大事に処理すべきバグ、いわゆる、
リリースクリティカルバグ (RC バグ) という特別なものがあります。
<em>critical</em>、もしくは、<em>grave</em>、<em>serious</em> という
serverity (重要度) を持っているバグリポートは、そのパッケージが
Debian の次の安定版リリースの中でリリースできるかどうかに影響を持っていると
考えられます。
これらのバグは、Debian のリリースを遅らせたり、freeze した時にパッケージを
削除する理由になったりもします。
そのためこれらのバグは、可能な限り早く修正される必要があります。
	<p>
<!--
Developers who are part of the <url id="&url-debian-qa;"
name="Quality Assurance"> group are following all such bugs, and trying
to help whenever possible. If, for any reason, you aren't able fix an
RC bug in a package of yours within 2 weeks, you should either ask for help
by sending a mail to the Quality Assurance (QA) group
&email-debian-qa;, or explain your difficulties and present a plan to fix
them by sending a mail to the bug report. Otherwise, people
from the QA group may want to do a Non-Maintainer Upload (see
<ref id="nmu">) after trying to contact you (they might not wait as long as
usual before they do their NMU if they have seen no recent activity from you
in the BTS).
-->
<url id="&url-debian-qa;" name="Quality Assurance"> のグループの
メンバーである開発者は、そのような全てのバグを追跡していますし、
可能な限りいつも、手助けしようとしています。
もし、何らかの理由で、2週間以内にあなたのパッケージの RC バグを
修正できないのでしたら、品質保証 (QA) グループ &email-debian-qa; に
メールを送って助けを請うか、バグリポートに対してメールを送って、
困難であることを説明し、修正する計画を提示します。
さもなくば、QA グループの人があなたに接触しようとした後に、
Non-Maintainer Upload (<ref id="nmu"> をご覧下さい。)しようとするでしょう。
(QA グループは、BTS での最近の活動が見られなかったら、NMU する前に
普段ほどは待たないでしょう。)

<!--
      <sect>Retiring
-->
      <sect>脱退する
	<p>
<!--
If you choose to leave the Debian project, you should make sure you do
the following steps:
-->
Debian プロジェクトから脱退を決めた場合は、
必ず以下の手続きを行なうべきです。
<enumlist>
	    <item>
<!--
Orphan all your packages, as described in <ref id="orphaning">.
-->
<ref id="orphaning"> の説明にしたがい、
自分のパッケージすべてをみなしご化する。
	    <item>
<!--
Send an email about why you are leaving the project to
&email-debian-private;.
-->
プロジェクト脱退の理由に関する電子メールを
&email-debian-private; に送る。
	    <item>
<!--
Notify the Debian key ring maintainers that you are leaving by
emailing to &email-debian-keyring;.
-->
&email-debian-keyring; 宛てに電子メールを送り、
Debian キーリング管理者にプロジェクト脱退を伝える。
</enumlist>

----
  大浦 真(OHURA Makoto): Makoto.Ohura@xxxxxxxxxxxxxxxxx(private)
                         ohura@xxxxxxxxxxxxx(LILO/Netfort)
                         mohura@xxxxxxxxxxxxxxxxxxxxxx(Kyoto Univ.)
  http://www.netfort.gr.jp/~ohura/