developers-reference 3.4.2 - en to ja translation catalogue (69 entries)

note: type: Content of: <chapter><title>
en: Beyond Packaging
ja: パッケージ化、そして…

note: type: Content of: <chapter><para>
en: Debian is about a lot more than just packaging software and maintaining those packages.  This chapter contains information about ways, often really critical ways, to contribute to Debian beyond simply creating and maintaining packages.
ja: Debian は、単にソフトウェアのパッケージを作ってメンテナンスをしているだけではありません。この章では、単にパッケージを作ってメンテナンスする以外で Debian へ協力・貢献するやり方、多くの場合とても重要となるやり方の情報を取り扱います。

note: type: Content of: <chapter><para>
en: As a volunteer organization, Debian relies on the discretion of its members in choosing what they want to work on and in choosing the most critical thing to spend their time on.
ja: ボランティア組織の例にたがわず、Debian の活動はメンバーが何をしたいのか、時間を割くのに最も重大だと思われることが何か、というメンバーの判断に依っています。

note: type: Content of: <chapter><section><title>
en: Bug reporting
ja: バグ報告

note: type: Content of: <chapter><section><para>
en: We encourage you to file bugs as you find them in Debian packages.  In fact, Debian developers are often the first line testers.  Finding and reporting bugs in other developers' packages improves the quality of Debian.
ja: 我々としては、Debian パッケージで見つけたバグを登録することを勧めています。実際のところ、大抵の場合は Debian 開発者が第一線でのテスト作業者となっています。他の開発者のパッケージで見つけたバグを報告することで Debian の品質が向上されています。

note: type: Content of: <chapter><section><para>
en: Read the <ulink url="&url-bts-report;">instructions for reporting bugs</ulink> in the Debian <ulink url="&url-bts;">bug tracking system</ulink>.
ja: Debian <ulink url="&url-bts;">バグ追跡システム (BTS)</ulink> の <ulink url="&url-bts-report;">バグ報告のやり方について (instructions for reporting bugs)</ulink> を参照してください。

note: type: Content of: <chapter><section><para>
en: Try to submit the bug from a normal user account at which you are likely to receive mail, so that people can reach you if they need further information about the bug.  Do not submit bugs as root.
ja: いつも使っているメールを受け取れるユーザアカウントからバグを送って見てください。そうすることで、開発者がそのバグに関するより詳細な情報を必要とする場合にあなたに尋ねることができます。root ユーザでバグを報告しないでください。

note: type: Content of: <chapter><section><para>
en: You can use a tool like <citerefentry> <refentrytitle>reportbug</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> to submit bugs.  It can automate and generally ease the process.
ja: バグを報告するには、<citerefentry> <refentrytitle>reportbug</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> の様なツールが使えます。これによって自動化を行って、かなり簡単な作業にできます。

note: type: Content of: <chapter><section><para>
en: Make sure the bug is not already filed against a package.  Each package has a bug list easily reachable at <literal>http://&bugs-host;/<replaceable>packagename</replaceable></literal> Utilities like <citerefentry> <refentrytitle>querybts</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> can also provide you with this information (and <command>reportbug</command> will usually invoke <command>querybts</command> before sending, too).
ja: パッケージに対して既にバグが報告されていないことを確認しておいてください。個々のパッケージに対するバグのリストは <literal>http://&bugs-host;/<replaceable>パッケージ名</replaceable></literal> にて簡単に確認できます。<citerefentry> <refentrytitle>querybts</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> のようなユーティリティもこの情報を入手できます (それから <command>reportbug</command> では大抵の場合は、バグを送信する前に <command>querybts</command> の実行もします)。

note: type: Content of: <chapter><section><para>
en: Try to direct your bugs to the proper location.  When for example your bug is about a package which overwrites files from another package, check the bug lists for <emphasis>both</emphasis> of those packages in order to avoid filing duplicate bug reports.
ja: 正しい所にバグを報告する様に心がけてください。例えばあるパッケージが他のパッケージのファイルを上書きしてしまうバグの場合ですが、バグ報告が重複して登録されるのを避けるため、これらのパッケージの<emphasis>両方</emphasis>のバグリストを確認してください。

note: type: Content of: <chapter><section><para>
en: For extra credit, you can go through other packages, merging bugs which are reported more than once, or tagging bugs `fixed' when they have already been fixed.  Note that when you are neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission from the maintainer).
ja: さらに言うと、他のパッケージについても、何度も報告されているバグをマージしたり既に修正されているバグに「fixed」タグをつけたりすることもできます。そのバグの報告者であったりパッケージメンテナではない場合は (メンテナから許可をもらっていなければ)、実際にバグをクローズしてはいけないことに注意してください。

note: type: Content of: <chapter><section><para>
en: From time to time you may want to check what has been going on with the bug reports that you submitted.  Take this opportunity to close those that you can't reproduce anymore.  To find out all the bugs you submitted, you just have to visit <literal>http://&bugs-host;/from:<replaceable>your-email-addr</replaceable></literal>.
ja: 時折、あなたが報告したバグ報告について何が起こっているのかをチェックしたくなることでしょう。これは、もう再現できないものをクローズするきっかけになります。報告した全てのバグ報告を確認するには、<literal>http://&bugs-host;/from:<replaceable>your-email-addr</replaceable></literal> を参照すればいいだけです。

note: type: Content of: <chapter><section><section><title>
en: Reporting lots of bugs at once (mass bug filing)
ja: 一度に大量のバグを報告するには (mass bug filing)

note: type: Content of: <chapter><section><section><para>
en: Reporting a great number of bugs for the same problem on a great number of different packages — i.e., more than 10 — is a deprecated practice.  Take all possible steps to avoid submitting bulk bugs at all.  For instance, if checking for the problem can be automated, add a new check to <systemitem role="package">lintian</systemitem> so that an error or warning is emitted.
ja: 大量の異なるパッケージに対して、同じ問題についての非常に多くのバグ (例えば 10 個以上) を報告するのは、推奨されていないやり方です。不要なバグ報告を避けるため、可能な限りの手続きを踏むようにしましょう。例えば、問題の確認を自動化できる場合は <systemitem role="package">lintian</systemitem> に新しくチェック項目を追加すれば、エラーや警告が明確になります。

note: type: Content of: <chapter><section><section><para>
en: If you report more than 10 bugs on the same topic at once, it is recommended that you send a message to &email-debian-devel; describing your intention before submitting the report, and mentioning the fact in the subject of your mail.  This will allow other developers to verify that the bug is a real problem.  In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously.
ja: 同じ問題について一度に 10 個以上のバグを報告する場合は、バグの投稿をする前に &email-debian-devel; へ送ることをお勧めします。バグ報告を送る前に注意点を記述し、メールのサブジェクトに事実を挙げておきます。これで他の開発者がそのバグが本当に問題であるかどうかを確認できるようになります。さらに、これによって複数のメンテナが平行して同じバグ報告を登録するのを防止できるようになります。

note: type: Content of: <chapter><section><section><para>
en: Please use the programs <command>dd-list</command> and if appropriate <command>whodepends</command> (from the package <systemitem role="package">devscripts</systemitem>) to generate a list of all affected packages, and include the output in your mail to &email-debian-devel;.
ja: <command>dd-list</command> プログラムを利用することと、明確になっているのであれば影響を受けるパッケージのリストを (<systemitem role="package">devscripts</systemitem> パッケージの) <command>whodepends</command> を使って出力して、&email-debian-devel; へのメールに含めて下さい。

note: type: Content of: <chapter><section><section><para>
en: Note that when sending lots of bugs on the same subject, you should send the bug report to <email>maintonly@&bugs-host;</email> so that the bug report is not forwarded to the bug distribution mailing list.
ja: 同じサブジェクトで大量のバグを送信する際の注意として、バグ報告がバグ情報用メーリングリストへ転送されないように　<email>maintonly@&bugs-host;</email> へバグ報告を送るべきである、ということです。

note: type: Content of: <chapter><section><section><section><title>
en: Usertags
ja: Usertag

note: type: Content of: <chapter><section><section><section><para>
en: You may wish to use BTS usertags when submitting bugs across a number of packages. Usertags are similar to normal tags such as 'patch' and 'wishlist' but differ in that they are user-defined and occupy a namespace that is unique to a particular user. This allows multiple sets of developers to 'usertag' the same bug in different ways without conflicting.
ja: 多数のパッケージに対するバグを登録する際に BTS の usertag を使いたくなるかもしれません。usertag は 'patch' や 'wishlist' のような通常のタグに似ていますが、ユーザが定義する事と特定のユーザに対して一意な名前空間を占めるという点で違っています。これによって、同じバグについて衝突する事無しに、開発者がそれぞれ別のやり方で複数の設定ができるようになります。

note: type: Content of: <chapter><section><section><section><para>
en: To add usertags when filing bugs, specify the <literal>User</literal> and <literal>Usertags</literal> pseudo-headers:
ja: バグを登録する際に usertag を追加するには、擬似ヘッダ (pseudo-header) <literal>User</literal> と <literal>Usertags</literal> を指定します。

note: type: Content of: <chapter><section><section><section><screen>
en: To: submit@bugs.debian.org
    Subject: <replaceable>title-of-bug</replaceable>
    
    Package: <replaceable>pkgname</replaceable>
    <replaceable>[ ... ]</replaceable>
    User: <replaceable>email-addr</replaceable>
    Usertags: <replaceable>tag-name [ tag-name ... ]</replaceable>
    
    <replaceable>description-of-bug ...</replaceable>
ja: To: submit@bugs.debian.org
    Subject: <replaceable>バグタイトル</replaceable>
    
    Package: <replaceable>パッケージ名</replaceable>
    <replaceable>[ ... ]</replaceable>
    User: <replaceable>メールアドレス</replaceable>
    Usertags: <replaceable>タグ名 [ タグ名 ... ]</replaceable>
    
    <replaceable>バグの説明 ...</replaceable>

note: type: Content of: <chapter><section><section><section><para>
en: Note that tags are seperated by spaces and cannot contain underscores. If you are filing bugs for a particular group or team it is recommended that you set the <literal>User</literal> to an appropriate mailing list after describing your intention there.
ja: タグは空白で区切られ、アンダースコア (_) を含められないのに注意してください。特定のグループやチームについてのバグを登録する場合は、適切なメーリングリストで注意を促した上で <literal>User</literal> をそのメーリングリストに設定するのをお勧めします。

note: type: Content of: <chapter><section><section><section><para>
en: To view bugs tagged with a specific usertag, visit <literal>http://&bugs-host;/cgi-bin/pkgreport.cgi?users=<replaceable>email-addr</replaceable>&amp;tag=<replaceable>tag-name</replaceable></literal>.
ja: 特定の usertag でバグを参照する場合は <literal>http://&bugs-host;/cgi-bin/pkgreport.cgi?users=<replaceable>メールアドレス</replaceable>&amp;tag=<replaceable>タグ名</replaceable></literal> を指定してください。

note: type: Content of: <chapter><section><title>
en: Quality Assurance effort
ja: 品質維持の努力

note: type: Content of: <chapter><section><section><title>
en: Daily work
ja: 日々の作業

note: type: Content of: <chapter><section><section><para>
en: Even though there is a dedicated group of people for Quality Assurance, QA duties are not reserved solely for them.  You can participate in this effort by keeping your packages as bug-free as possible, and as lintian-clean (see <xref linkend="lintian"/>) as possible.  If you do not find that possible, then you should consider orphaning some of your packages (see <xref linkend="orphaning"/>).  Alternatively, you may ask the help of other people in order to catch up with the backlog of bugs that you have (you can ask for help on &email-debian-qa; or &email-debian-devel;).  At the same time, you can look for co-maintainers (see <xref linkend="collaborative-maint"/>).
ja: 品質保証に割り当てられたグループの人々がいたとしても、QA 作業は彼らのみに課せられるものではありません。あなたもパッケージを可能な限りバグが無いように保ち、できるだけ lintian clean な状態 (<xref linkend="lintian"/> を参照) にすることで参加することができるのです。それが可能ではないように思えるなら、パッケージをいくつか「みなしご化 (orphan)」してください (<xref linkend="orphaning"/> 参照)。または、溜まったバグ処理に追いつくため、他の人々に助力を願い出ることも可能です (&email-debian-qa; や &email-debian-devel; で助けを求めることができます)。同時に共同メンテナ (co-maintainer) を探すことも可能です (<xref linkend="collaborative-maint"/> を参照してください)。

note: type: Content of: <chapter><section><section><title>
en: Bug squashing parties
ja: バグ潰しパーティ (BSP)

note: type: Content of: <chapter><section><section><para>
en: From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible.  They are announced on &email-debian-devel-announce; and the announcement explains which area will be the focus of the party: usually they focus on release critical bugs but it may happen that they decide to help finish a major upgrade (like a new <command>perl</command> version which requires recompilation of all the binary modules).
ja: 時折、QA グループは可能な限りの問題を無くすためにバグ潰しパーティ (BSP) を開催しています。開催案内は &email-debian-devel-announce; で行われ、パーティがどの部分に集中してやるのかが告知されます。大抵はリリースクリティカルバグ (RC) への対応に当てられますが、大きなアップグレード (新しい <command>perl</command> バージョンでの全バイナリモジュールを再コンパイルのような) を完了する手助けのために開かれることもあります。

note: type: Content of: <chapter><section><section><para>
en: The rules for non-maintainer uploads differ during the parties because the announcement of the party is considered prior notice for NMU.  If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect from the party.  If you don't want an NMU, or if you're only interested in a patch, or if you will deal yourself with the bug, please explain that in the BTS.
ja: メンテナ以外によるアップロード (non-maintainer upload) のルールはパーティの開催中とそれ以外で違います。これは、パーティのアナウンスは NMU の予告であると考えられているためです。パーティによって影響を受けるパッケージを持っている場合 (例えばリリースクリティカルバグを持っている場合) は、それぞれ対応するバグについて現状説明とこのパーティでどの様なことを期待しているのかを説明しないといけません。NMU を望まない、パッチでの対応にのみ興味がある、あるいは自分自身で対処をする予定の場合は、BTS で説明をしてください。

note: type: Content of: <chapter><section><section><para>
en: People participating in the party have special rules for NMU, they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least.  All other NMU rules apply as usually; they should send the patch of the NMU to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed).  They should also respect any particular wishes of the maintainer.
ja: パーティに参加している人には NMU についての特別ルールが割り当てられます。NMU について、少なくとも 3 日遅延してアップロードを行う場合 (DELAYED/3-day キューなどへのアップロードの場合) は予告無しで NMU できるのです。他の NMU ルールは全て通常通りに適用されます - NMU のパッチを BTS に送付する必要があります (修正されていないバグのいずれかを NMU で修正する、あるいは新たなバグにパッチを送り、fixed とタグを付けるなど)。それから、作業者は各メンテナの要望に沿う必要があります。

note: type: Content of: <chapter><section><section><para>
en: If you don't feel confident about doing an NMU, just send a patch to the BTS.  It's far better than a broken NMU.
ja: NMU をする自信が無い場合は、BTS へパッチを投げるだけにしてください。NMU でパッケージを壊してしまうより、遥かに良いことです。

note: type: Content of: <chapter><section><title>
en: Contacting other maintainers
ja: 他のメンテナに連絡を取る

note: type: Content of: <chapter><section><para>
en: During your lifetime within Debian, you will have to contact other maintainers for various reasons.  You may want to discuss a new way of cooperating between a set of related packages, or you may simply remind someone that a new upstream version is available and that you need it.
ja: Debian と共に過ごす間、様々な理由で他のメンテナに連絡を取りたくなることでしょう。関連パッケージ間での共同作業の新たなやり方について協議したい場合や、開発元で自分が使いたい新しいバージョンが利用可能になっていることを単に知らせたい場合などです。

note: type: Content of: <chapter><section><para>
en: Looking up the email address of the maintainer for the package can be distracting.  Fortunately, there is a simple email alias, <literal><replaceable>package</replaceable>@&packages-host;</literal>, which provides a way to email the maintainer, whatever their individual email address (or addresses)  may be.  Replace <replaceable>package</replaceable> with the name of a source or a binary package.
ja: パッケージメンテナのメールアドレスを探しだすのは骨が折れます。幸いな事に、<literal><replaceable>パッケージ名</replaceable>@&packages-host;</literal> というシンプルなメールのエイリアスがあり、メンテナらの個人アドレスが何であれメンテナへメールを届ける手段となっています。<replaceable>パッケージ名</replaceable> はパッケージのソース名かバイナリパッケージ名に置き換えてください。

note: type: Content of: <chapter><section><para>
en: You may also be interested in contacting the persons who are subscribed to a given source package via <xref linkend="pkg-tracking-system"/>.  You can do so by using the <literal><replaceable>package</replaceable>@&pts-host;</literal> email address.
ja: <xref linkend="pkg-tracking-system"/> 経由でソースパッケージの購読を行っている人に連絡を取りたくなるかもしれません。その場合は <literal><replaceable>パッケージ名</replaceable>@&pts-host;</literal> メールアドレスが使えます。

note: type: Content of: <chapter><section><title>
en: Dealing with inactive and/or unreachable maintainers
ja: 活動的でない、あるいは連絡が取れないメンテナに対応する

note: type: Content of: <chapter><section><para>
en: If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages.  It is possible that they are not active any more, but haven't registered out of the system, so to speak.  On the other hand, it is also possible that they just need a reminder.
ja: パッケージがメンテナンスされていないと気づいた場合、メンテナが活動的でパッケージの作業を続けるかどうかを確認する必要があります。もはや活動的な状態ではない可能性もありますが、言わばシステムに登録していなかったという可能性もあります。あるいは、単に確認が必要なだけという可能性もあります。

note: type: Content of: <chapter><section><para>
en: There is a simple system (the MIA database) in which information about maintainers who are deemed Missing In Action is recorded.  When a member of the QA group contacts an inactive maintainer or finds more information about one, this is recorded in the MIA database.  This system is available in <filename>/org/qa.debian.org/mia</filename> on the host <literal>qa.debian.org</literal>, and can be queried with the <command>mia-query</command> tool.  Use <command>mia-query --help</command> to see how to query the database.  If you find that no information has been recorded about an inactive maintainer yet, or that you can add more information, you should generally proceed as follows.
ja: Missing In Action (行方不明) だと考えられているメンテナについての情報が記録されるシンプルなシステム (MIA データベース) があります。品質保証グループ (QA グループ) のメンバーが活動的ではないメンテナに連絡を取った場合や、そのメンテナについて新たな情報がもたらされた場合、その記録が MIA データベースに残されます。このシステムは <literal>qa.debian.org</literal> ホスト上の <filename>/org/qa.debian.org/mia</filename> で利用可能になっており、<command>mia-query</command> ツールで検索ができます。どうやってデータベースを検索するのかについては <command>mia-query --help</command> と入力してください。

note: type: Content of: <chapter><section><para>
en: The first step is to politely contact the maintainer, and wait a reasonable time for a response.  It is quite hard to define reasonable time, but it is important to take into account that real life is sometimes very hectic.  One way to handle this would be to send a reminder after two weeks.
ja: 最初の一歩はメンテナに丁寧にコンタクトを取り、応答するのに充分な時間待つことです。充分な時間というのを定義するのは非常に困難ですが、実生活では時折非常に多忙になるのを考慮に入れると重要なことです。一つのやり方としては、リマインダーを二週間後に送るという方法があります。

note: type: Content of: <chapter><section><para>
en: If the maintainer doesn't reply within four weeks (a month), one can assume that a response will probably not happen.  If that happens, you should investigate further, and try to gather as much useful information about the maintainer in question as possible.  This includes:
ja: メンテナが４週間 (１ヶ月）応答をしない場合、おそらく反応がないと判断できます。この様な場合はより詳細に確認し、可能な限り問題となっているメンテナに関する有用な情報をかき集める必要があります。これには以下のようなものが含まれています。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: The <literal>echelon</literal> information available through the <ulink url="&url-debian-db;">developers' LDAP database</ulink>, which indicates when the developer last posted to a Debian mailing list.  (This includes mails about uploads distributed via the &email-debian-devel-changes; list.)  Also, remember to check whether the maintainer is marked as on vacation in the database.
ja: <ulink url="&url-debian-db;">開発者 LDAP データベース</ulink> を通じて得られる <literal>echelon</literal> 情報は、開発者が最後に Debian メーリングリストに投稿したはいつなのかを示します (これには &email-debian-devel-changes; での配布物のアップロードのメールも含まれます)。また、データベースでメンテナが休暇中かどうかも確認してください

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: The number of packages this maintainer is responsible for, and the condition of those packages.  In particular, are there any RC bugs that have been open for ages? Furthermore, how many bugs are there in general? Another important piece of information is whether the packages have been NMUed, and if so, by whom.
ja: このメンテナが対応しているパッケージ数やパッケージの状態。特に、長期間放置され続けている RC バグがあるかどうか? さらに通常どの程度の数のバグがあるか? もう一つの重要な情報はパッケージが NMU されているかどうか、されているとしたら誰によって行われているか、です。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: Is there any activity of the maintainer outside of Debian? For example, they might have posted something recently to non-Debian mailing lists or news groups.
ja: Debian 以外でメンテナの活動があるかどうか? 例えば、近頃 Debian 以外のメーリングリストや news グループへの投稿をしているなど。

note: type: Content of: <chapter><section><para>
en: A bit of a problem are packages which were sponsored — the maintainer is not an official Debian developer.  The <literal>echelon</literal> information is not available for sponsored people, for example, so you need to find and contact the Debian developer who has actually uploaded the package.  Given that they signed the package, they're responsible for the upload anyhow, and are likely to know what happened to the person they sponsored.
ja: パッケージがスポンサーされている、つまりメンテナが公式の Debian 開発者ではない場合はちょっとした問題となります。例えば <literal>echelon</literal> の情報は、スポンサーされている人は利用できません。そのため実際にパッケージをアップロードした Debian 開発者を探して確認を取る必要があります。彼らがパッケージにサインしたということは、アップロードについて何であれ責任を持ち、スポンサーした人に何が起こっているかを知っていそうだということです。

note: type: Content of: <chapter><section><para>
en: It is also allowed to post a query to &email-debian-devel;, asking if anyone is aware of the whereabouts of the missing maintainer.  Please Cc: the person in question.
ja: &email-debian-devel; に、活動が見えないメンテナの居所に誰か気づいているかという質問を投稿するのもありです。問題の人を Cc: に入れてください。

note: type: Content of: <chapter><section><para>
en: Once you have gathered all of this, you can contact &email-mia;.  People on this alias will use the information you provide in order to decide how to proceed.  For example, they might orphan one or all of the packages of the maintainer.  If a package has been NMUed, they might prefer to contact the NMUer before orphaning the package — perhaps the person who has done the NMU is interested in the package.
ja: ここに書かれた全てを収集したなら、&email-mia;に連絡しましょう。この名前のエリアスを担当している人はあなたが供給した情報を使ってどう進めるかを判断します。例えば、そのメンテナのパッケージの一部または全てをみなしご化 (Orphan) するかも知れません。パッケージがNMUされていた場合は、パッケージをみなしご化 (Orphan) する前にNMUをした人に連絡する事を選ぶかもしれません — NMUをした人はきっとパッケージに関心があるでしょうから。

note: type: Content of: <chapter><section><para>
en: One last word: please remember to be polite.  We are all volunteers and cannot dedicate all of our time to Debian.  Also, you are not aware of the circumstances of the person who is involved.  Perhaps they might be seriously ill or might even have died — you do not know who may be on the receiving side.  Imagine how a relative will feel if they read the e-mail of the deceased and find a very impolite, angry and accusing message!
ja: 最後に一言: 礼儀正しく振る舞いましょう。我々は所詮ボランティアで、全ての時間を Debian に捧げられるわけではありません。また、関わっている人の状況がわかるわけでもありません。重い病気にかかっているかかもしれないし、あるいは死んでしまっているかもしれません - メッセージを受け取る側にどんな人がいるかは分かりません。亡くなった方のご親戚の方がメールを読んだ場合に、非常に無礼で怒った叱責調のメッセージを見つけてどうお感じになるかを想像してください。

note: type: Content of: <chapter><section><para>
en: On the other hand, although we are volunteers, we do have a responsibility.  So you can stress the importance of the greater good — if a maintainer does not have the time or interest anymore, they should let go and give the package to someone with more time.
ja: 一方で、我々はボランティアではありますが責任を持っています。全体の幸せの重要性をよく考える必要があります — もしメンテナが時間が足りなかったり、もう興味を無くしてしまった場合は、パッケージを誰か他のより時間がある人間に与えるべきです。

note: type: Content of: <chapter><section><para>
en: If you are interested in working in the MIA team, please have a look at the <filename>README</filename> file in <filename>/org/qa.debian.org/mia</filename> on <literal>qa.debian.org</literal> where the technical details and the MIA procedures are documented and contact &email-mia;.
ja: MIA チームで働くのに興味を持った場合は、技術上の詳細と MIA の手順が記載されている <literal>qa.debian.org</literal> 上の <filename>/org/qa.debian.org/mia</filename> 内の <filename>README</filename> ファイルを参照して、&email-mia; に連絡を取ってください。

note: type: Content of: <chapter><section><title>
en: Interacting with prospective Debian developers
ja: Debian 開発者候補に対応する

note: type: Content of: <chapter><section><para>
en: Debian's success depends on its ability to attract and retain new and talented volunteers.  If you are an experienced developer, we recommend that you get involved with the process of bringing in new developers.  This section describes how to help new prospective developers.
ja: Debian の成功は新たな才能あるボランティアをどう魅了し確保するかにかかっています。あなたが経験豊かな開発者なら、新たな開発者を呼び込むプロセスに関与するべきです。このセクションでは新たな開発者候補者をどうやって手助けするのかについて記述します。

note: type: Content of: <chapter><section><section><title>
en: Sponsoring packages
ja: パッケージのスポンサーを行う

note: type: Content of: <chapter><section><section><para>
en: Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own, a new maintainer applicant.  Sponsoring a package also means accepting responsibility for it.
ja: パッケージのスポンサーになるというのは自分の権限ではパッケージをアップロードできない、新規メンテナ応募者のパッケージをアップロードするということです。また、パッケージのスポンサーを行うことはそれに伴う責任を引き受けることを意味します。

note: type: Content of: <chapter><section><section><para>
en: New maintainers usually have certain difficulties creating Debian packages — this is quite understandable.  That is why the sponsor is there, to check the package and verify that it is good enough for inclusion in Debian.  (Note that if the sponsored package is new, the ftpmasters will also have to inspect it before letting it in.)
ja: 新たなメンテナは大抵 Debian パッケージの作成する際に何らかの困難に会いますーこれは非常に理解できることです。これはなぜスポンサーがいてパッケージをチェックし Debian に含めるのに充分良いものであるかどうかを確認するのかの根拠です。(注記: スポンサーされたパッケージが新規の場合、Debian に入れる前に ftpmaster らがそのパッケージをチェックする必要があります)。

note: type: Content of: <chapter><section><section><para>
en: Sponsoring merely by signing the upload or just recompiling is <emphasis role="strong">definitely not recommended</emphasis>.  You need to build the source package just like you would build a package of your own.  Remember that it doesn't matter that you left the prospective developer's name both in the changelog and the control file, the upload can still be traced to you.
ja: 単にサインしてアップロードするや、再コンパイルするだけのスポンサー作業は<emphasis role="strong">全く推奨されません</emphasis>。ソースパッケージを自分自身がパッケージをビルドするようにビルドする必要があります。changelog と control ファイルに開発候補者の名前を残してあろうとも、アップロード誰がしたかは遡及できることを忘れないでください。

note: type: Content of: <chapter><section><section><para>
en: If you are an application manager for a prospective developer, you can also be their sponsor.  That way you can also verify how the applicant is handling the 'Tasks and Skills' part of their application.
ja: もしあなたが開発候補者の応募管理者であれば、彼らのスポンサーとなることもできます。こうすることで応募者が応募作業の 'Tasks and Skills' 部分をどう取り扱えるかを判断できます。

note: type: Content of: <chapter><section><section><title>
en: Managing sponsored packages
ja: スポンサーされたパッケージを取り扱う

note: type: Content of: <chapter><section><section><para>
en: By uploading a sponsored package to Debian, you are certifying that the package meets minimum Debian standards.  That implies that you must build and test the package on your own system before uploading.
ja: スポンサーされたパッケージを Debian にアップロードすることは、Debian の標準について最低限は合致していることを保証することです。つまり、アップロード前に自分自身のシステムでパッケージをビルド、テストしなくてはいけないという意味です。

note: type: Content of: <chapter><section><section><para>
en: You cannot simply upload a binary <filename>.deb</filename> from the sponsoree.  In theory, you should only ask for the diff file and the location of the original source tarball, and then you should download the source and apply the diff yourself.  In practice, you may want to use the source package built by your sponsoree.  In that case, you have to check that they haven't altered the upstream files in the <filename>.orig.tar.{gz,bz2,lzma}</filename> file that they're providing.
ja: あなたは、スポンサー対象者からの <filename>.deb</filename> バイナリを単にアップロードすることはできません。通常、diff ファイルとオリジナルのソース tar ファイルを要求して、それから自分でソースをダウンロードして diff を適用する必要があります。実際には、スポンサー対象者が生成したソースパッケージを使うということです。この場合、彼らが提供した <filename>.orig.tar.{gz,bz2,lzma}</filename> ファイル中の開発元 (upstream) を改変していないことをチェックする必要があります。

note: type: Content of: <chapter><section><section><para>
en: Do not be afraid to write the sponsoree back and point out changes that need to be made.  It often takes several rounds of back-and-forth email before the package is in acceptable shape.  Being a sponsor means being a mentor.
ja: スポンサー対象者に必要な変更点を指摘の連絡するのを恐れないでください。パッケージが受け入れ可能な形になる前に何度もメールのやりとりが起こるのはよくあることです。スポンサーになるということはメンター (mentor) になるということです。

note: type: Content of: <chapter><section><section><para>
en: Once the package meets Debian standards, build and sign it with
ja: 一旦 Debian の標準に合致するようになったら、incoming ディレクトリにアップロードする前にパッケージを以下の様にしてビルドして署名してください

note: type: Content of: <chapter><section><section><para>
en: before uploading it to the incoming directory.  Of course, you can also use any part of your <replaceable>KEY-ID</replaceable>, as long as it's unique in your secret keyring.
ja: もちろん、秘密鍵のキーリング中で唯一である限り、どの <replaceable>KEY-ID</replaceable> も使うことができます。

note: type: Content of: <chapter><section><section><para>
en: The <literal>Maintainer</literal> field of the <filename>control</filename> file and the <filename>changelog</filename> should list the person who did the packaging, i.e., the sponsoree.  The sponsoree will therefore get all the BTS mail about the package.
ja: <filename>control</filename> ファイルの<literal>Maintainer</literal> 欄と<filename>changelog</filename> にはパッケージ作業を行った人を記載する必要があります。つまりはスポンサー対象者、ということです。そうすることで、スポンサー対象者がパッケージに対する BTS メールを受け取れるようになります。

note: type: Content of: <chapter><section><section><para>
en: If you prefer to leave a more evident trace of your sponsorship job, you can add a line stating it in the most recent changelog entry.
ja: スポンサーを行ったという状況証拠を残しておいて後から確認したいという場合は、最も新しい changelog のエントリにそのような記述を追加できます。

note: type: Content of: <chapter><section><section><para>
en: You are encouraged to keep tabs on the package you sponsor using <xref linkend="pkg-tracking-system"/>.
ja: <xref linkend="pkg-tracking-system"/> を使って、スポンサーしたパッケージの状況を把握するのをお勧めします。

note: type: Content of: <chapter><section><section><title>
en: Advocating new developers
ja: 新たな開発者を支持する (advocate)

note: type: Content of: <chapter><section><section><para>
en: See the page about <ulink url="&url-newmaint-advocate;">advocating a prospective developer</ulink> at the Debian web site.
ja: Debian ウェブサイトの<ulink url="&url-newmaint-advocate;">開発者志願者の支持者になる (advocating a prospective developer)</ulink>のページを参照してください。

note: type: Content of: <chapter><section><section><title>
en: Handling new maintainer applications
ja: 新規メンテナ申請 (new maintainer applications) を取り扱う

note: type: Content of: <chapter><section><section><para>
en: Please see <ulink url="&url-newmaint-amchecklist;">Checklist for Application Managers</ulink> at the Debian web site.
ja: Debian のウェブサイトにある <ulink url="&url-newmaint-amchecklist;">申請管理者用チェックリスト (Checklist for Application Managers)</ulink> を参照してください。
