Author: mumumu
Date: Sat Oct 13 18:18:36 2007
New Revision: 1255
Log:
- updated translation
Modified:
trunk/ja/ch07.xml
Modified: trunk/ja/ch07.xml
==============================================================================
--- trunk/ja/ch07.xml (original)
+++ trunk/ja/ch07.xml Sat Oct 13 18:18:36 2007
@@ -1294,7 +1294,7 @@
それに乗り遅れまいとして大急ぎで変更作業を終えようとします。
これは勿論、リリースするときにはまさに起こって欲しくないことです。
開発者は自分の好きなペースで新機能を実装していればいいのであって、
- 自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方が望ましいのです。
+ 自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方がいいのです。
ひとつのリリースに多くの変更を直前に詰め込もうとすればするほど、
コードは不安定になり、（普通）多くのバグが発生してしまうのです。
</para>
@@ -1322,15 +1322,14 @@
リリースを安定化する過程でどの変更をリリースに取り込むべきかについて、
おおまかな点で一致しています。深刻なバグ、
特に回避しようがないバグの修正は含めていいでしょう。
- ドキュメントの更新も含めていいでしょうし、エラーメッセージの修正も同様です。
- （但し、それがインターフェイスの一部と考えられていて、
- 安定していなければいけない場合は別です）
- 多くのプロジェクトでは、リスクが低いか、コアに影響しないある種の変更も受け入れますし、
+ ドキュメントの更新も含めていいでしょうし、エラーメッセージの修正（但し、それがインターフェイスの一部と考えられていて、
+ 安定していなければいけない場合は別です）も同様です。
+ 多くのプロジェクトでは、リスクが低いか、コアに影響しない変更も受け入れますし、
リスクを測るための正式なガイドラインもあるでしょう。
- しかし、どんな基準があっても人間の判断は必ず必要です。
+ しかし、どんな基準があったとしても人間の判断は必ず必要です。
変更をリリースに取り込むか否かをプロジェクトが決めなければいけないのは日常茶飯事でしょう。
危険なのは、開発者それぞれが自分の変更をリリースに含めたいと思っているので、
- 変更を受け入れることを望む人は多いのに、それに対してNOという人が少ないことです。
+ 変更を受け入れることを望む人は多いのに、それに対して NO という人が少ないことです。
</para>
<!--
@@ -1351,15 +1350,15 @@
<para>
そういうわけで、リリースを安定化させるプロセスは、
ほとんどが "NO" と言う仕組みを作ることと同じです。
- オープンソースプロジェクトに特有なトリックは、
+ オープンソースプロジェクトに特有なのは、
開発者を傷つけたり、がっかりさせることなく "NO" といいつつ、
- 価値がある変更はリリースに取り込むようにする方法に知恵を絞っています。
+ 価値がある変更はリリースに取り込むようにする方法に知恵を絞っていることです。
たくさんの方法がありますが、いったん開発チームがそれらを重要な基準として注目すれば、
基準を満たす仕組みを作るのは簡単です。
- ここではもっとも両極端な、人気のあるやり方をふたつ簡単に説明しますが、
+ ここではもっとも人気のある、両極端なやり方をふたつ簡単に説明しますが、
二つだけにすることで、プロジェクトが創造性をなくしてはいけません。
他のやり方はたくさんあるでしょうから、
- 実際に使われているのを私が見たことがあるふたつだけに留めておきます。
+ 私が実際に使われているのを見たことがあるふたつだけに留めておきます。
</para>
<!-- ======================== subsection ============================== -->
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
