Author: matakagi Date: Fri May 2 19:20:41 2008 New Revision: 1462 Log: - translated "Handling a Fork".
Modified: trunk/ja/ch08.xml Modified: trunk/ja/ch08.xml ============================================================================== --- trunk/ja/ch08.xml (original) +++ trunk/ja/ch08.xml Fri May 2 19:20:41 2008 @@ -4224,8 +4224,12 @@ </para> <sect2 id="forks-handling"> +<!-- <title>Handling a Fork</title> +--> +<title>フォークの処理</title> +<!-- <para>If someone threatens a fork in your project, keep calm and remember your long-term goals. The mere <emphasis>existence</emphasis> of a fork isn't what hurts a project; @@ -4251,7 +4255,40 @@ they need, and provide it if you can. Bend over backward to show that you are not standing in the way, and that you want the fork to succeed or fail on its own merits and nothing else.</para> +--> +<para> + プロジェクト内で誰かがフォークの兆候を見せ始めたら、 + まずは落ち着いてあなたの長期目標を思い出しましょう。 + フォークすること<emphasis>自体</emphasis>はプロジェクトにとって害ではありません。 + むしろそれによって開発者やユーザーを失うことが問題なのです。 + つまり、あなたのやるべきことはフォークの芽を摘むことではなく + その被害を最小限に抑えることなのです。 + フォークについて腹が立つかもしれません。 + そのフォークは不当なものであり、また不要なものであると感じるかもしれません。 + でも、そんな感情を表に出したところで、 + 態度を決めかねている開発者をあなたから遠ざけることにしかなりません。 + 開発者たちに、態度を明確にするよう要求してはいけません。 + そして、フォークする人たちともできるだけ協力的に接するようにしましょう。 + まず第一に、誰かがフォーク側で作業をすることになったからといって、 + その人のコミット権を剥奪するようなことはやめましょう。 + フォーク側で作業をすることになったからといって、 + 元のプロジェクトにおけるその人の権限が即刻失われるというわけではありません。 + これまでコミッターであった人は、これからもコミッターであり続けるべきです。 + さらに、フォーク側とはできるだけ仲良くやっていきたいという意志を示すことも大切です。 + 必要に応じて、お互いのプロジェクトの変更内容を相手側にも反映させられるような関係を保ちましょう。 + もしあなたがプロジェクトのサーバーの管理権限を持っているのなら、 + フォークを始めるにあたってのインフラの支援を提案しましょう。 + たとえば、そのプロジェクトの過去のバージョン管理リポジトリのデータのコピーを提供すれば、 + 彼らが過去のデータを使えるようになります (使用するバージョン管理システムによっては、 + わざわざそうしなくても過去のデータを利用できるものもあります)。 + 何か必要なものがないかどうかを彼らに聞き、 + 可能な限り支援するようにしましょう。 + あなたがフォークの邪魔をするつもりがないこと、 + そして (他の要因ではなく) あくまでもフォーク側の実力次第で成功か失敗が決まるような状態にすること + を態度で示すことが大切です。 +</para> +<!-- <para>The reason to do all this—and do it publicly—is not to actually help the fork, but to persuade developers that your side is a safe bet, by appearing as non-vindictive as possible. In war it @@ -4263,7 +4300,24 @@ project to benefit from interesting new features in the fork (yes, the fork may have things you want), and also increase the chances of a merger down the road.</para> +--> +<para> + これらすべてを (公式に) 行う理由は、 + フォーク側を助けるためではありません。 + 「こっち側にいたほうが何かと安全ですよ」 + ということを、できるだけ押しつけがましくない方法で開発者たちに伝えるためです。 + 戦争においては、どちらの陣営に属するのかを明確にさせることにはそれなりの意味もあります + (戦略的な意味、あるいは人間的な意味において)。 + しかし、フリーソフトウェアの世界においてはこれはまったく無意味です。 + 実際、フォークした後でも両方のプロジェクトでおおっぴらに活動する開発者も中にはいます。 + 両者の互換性を保つために力を注いでいたりするわけです。 + 彼らのおかげで、フォークした後でも両方のプロジェクトの間の交流ができるようになります。 + 彼らは、フォーク側で追加したすてきな新機能をあなたのプロジェクトにもたらしてくれるかもしれません + (そう、あなたの望むものをあちら側で作っている可能性もあるでしょう)。 + そして、将来ふたたび両者が合流するという望みも残してくれます。 +</para> +<!-- <para>Sometimes a fork becomes so successful that, even though it was regarded even by its own instigators as a fork at the outset, it becomes the version everybody prefers, and eventually supplants the @@ -4288,7 +4342,43 @@ everyone with a needless name change, yet do nothing to prevent the switchover. So GCC adopted the EGCS codebase, and there is once again a single GCC, but greatly improved because of the fork.</para> +--> +<para> + 時にはフォークのほうが大成功を収めることもあります。 + 最初に分裂させた当事者でさえ自分たちのほうがフォークだと認めているにもかかわらず、 + みんながそちらのバージョンのほうをずっと好むようになり、 + 結局本家に取って代わるようになるといったものです。 + 有名なのは GCC/EGCS の例です。 + <firstterm>GNU Compiler Collection</firstterm> + (<firstterm>GCC</firstterm>、これは以前は <firstterm>GNU C + Compiler</firstterm> という名前でした) + は、オープンソースのネイティブコードコンパイラとしてもっともよく知られているもので、 + またもっとも多くの環境に移植されているコンパイラでもあります。 + GCC の公式メンテナーと Cygnus Software + <footnote> + <para> + 現在は RedHat (<ulink url="http://www.redhat.com/"/>) + に吸収されました。 + </para> + </footnote> + との間の意見の相違が原因で、GCC のもっとも活発な開発者グループのひとつであった + Cygnus は GCC を離れて <firstterm>EGCS</firstterm> + というフォークを立ち上げました。 + このフォークは、意図的にオリジナルと敵対することを避けました。 + EGCS の開発者は、決して自分たちのバージョンを公式な GCC にしようとは思わなかったのです。 + そうではなく、EGCS をよりよいものにすることだけに注力し、 + パッチを受け入れる頻度も公式の GCC メンテナーより多くしました。 + EGCS の人気は増し、大手の OS ディストリビュータの中にも + デフォルトのコンパイラとして GCC ではなく EGCS を採用するところが出てきました。 + ここにきて、さすがに "GCC" の名前を持っている本家 GCC のメンテナーたちもわかってきました。 + みんなが EGCS に移行するときにわざわざ名前を変更しなければならないのは面倒だということ、 + そしてもはや GCC の名前を引き渡さざるをえないということを。 + そこで、GCC は EGCS のコードを受け入れることにしました。 + GCC は再び統一されたのです。 + フォークのおかげで、中身はとても改良されたものになっています。 +</para> +<!-- <para>This example shows why you cannot always regard a fork as an unadulteratedly bad thing. A fork may be painful and unwelcome at the time, but you cannot necessarily know whether it will succeed. @@ -4307,6 +4397,30 @@ adopt into the mainline project some or all of the actions contemplated by the fork—in essence, to avoid the fork by becoming it.</para> +--> +<para> + この例ひとつとっても、 + フォークを単純に悪とみなすべきではないことがよくわかります。 + フォークが起こったときは苦痛を感じてあまり歓迎されないかもしれませんが、 + フォークが成功するかどうかなんてそのときには知ることはできません。 + したがって、あなたを含むプロジェクトのメンバーができることといえば、 + 彼らを見守り続けて新機能やコードを取り込めるように準備しておくことくらいです。 + もしそのほうがプロジェクト全体の利益になると皆が同意したら、 + 究極の選択としてフォーク側に合流することも考えるべきでしょう。 + もちろん、フォークに加わるメンバーをみれば + それが成功するか失敗するかをある程度予測できることも多いでしょう。 + たとえば、プロジェクト内で文句ばかり言っていた人が + 一握りの不満分子 (彼らもプロジェクト内では建設的な振る舞いをしていませんでした) + を引き連れてフォークしたとしましょう。 + こんな場合は、むしろフォークしてくれたほうがありがたかったでしょうね。 + 彼らが本家に取って代わることを心配する必要もないでしょう。 + しかし、もし皆に尊敬されている実力者がフォークに参加しているというのなら、 + なぜそんなことになったのか自分に問い返してみましょう。 + おそらく、あなたのプロジェクトには制約が多すぎ、 + やりたいことの一部 (あるいはすべて) + を実現するにはフォークするしかなかったのでしょう。 + 自らがフォークすることで他のフォークを避けるということです。 +</para> </sect2> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
