Author: rocksun Date: Sat Oct 25 05:03:33 2008 New Revision: 1534 Log: Modify some mistakes make build failed.
Modified: trunk/zh/book.xml trunk/zh/ch02.xml trunk/zh/ch03.xml trunk/zh/ch04.xml trunk/zh/dedication.xml Modified: trunk/zh/book.xml ============================================================================== --- trunk/zh/book.xml (original) +++ trunk/zh/book.xml Sat Oct 25 05:03:33 2008 @@ -29,6 +29,8 @@ <authorgroup> <author><firstname>Karl</firstname><surname>Fogel</surname> <contrib>(Author)</contrib></author> + <author><surname>(Rock Sun)</surname><firstname>孙岱军</firstname> + <contrib>(Translator)</contrib></author> <author><surname>(Wang Peng)</surname><firstname>王 芃 </firstname> <contrib>(Translator)</contrib></author> <author><surname>(Zissan)</surname><firstname>管 清</firstname> Modified: trunk/zh/ch02.xml ============================================================================== --- trunk/zh/ch02.xml (original) +++ trunk/zh/ch02.xml Sat Oct 25 05:03:33 2008 @@ -293,8 +293,8 @@ <para>但很不幸,你不可能在项目的开始就完成FAQ,好的FAQ不是写成的,而是长成的。它们是通过定义反应文档,随着人们对软件的日常使用而进化。因为不能预感到用户将会提出的问题,所以我们无法从头开始编写有用的FAQ。</para> - <para>因此,不要在这方面浪费时间了。但无论如何,你或许会发现创建一个FAQ的空白模板会很有用,很明显这样可以帮助人们在项目进行中贡献问题和答案。此时,最重要的性质不是完整,而是方便:如果添加FAQ非常简单,人们就会去添加。(正确的FAQ维护应该是特殊和迷惑性的问题,将会在<xref linkend="managing-volunteers"/>的</phrase><xref - linkend="faq-manager"/><phrase output="printed">详细讨论。)</para> + <para>因此,不要在这方面浪费时间了。但无论如何,你或许会发现创建一个FAQ的空白模板会很有用,很明显这样可以帮助人们在项目进行中贡献问题和答案。此时,最重要的性质不是完整,而是方便:如果添加FAQ非常简单,人们就会去添加。(正确的FAQ维护应该是特殊和迷惑性的问题,将会在<xref linkend="managing-volunteers"/><phrase output="printed">的</phrase><xref + linkend="faq-manager"/>详细讨论。)</para> </sidebar> <sect3 id="documentation-availability"> Modified: trunk/zh/ch03.xml ============================================================================== --- trunk/zh/ch03.xml (original) +++ trunk/zh/ch03.xml Sat Oct 25 05:03:33 2008 @@ -117,7 +117,7 @@ <varlistentry><term>审核特性</term> <listitem> - <para>在邮件发送到整个列表之前的“审核”是检查邮件以确保:a) 不是 垃圾邮件,以及b) 符合 主题。审核必须有人参与,但软件能很大程度的使之变得容易。后面还有关于审核的更多内容。</para> + <para>在邮件发送到整个列表之前的“审核”是检查邮件以确保:a) 不是 垃圾邮件,以及b) 符合 主题。审核必须有人参与,但软件能很大程度的使之变得容易。后面还有关于审核的更多内容。</para> </listitem> </varlistentry> @@ -575,7 +575,7 @@ <sect2 id="vc-choosing"> <title>选择一个版本控制系统</title> -<para>在写本文的时候,自由软件世界中两个最流行的版本控制系统是<firstterm>并行版本系统</firstterm>(firstterm>CVS</firstterm>,<ulink url="http://www.cvshome.org/"/>)和<firstterm>Subversion</firstterm>(<firstterm>SVN</firstterm>,<ulink url="http://subversion.tigris.org/"/>)。</para> +<para>在写本文的时候,自由软件世界中两个最流行的版本控制系统是<firstterm>并行版本系统</firstterm>(<firstterm>CVS</firstterm>,<ulink url="http://www.cvshome.org/"/>)和<firstterm>Subversion</firstterm>(<firstterm>SVN</firstterm>,<ulink url="http://subversion.tigris.org/"/>)。</para> <para>CVS已经存在很长时间了。大多数有经验的开发者已经熟悉了它,它或多或少满足了你的需要,而且因为它已经流行了很长时间了,你可能不会陷入它是否是正确选择的争论。CVS有一些缺点,它不支持简单的引用多个文件的变更;它不支持版本控制下的(这样如果你需要识别出项目开始后的代码树,会非常头痛)文件重命名和拷贝;它对合并的支持很弱;它处理大文件和二进制文件不佳;以及在操作很多文件时操作会非常慢。</para> Modified: trunk/zh/ch04.xml ============================================================================== --- trunk/zh/ch04.xml (original) +++ trunk/zh/ch04.xml Sat Oct 25 05:03:33 2008 @@ -1,98 +1,26 @@ <chapter id="social-infrastructure"> -<title>社会和政治的基础架构Social and Political Infrastructure</title> +<title>社会和政治的基础架构</title> <simplesect> -<para>有关自由软件,人们经常问道的第一个问题是:“它是怎么做的?什么在推动计划运行? -谁来做决定?”The first questions people usually ask about free software are -"How does it work? What keeps a project running? Who makes the -decisions?" I'm always dissatisfied with bland responses about -meritocracy, the spirit of cooperation, code speaking for itself, etc. -The fact is, the question is not easy to answer. Meritocracy, -cooperation, and running code are all part of it, but they do little -to explain how projects actually run on a day-to-day basis, and say -nothing about how conflicts are resolved.</para> - -<para>This chapter tries to show the structural underpinnings -successful projects have in common. I mean "successful" not just in -terms of technical quality, but also operational health and -survivability. Operational health is the project's ongoing ability to -incorporate new code contributions and new developers, and to be -responsive to incoming bug reports. Survivability is the project's -ability to exist independently of any individual participant or -sponsor—think of it as the likelihood that the project would -continue even if all of its founding members were to move on to other -things. Technical success is not hard to achieve, but without a -robust developer base and social foundation, a project may be unable -to handle the growth that initial success brings, or the departure of -charismatic individuals.</para> - -<para>There are various ways to achieve this kind of success. Some -involve a formal governance structure, by which debates are resolved, -new developers are invited in (and sometimes out), new features -planned, and so on. Others involve less formal structure, but more -conscious self-restraint, to produce an atmosphere of fairness that -people can rely on as a <foreignphrase>de facto</foreignphrase> form -of governance. Both ways lead to the same result: a sense of -institutional permanence, supported by habits and procedures that are -well understood by everyone who participates. These features are even -more important in self-organizing systems than in centrally-controlled -ones, because in self-organizing systems, everyone is conscious that a -few bad apples can spoil the whole barrel, at least for a while.</para> +<para>有关自由软件,人们经常问到的第一个问题是:“它能行吗?如何运作一个项目?谁来做决定?”我一直对关于知识界精化、合作精神、代码会说话此类的平淡回复不感兴趣,事实是这个问题很难回答,知识界精化、合作精神和运行代码只是其中的一部分,但它们对于解释日复一日的项目运转贡献不多,对于如何解决冲突什么也没说。 +</para> + +<para>本章尝试展示支持成功项目的共同结构,“成功”不仅仅指的技术质量方面,而且也包含了运行健康状况和生存性。运行健康状况是指项目将新代码和新开发者吸收进来,并对到来的bug负责的持续能力。生存性是项目独立于任何单独参与者或赞助商而存在的能力—考虑一下如果项目所有的创始成员离开后项目继续运作的可能性。技术成功不难实现,但是如果没有健壮的开发者基础和社会基础,一个项目就不能处理由初始的成功带来的成长,或者有魅力个体的离开。</para> + +<para>获取此类成功有很多方法。有些涉及正式的管理结构,通过哪些争论被解决、新开发者被邀请加入(有时是离开)和计划的新特行等等。还有一些涉及不太正式的结构,但需要更有意识的自我克制,来产生一种人们可以依赖的正直氛围,作为<foreignphrase>事实上的</foreignphrase>管理形式。两种方式都产生相同的结果:一种由来已久的永恒感觉,由所有参与者都充分理解的习惯和程序作为支撑。这些特性在自我组织的系统中甚至比集中控制的系统更重要,每个人都知道一个坏苹果可以毁掉一桶,即使只是一会儿。</para> <sect1 id="forkability"> -<title>Forkability</title> +<title>分叉能力(forkability)</title> + +<para>能将开发者绑定在一个自由软件项目中的必需组成部分,能让他们在必要时愿意作出妥协,是代码的<firstterm>分叉能力</firstterm>:也就是任何人可以使用一个拷贝并使之成为一个竞争项目的能力,被称为<firstterm>分叉</firstterm>。怪异的是自由软件项目的中分叉<emphasis>可能性</emphasis>具备比实际的分叉更大的动力,很少会发生。因为分叉对于每个人都不好(<phrase output="printed"><xref linkend="managing-volunteers"/>的</phrase><xref linkend="forks"/>会解释详细原因),分叉的威胁越大,越期望的人就越会妥协去避免它。</para> + +<para>分叉,更确切说是分叉的可能性,是自由软件项目中没有真正独裁者的原因。考虑到在一个特定开源项目中听到某人被称为“独裁者”或者“暴君”是多么常见,这看起来是一个令人惊讶的断言。但是此类暴政是特别的,与一般意义上的字面理解非常不同。想象一下一个国王的臣民可以在任何时候复制整个王国,并搬过去按自己满意的规则统治。这与国王无论如何做,臣民都无法离开的情况是多么的不同?</para> + +<para>这也是为什么即使项目不是完全按照民主方式组织时,在实践中,重要决定还是通过民主方式产生。可复制性暗指了分叉能力;分叉能力暗指了意见一致。也可能是每个人都希望与一个领袖不同(最有名的例子是在Linux内核开发中的Linus Torvalds),但那是因为他们<emphasis>选择</emphasis>如此,以一种非愤世嫉俗和非邪恶的方式。暴君没有项目的定身法,所有开源许可证都有一个关键特性,也就是在代码如何变更或使用上没有给任何组织更多的权力,如果一个独裁者突然开始做了一个坏的决定,就从此不得安宁,紧接着就是造反和分叉。除非,当然,很多时候不会到这一步,因为独裁者会首先妥协。</para> -<para>The indispensable ingredient that binds developers together on a -free software project, and makes them willing to compromise when -necessary, is the code's <firstterm>forkability</firstterm>: the -ability of anyone to take a copy of the source code and use it to -start a competing project, known as a <firstterm>fork</firstterm>. -The paradoxical thing is that the <emphasis>possibility</emphasis> of -forks is usually a much greater force in free software projects than -actual forks, which are very rare. Because a fork is bad for everyone -(for reasons examined in detail in -<xref linkend="forks"/><phrase output="printed"> in -<xref linkend="managing-volunteers"/></phrase>), the more serious -the threat of a fork becomes, the more willing people are to -compromise to avoid it.</para> - -<para>Forks, or rather the potential for forks, are the reason there -are no true dictators in free software projects. This may seem like a -surprising claim, considering how common it is to hear someone called -the "dictator" or "tyrant" in a given open source project. But this -kind of tyranny is special, quite different from the conventional -understanding of the word. Imagine a king whose subjects could copy -his entire kingdom at any time and move to the copy to rule as they -see fit. Would not such a king govern very differently from one whose -subjects were bound to stay under his rule no matter what he -did?</para> - -<para>This is why even projects that are not formally organized as -democracies are, in practice, democracies when it comes to important -decisions. Replicability implies forkability; forkability implies -consensus. It may well be that everyone is willing to defer to one -leader (the most famous example being Linus Torvalds in Linux kernel -development), but this is because they <emphasis>choose</emphasis> to -do so, in an entirely non-cynical and non-sinister way. The dictator -has no magical hold over the project. A key property of all open -source licenses is that they do not give one party more power than any -other in deciding how the code can be changed or used. If the dictator -were to suddenly start making bad decisions, there would be -restlessness, followed eventually by revolt and a fork. Except, of -course, things rarely get that far, because the dictator compromises -first.</para> - -<para>But just because forkability puts an upper limit on how much -power anyone can exert in a project doesn't mean there aren't -important differences in how projects are governed. You don't want -every decision to come down to the last-resort question of who is -considering a fork. That would get tiresome very quickly, and sap -energy away from real work. The next two sections examine different -ways to organize projects such that most decisions go smoothly. These -two examples are somewhat idealized extremes; many projects fall -somewhere along a continuum between them.</para> +<para>但分叉能力放置了一个上限(一个人在一个项目中发挥多少力量的上限)并不意味着项目的管理方式没有太大的区别。你不会希望每个决定都是某人要考虑分叉后的结果,下面两个小节会仔细检查组织项目平稳做出大多数决定的不同方法,这两个都是极端理想的例子;许多项目会处于中间状态。</para> </sect1> @@ -100,7 +28,7 @@ <!-- ======================== SECTION ============================== --> <sect1 id="benevolent-dictator"> -<title>Benevolent Dictators</title> +<title>慈善独裁者</title> <para>The <firstterm>benevolent dictator</firstterm> model is exactly what it sounds like: final decision-making authority rests with one Modified: trunk/zh/dedication.xml ============================================================================== --- trunk/zh/dedication.xml (original) +++ trunk/zh/dedication.xml Sat Oct 25 05:03:33 2008 @@ -1,7 +1,7 @@ <dedication id="dedication"> -<para><emphasis>�Ȿ�����ҵ���λ�����ѣ��Ҳ������������ǣ�Karen -Underhill��Jim Blandy��</emphasis></para> +<para><emphasis>这本书献给我的两位好朋友,我不可能忘掉他们:Karen +Underhill和Jim Blandy。</emphasis></para> </dedication>
_______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators