# Appendix D. 报告bug的样例指导 这是Subversion项目针对新用户如何报告bug的在线指导的少许修改版本。为什么项目有一个这样的指导的重要性请见[Chapter 8, *管理志愿者*](# "Chapter 8. 管理志愿者")的[the section called “将每个用户当作潜在的志愿者”](# "将每个用户当作潜在的志愿者")。原始的文档位于[http://svn.collab.net/repos/svn/trunk/www/bugs.html](http://svn.collab.net/repos/svn/trunk/www/bugs.html)。 ~~~ Subversion中如何报告Bug 该文档说明了如何以及在何处报告Bug。（这里不是所有现存Bug的列表 - 您可以 在这里得到。） 何处报告Bug --------------------- * 如果是Subversion本身的Bug，可以发送邮件到users@subversion.tigris.org。 如果确认是bug，或许您可以将其输入问题跟踪系统。（或者如果您对Bug 非常确定，可以直接在我们的开发列表dev@subversion.tigris.org发布。 但是，如果您不能确定，最好首先在users@提交；某人会告诉您您所遇到的 情况是否与预期一致。） * 如果是APR库的Bug，请同时在以下列表中报告： dev@apr.apache.org，dev@subversion.tigris.org * 如果是Neon HTTP库的Bug，请同时在以下列表中报告： neon@webdav.org，dev@subversion.tigris.org * 如果是Apache HTTPD 2.0的Bug，请同时在以下列表中报告： dev@httpd.apache.org，dev@subversion.tigris.org。Apache httpd 开发者邮件列表流量较大，您的报告可能会被错过。您也可以在 http://httpd.apache.org/bug_report.html发起一个bug。 * 如果您的毯子有bug，请给他一个拥抱让它保持温暖。 如何报告一个Bug ------------------- 首先，请确保它是一个bug。如果Subversion无法按照您的预期工作，请检查 文档和邮件列表，确保它确实应该按照您的预期工作。当然，如果是常识， 例如Subversion破坏了您的数据并导致您的显示器冒烟，您可以相信自己的 判断。但是如果并不确定，请继续在用户邮件列表users@subversion.tigris.org 中询问，或者在IRC的irc.freenode.net中的频道#svn中询问。 一旦您确定是一个bug，最重要的事情得到一个简单的描述和重现步骤。例如， 如果您发现的bug，只会发生在5个文件的10次提交中，请设法使之在单个文件 的单个提交中发生。重现步骤越简单，开发者越有可能重现bug并修正它。 当您写下重现步骤时，不要仅仅写下使bug发生的散文描述，而应当给出一个 您所运行命令的一系列文本脚本，及其输出。请使用复制粘贴，如果与文件 有关，请包含文件名，如果您觉得与内容有关，也请提供文件内容。最好是能 提供打包的重现步骤脚本，那会使我们获益良多。 快速健全性检查：您正在运行Subversion最近的版本，对吧？:-)或许bug已经 修正；请对最新的Subversion开发树运行重现步骤进行测试。 除了重现步骤，我们也需要重现Bug的完整环境描述。包括： * 您的操作系统 * Subversion的发布版本和修订版本 * 构建Subversion的编译器和配置选项 * 您对Subversion的私下修改 * 运行Subversion的Berkeley DB版本，如果使用的话 * 所有其他可能相关的事情，宁肯信息多一点也不要少一点。 一旦完成了这些，您就准备好了编写报告了。从对Bug的简短描述开始，也就是 您对Subversion的预期行为方式，与之对应的实际行为方式。虽然Bug对 你是显而易见的，但对其他人可能并不是这么明显，所以最好可以避免猜谜游 戏。然后是环境描述，以及重现步骤。如果您希望也可以包含对于原因的猜测， 甚至是修正bug的补丁，那样就太棒了 - 关于发送补丁的指导请看 http://svn.collab.net/repos/svn/trunk/www/hacking.html#patches。 将所有信息发送到dev@subversion.tigris.org，或者如果您已经在此询问并被 要求发起一个问题，可以根据这里的指导进入问题跟踪系统。 谢谢。我们知道要发起一个有效的bug报告还有很多事情要做，但是一个好的报告 可以为开发者节省大量时间，会让bug更有可能被修正。 ~~~