Author: wangpeng Date: Fri Jul 27 02:51:58 2007 New Revision: 860 Log: ch02 continued
Modified: trunk/zh/ch02.xml Modified: trunk/zh/ch02.xml ============================================================================== --- trunk/zh/ch02.xml (original) +++ trunk/zh/ch02.xml Fri Jul 27 02:51:58 2007 @@ -248,58 +248,16 @@ <!-- ======================== subsection ============================== --> <sect2 id="vc-and-bug-tracker-access"> -<title>Version Control and Bug Tracker Access</title> +<title>版本控制和Bug追踪进入</title> -<para>Downloading source packages is fine for those who just want to -install and use the software, but it's not enough for those who want -to debug or add new features. Nightly source snapshots can help, but -they're still not fine-grained enough for a thriving development -community. People need real-time access to the latest sources, and -the way to give them that is to use a version control system. The -presence of anonymously accessible version controlled sources is a -sign—to both users and developers—that this project is -making an effort to give people what they need to participate. If you -can't offer version control right away, then put up a sign saying you -intend to set it up soon. Version control infrastructure is discussed -in detail in <xref linkend="vc"/><phrase output="printed"> in +<para>下载源码软件包对于只想安装和使用软件的人来说足矣， 但对于想要解决bug问题或增加新特性的那些人就不够了。 尽管每夜快照档(nightly source snapshots)会有些帮助， 但是对一个活跃的开发社区来说， 仍然不够细致。 人们需要实时进入最新的代码系统， 而能够实现这一点的途径便是使用版本控制系统。 如果一个人在匿名情况下便可以获取受版本控制的代码， 那就意味着该软件对用户和开发人员昭示：项目正努力为人们的参与创造条件。 要是你不能马上提供版本控制， 也应该出一个告示， 告知人们你会尽快那样做。 有关版本控制的基础架构详见<xref linkend="vc"/><phrase output="printed"> in <xref linkend="technical-infrastructure"/></phrase>.</para> -<para>The same goes for the project's bug tracker. The importance of -a bug tracking system lies not only in its usefulness to developers, -but in what it signifies for project observers. For many people, an -accessible bug database is one of the strongest signs that a project -should be taken seriously. Furthermore, the higher the number of bugs -in the database, the better the project looks. This might seem -counterintuitive, but remember that the number of bugs recorded really -depends on three things: the absolute number of bugs present in the -software, the number of users using the software, and the convenience -with which those users can register new bugs. Of these three factors, -the latter two are more significant than the first. Any software of -sufficient size and complexity has an essentially arbitrary number of -bugs waiting to be discovered. The real question is, how well will -the project do at recording and prioritizing those bugs? A project -with a large and well-maintained bug database (meaning bugs are -responded to promptly, duplicate bugs are unified, etc.) therefore -makes a better impression than a project with no bug database, or a -nearly empty database.</para> - -<para>Of course, if your project is just getting started, then the bug -database will contain very few bugs, and there's not much you can do -about that. But if the status page emphasizes the project's youth, -and if people looking at the bug database can see that most filings have -taken place recently, they can extrapolate from that that the project -still has a healthy <emphasis>rate</emphasis> of filings, and they -will not be unduly alarmed by the low absolute number of bugs -recorded.</para> - -<para>Note that bug trackers are often used to track not only software -bugs, but enhancement requests, documentation changes, pending tasks, -and more. The details of running a bug tracker are covered in -<xref linkend="bug-tracker"/><phrase output="printed"> in -<xref linkend="technical-infrastructure"/></phrase>, so I won't -go into them here. The important thing from a presentation point of -view is just to <emphasis>have</emphasis> a bug tracker, and to make -sure that fact is visible from the front page of the project.</para> +<para>对于项目的bug追踪系统来说，也是同样的道理。 Bug追踪系统之所以重要不只因为它对开发人员十分有用， 而且对关注项目的人来说是一种标志。 在许多人看来， 一个可以进入的bug数据库是一个项目是否严肃认真的重要标志之一。 再者， 数据库中的bug数量越多， 项目看起来越好。 这听起来似乎有悖常理， 但是请记住bug数量的记录实际上取决于三个因素： 软件中存在的bug绝对数量， 使用该软件的用户人数， 以及用户记录新发现的bug的方便程度。 在这三个因素当中， 后两个比前一个重要得多。 任何具有一定规模和复杂性的软件基本上都存在一定数量有待被发现的bugs。 真正的问题时， 一个项目在记录和优先解决bug问题方面做得有多好？ 如果一个项目有一个较大而又维护得很好的bug数据库（意思是bug问题得到及时地回应， bug复件被整合等等）， 那么这个项目就会比那些没有bug数据库， 或者bug数据库里空空如也的项目给予人们更好的印象。</para> + +<para>当然，如果你的项目刚刚起步， 那么bug数据库里就只有为数不多的bugs， 而对此你也没有什么办法。但是如果在开发状况页强调项目仍处于初创期， 且人们看到bug数据库里大多数的文档都是近期建立的， 他们便可以由此推断出该项目仍然有良好的建挡<emphasis>比率</emphasis>， 也就不会因为看到相对较低的已经记录的bug绝对数量而产生不适当的警觉。 </para> + +<para>请注意bug追踪系统的用途不止追踪软件的bugs， 而且也用来跟踪扩展请求，文档变更， 待解决的任务， 以及其它一些问题。 运行一个bug追踪系统的详细内容见<xref linkend="bug-tracker"/><phrase output="printed"> in <xref linkend="technical-infrastructure"/></phrase>, 所以在此我就不赘述了。重要的是， bug追踪<emphasis>一定</emphasis>要显示出来，而且要确保项目的首页上便能看到这一点。</para> </sect2> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
