initial commit

1 files changed, 55 insertions, 0 deletions

diff --git a/files/ja/hacking_mozilla/index.html b/files/ja/hacking_mozilla/index.html
new file mode 100644
index 0000000000..c4163517cb
--- /dev/null
+++ b/files/ja/hacking_mozilla/index.html
@@ -0,0 +1,55 @@
+---
+title: Hacking Mozilla
+slug: Hacking_Mozilla
+tags:
+  - Developing Mozilla
+---
+<p>このページは、Mozilla の CVS リポジトリにプログラムコードをチェックインする方法を知りたい方のために設けられました。もしあなたが、今まで一度も Mozilla をビルドしたことがなければ、<a href="ja/Mozilla_Source_Code_(HTTP%2f%2fFTP)">ソースコード</a> のページを参照して、ビルドすることから始めた方がよいでしょう。そして <a href="ja/Mozilla_Hacker's_Getting_Started_Guide">Mozilla のハックを始めるためのガイド</a> を調べてみてください。
+</p>
+<h3 id=".E3.83.91.E3.83.83.E3.83.81.E3.81.AE.E3.83.A9.E3.82.A4.E3.83.95.E3.82.B5.E3.82.A4.E3.82.AF.E3.83.AB"> パッチのライフサイクル </h3>
+<p>もし、パッチ作成に関心があれば、以下のガイドラインが役に立つでしょう
+</p>
+<ul><li> 私達の基本的な設計思想の一つは、私達のプログラムコードが様々なプラットフォーム上で動作するようにするということです。必ずしも最新の標準の全てをサポートしていないようなコンパイラを使って、小さなプラットフォームに Mozilla を移植している人々もいます。もしあなたがコンパイルされたコード (C, C++) を書いているのであれば、私達の <a href="index.php?title=ja/C%2b%2b_Portability_Guide">C++ 移植ガイド</a> に従い、できる限りの警告出力を有効にしてコンパイルを行うことで、それらのプラットフォームを助けてください。いつの日かあなたは、あなたが書いたプログラムコードが、ケーブルテレビの受信機や携帯電話のような本当に小さなプラットフォーム上で動作しているのを見つけることでしょう。
+</li><li> あなたのコードは <a class="external" href="http://www.mozilla.org/projects/l10n/customizable-code.html">ローカリゼイション</a> にも気を付けてください。62の <a class="external" href="http://www.mozilla.org/projects/l10n/mlp_status.html#projects">登録されたプロジェクト</a> があり、そのうち 7 〜 10 個は現在もアクティブです。
+</li><li> <a href="ja/Mozilla_Coding_Style_Guide">Mozilla コーディングスタイルガイド</a> にも注意してください。
+</li><li> カスタマイズ性を考慮してください。Mozilla テクノロジの最大の利点の一つは、カスタマイズ性です。Mozilla のベンダやディストリビュータは彼らのニーズに向かって Mozilla を仕立てる特別な要件があるでしょう。Mozilla のディストリビュートを円滑にするために、機能を追加、削除、修正を容易に出来るように、是非カスタマイズ性を考慮してください。
+</li><li> 私達の <a class="external" href="http://www.mozilla.org/roadmap.html">開発ロードマップ</a> を読んでください。それは、Mozilla が目標としているアーキテクチャの概説であり、Mozilla をハックする全ての人にとって良い読みものです。
+</li><li> 新しいソースファイルを作るときには、適切な <a class="external" href="http://www.mozilla.org/MPL/boilerplate-1.1/">boilerplate (テンプレート)</a> のライセンスヘッダを加え、空欄を埋めてください。また、修正したファイルのライセンスヘッダの contributors (貢献者) 欄にあなた自身を加えるべきならばそうしてください。
+</li><li> パッチは現在の CVS に対して書くべきです。また、ソースファイルを開くことなくパッチを理解してもらうために、なるべく前後に十分な行を加えるべきです。標準のガイドラインとしては、最低限 <code>cvs diff -u8pN</code> を使用することが推奨されます。理解しやすいパッチを作るためにもっと前後の行を増やしたいなら、数字の 8 をもっと大きい数字に変えてください。
+</li></ul>
+<p>もし、あなたがパッチを持っていたら、それを <a class="link-https" href="https://bugzilla.mozilla.org/">Bugzilla</a> へのバグ報告に添付してください。私たちはコードレビューに大きな信頼を置いています。なので、CVS リポジトリにコードをチェックインする前に、適切な <a class="external" href="http://www.mozilla.org/owners.html">モジュールオーナー</a> か、その同僚によるレビューを受ける必要があります。モジュールは完全には直接 Bugzilla コンポーネントに対応しません。しかし、強い相関があります。レビューを受けるには：
+</p>
+<ul><li> <a class="external" href="http://www.mozilla.org/owners.html">該当モジュールのモジュールオーナーか peer (代行者)</a> に、パッチに <code>?</code> というレビューフラグを立て (このフラグはレビューが求められていることを示します)、レビューをお願いしたい人のメールアドレスを記入して、レビューを明示的に依頼してください (あなたが指名されたのでなければ)。
+</li><li> バグナンバと、パッチを添付している事実と、レビューしてほしいことに言及して、モジュールオーナーか代行者に直接メールを送ることも出来ます。しかし、Bugzilla の依頼機能を使った方が見落とされる可能性は低いです。
+</li></ul>
+<p>いくつかのケースで、次の数日以内に返答を受け取ることが出来るでしょう。不幸にして、忙しすぎるので彼らのバグ情報すべてに追いつけていない人々もいます。なので、あなたが 1 週間以内に返事を受け取れなくて、あなたがそのパッチに (言うならば、1 年やそこらでなく) すぐに対応する価値があると考えるなら、このようなことが出来ます。
+</p>
+<ul><li> そのコンポーネントのバグに対するパッチをレビューしたことのある誰か他の人を Bugzilla で探し、かわりにその人にレビューを依頼してください。
+</li><li> IRC の <a class="link-irc" href="irc://irc.mozilla.org/#developers">#developers</a> で適切なレビューワが誰かを聞いてください。注意：レビュー依頼は IRC ではなく、E-Mail で
+</li></ul>
+<p>レビューワはあなたが取り組んでほしいあなたのパッチに対してコメントするでしょう。彼らが満足したとき、かれらはパッチをレビュー済みと印付けし、バグ (訳注：Bugzilla) で "r=&lt;user&gt;"と言うでしょう。
+</p><p>たいていの場合、"スーパーレビュー"として知られる追加のレベルのレビューが必要です。<a class="external" href="http://www.mozilla.org/hacking/reviewers.html">スーパーレビュー</a> ドキュメントはスーパーレビューを受けるために何をすべきかについて詳しく述べています。また、スーパーレビューはパッチに変更を求めるかもしれません。彼らが満足すると、バグ (Bugzilla) の中でそう言うでしょう。
+</p><p>レビューとスーパーレビューを受けて、パッチが十分な水準に達していたら、ツリーにチェックインできます。あなたが CVS アカウントを持っていない場合、代わりにチェックインしてくれる人を探さなければなりません。これは実に簡単です。<code>checkin-needed</code> キーワードをバグに追加するだけです。数少ないコミッターがこのキーワードの検索を設定しており、ちょくちょく調べてはコミットされていないパッチをコミットします。通常はキーワードが追加されてから 1 ～ 2 週間のうちにはコミットされるでしょう。2 週間以上たってもコミットされない場合、IRC に行って誰かにあなたのパッチをコミットするように (そして <code>checkin-needed</code> が付いたバグを調べるように、それらのバグにパッチを提供した人たちも同じように待たされているでしょうから) 言ってみる価値はあるでしょう。
+</p><p>時折、ツリーはリリースを試みるために少しより厳重にロックされ、"approval" (承認) と呼ばれる第三段階がチェックインのために必要になります。それらの時期には、<a class="external" href="http://tinderbox.mozilla.org/">Tinderbox</a> は approval が必要であると先頭でうたって注意を促します。approval を依頼するには、パッチ添付ファイルを変更して approval フラグに <code>?</code> をセットしてください。もし、approval が断られた場合、リリースが行われるか、リリースへ向けての開発がブランチとなるまで、1 週間程度パッチのチェックインを待たなければなりません。
+</p><p>これらのプロセスの中で、他に問題を抱えているか、ガイドが必要なら、<a class="link-mailto" href="mailto:gerv@mozilla.org">Gerv</a> にメールすることです。
+</p>
+<h3 id="CVS_Commit_Access_.E3.83.AB.E3.83.BC.E3.83.AB"> CVS Commit Access ルール </h3>
+<p>あなたがパッチでの貢献を頻繁に行って、品質の良いコードについて定評のある業績を残したとき、<a class="external" href="http://www.mozilla.org/hacking/getting-cvs-write-access.html">CVS コミット権限を得る</a> のプロセスを始めることが出来ます。CVS コミット権限は、以下のルールが伴います。
+</p><p>もっとも重要なルールは、ビルドのプロセスに関してです。それを無視することは、多くの人々の時間を浪費することになります。図々しい違反者は、ルールに従う事に悩まされるでしょう。抵抗は無駄です。
+</p>
+<ul><li> <a class="external" href="http://www.mozilla.org/hacking/rules.html">follow the tree rules</a> を学びましょう。私達のビルドの手順は、柔軟で、人の手の介入を最小限しか必要とせず、数百人の技術者に対しても調整可能です。人々がこの単純なルールに従う限り、この手順は動作し続けるでしょう。
+</li><li> リポジトリにチェックインする人は全て、ツリーの担当する部分がきれいに保たれているようにしなくてはいけません。あなたのプログラムコードをチェックイン<b>する前に</b>、他のプラットフォームでビルドできることを確かめてください。チェックイン後は、Tinderbox があなたのプログラムコードを正常にビルドできるようにすることと、ビルド時や実行時の予期しない問題に対応できるようにすることは、あなたの責任です。多くの人にとって、<a class="external" href="http://groups.google.com/groups?oi=djq&amp;as_umsgid=mcmullen-2404991952090001%40h-208-12-40-136.mcom.com">ツリーの破損は時間の損失</a> となります。決してしないでください。
+</li><li> <a class="external" href="http://tinderbox.mozilla.org/">Tinderbox</a> の活用について学んでください。Tinderbox を使って、ツリーについての全ての情報を入手することができます。誰かがプログラムコードをツリーにチェックインしている場合、あなたは Bonsai を使って、ツリーがオープンされているかどうかや、計画されているクローズがあるかどうかなど、そのツリーについての情報を調べなくてはいけません。
+</li><li> 新しいディレクトリを作成する際には、そのディレクトリの親ディレクトリの所有者の許可を得てください。"mozilla" のトップディレクトリに新しいディレクトリを追加する際には、mozilla.org の <a class="link-mailto" href="mailto:staff@mozilla.org">スタッフ</a> に連絡してください。私達は、相当な理由がない限りは、新しいトップレベルディレクトリの追加を望みません。ほとんどの新しいプロジェクトは、ツリーにすでにあるどこかのフォルダ、例えば components におさまるでしょう。
+</li></ul>
+<p>Happy hacking!
+</p>
+<div class="originaldocinfo">
+<h2 id=".E5.8E.9F.E6.96.87.E6.9B.B8.E3.81.AE.E6.83.85.E5.A0.B1"> 原文書の情報 </h2>
+<ul><li> 最終更新日: October 1, 2007
+</li><li> 著作権: Portions of this content are © 1998–2007 by individual mozilla.org contributors; content available under a Creative Commons license | <a class="external" href="http://www.mozilla.org/foundation/licensing/website-content.html">詳細</a>
+</li></ul>
+</div>
+<div class="noinclude">
+</div>
+{{ languages( { "en": "en/Hacking_Mozilla" } ) }}