Author: mumumu
Date: Sat Aug 25 14:52:06 2007
New Revision: 1099
Log:
- translated part of ch07.
Modified:
trunk/ja/ch07.xml
Modified: trunk/ja/ch07.xml
==============================================================================
--- trunk/ja/ch07.xml (original)
+++ trunk/ja/ch07.xml Sat Aug 25 14:52:06 2007
@@ -49,10 +49,10 @@
新機能の開発や重大でないバグフィックスは、
リリースが終わるまで脇に置いてくれと開発チーム全体に求めることができます。
ボランティアの集団はそんな一枚岩ではありません。
- オープンソースプロジェクトの人々は様々な理由で動いています。
+ オープンソースプロジェクトの人々は様々な理由で働いています。
よってリリース作業を手伝うことに興味がない人たちは、
たとえリリース作業が進行中でも日々の開発作業を続けたいと考えます。
- 開発は止まることがありませんので、
+ 開発が止まることはないので、
オープンソースソフトウェアのリリース作業は、
プロプラエタリなそれに比べて時間がかかりがちですが、
混沌としたものではありません。
@@ -63,7 +63,7 @@
もうひとつは、一度にひとつの車線でだけ作業を行い、
もう一方は通行できるようにしておくことです。
はじめのやり方は <emphasis>修理を行なう作業員にとっては</emphasis> 効率がいいやり方ですが、
- 作業員以外の人には効率がよくありません — 作業が終わるまで道路全体が閉鎖されるからです。
+ それ以外の人にはよくありません — 作業が終わるまで道路全体が閉鎖されるからです。
ふたつめのやり方は時間がかかり、修理する作業員は大変です（少ない人数、少ない機械、
窮屈な環境での作業を強いられる上、
通行する車を徐行させて交通整理をする旗振り役も置かなければいけない、など）が、
@@ -71,7 +71,7 @@
</para>
-
+<!--
<para>Open source projects tend to work the second way. In fact, for
a mature piece of software with several different release lines being
maintained simultaneously, the project is sort of in a permanent state
@@ -79,7 +79,19 @@
consistent but low level of background inconvenience is always being
tolerated by the development group as a whole, so that releases get
made on a regular schedule.</para>
+-->
+<para>
+ オープンソースプロジェクトはよくふたつめのやり方で動いています。
+ 実際、複数の異なったリリースラインがある状態で、
+ 成熟したソフトウェアのモジュールを管理するために、
+ プロジェクトはずっと小規模な道路修理を続けているような状態です。
+ いつも二つの車線が閉鎖して作業をしています。つまり、
+ リリースを定期的なスケジュールに従って行なえるように、
+ 開発チームは裏で起こるささいな不都合にはいつも目をつぶっているのです。
+</para>
+
+<!--
<para>The model that makes this possible generalizes to more than just
releases. It's the principle of parallelizing tasks that are not
mutually interdependent—a principle that is by no means unique
@@ -98,13 +110,45 @@
lot of developers sitting idle a lot of the time—which would be
not only inefficient but boring, and therefore dangerous, in that a
bored developer is likely to soon be an ex-developer.</para>
+-->
+<para>
+ この作業モデルはリリース作業以外にも一般化できます。
+ 互いに依存していないタスクは平行して処理をするという原則です。—
+ これはオープンソースソフトウェアの開発に限ったものではありませんが、
+ オープンソースプロジェクトは、独自のやり方でこの原則を実践しています。
+ プロジェクトで作業をしているボランティア達は、
+ 道路工事の作業員や通行する車を気にする余裕はそんなにありませんし、
+ カラーコーンの傍に待機して車に旗を振らせることに作業員を専念させる余裕もないのです。
+ つまり、彼らはプロジェクト管理の負荷の変化が激しい管理プロセスよりは、
+ 負荷が一定か、変化が少なくなるようなプロセスを好みます。
+ ボランティアたちは、ちょっと不便だなと思う状態が続いても嫌がりません。
+ 自分にかかる負荷が予想できるからこそ、
+ 彼らはプロジェクトで起こっていることがスケジュールと衝突しているかどうかを気にせずに作業できるのです。
+ プロジェクトが別の作業をやめてある作業に専念させるようなマスタ－スケジュールに縛られていると、
+ 多くの開発者が長い間何もしない状態が発生します — これは非効率であるばかりか、
+ 退屈なものなので危険です。退屈した開発者は、すぐに辞めてしまうでしょう。
+</para>
+
+<!--
<para>Release work is usually the most noticeable non-development task
that happens in parallel with development, so the methods described in
the following sections are geared mostly toward enabling releases.
However, note that they also apply to other parallelizable tasks, such
as translations and internationalization, broad API changes made
gradually across the entire code base, etc.</para>
+-->
+
+<para>
+ リリース作業は、
+ 平行して行なわれる作業のなかでも開発とは関係ないもっとも目立つタスクです。
+ よって次の節で説明するやり方で、
+ リリース作業を行なうタイミングを調整しています。
+ しかし、リリース作業と平行して行なえる作業、
+ たとえば翻訳や国際化、
+ コードベース全体に徐々に浸透するようにAPIを大規模に変更する、
+ などが同時に行なわれていることに注意してください。
+</para>
</simplesect>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
