错误 / 问题 ¶

如何报告错误 ¶

首先，确保这是一个错误。如果 Subversion 的行为与您的预期不符，请查看文档和邮件列表存档，以获取证据证明它应该按您的预期方式运行。当然，如果这是一个常识性的问题，比如 Subversion 只是破坏了您的数据并导致您的显示器冒烟，那么您可以相信自己的判断。但是，如果您不确定，请先在用户邮件列表 [email protected] 上询问，或在 IRC 上询问，irc.libera.chat，频道 #svn（网络界面 或 Matrix）。

您还应该在错误跟踪器中搜索，看看是否有人已经报告了此错误。

一旦您确定这是一个错误，并且我们还不知道，您能做的最重要的事情就是想出一个简单的描述和重现方法。例如，如果您最初发现的错误涉及十次提交中的五个文件，请尝试只用一个文件和一次提交来重现它。重现方法越简单，开发人员就越有可能成功重现错误并修复它。

在编写重现方法时，不要仅仅用散文描述您为使错误发生所做的事情。相反，请提供您运行的精确命令序列及其输出的文字记录。使用剪切粘贴来完成此操作。如果涉及文件，请务必包含文件名称，甚至包含您认为可能相关的内容。最好的方法是将您的重现方法打包成一个脚本；这将对我们有很大帮助。以下是一个此类脚本的示例：repro-template.sh （适用于类 Unix 系统和 Bourne shell）或 repro-template.bat（适用于 Windows shell，由 Paolo Compieta 贡献）；我们欢迎为其他系统贡献类似的模板脚本。

快速检查：您*正在*运行最新版本的 Subversion，对吧？:-) 可能此错误已经修复；您应该针对最新的 Subversion 开发树测试您的重现方法。

除了重现方法之外，我们还需要您重现错误的环境的完整描述。这意味着

• 您的操作系统
• Subversion 的版本和/或修订版
• 您用来构建 Subversion 的编译器和配置选项
• 您对 Subversion 所做的任何私有修改
• 您运行 Subversion 时使用的 Berkeley DB 版本（如果有）
• 任何其他可能相关的因素。宁可信息过多，也不要信息过少。

准备好所有这些信息后，您就可以开始编写报告了。首先要清楚地描述错误是什么。也就是说，说明您预期 Subversion 的行为，并将其与实际行为进行对比。虽然错误对您来说可能很明显，但对其他人来说可能并不明显，因此最好避免猜测。接下来是环境描述和重现步骤。如果您还想包含关于原因的推测，甚至提供一个修复错误的补丁，那就太好了——请参阅补丁提交指南。

将所有这些信息发布到[email protected]，或者如果您已经在那里并被要求提交问题，那么请访问问题跟踪器并按照那里的说明操作。

感谢您。我们知道提交有效的错误报告需要很多工作，但一份好的报告可以节省开发人员数小时的时间，并使错误更有可能得到修复。

在哪里报告错误 ¶

• 如果错误出现在 Subversion 本身，请发送邮件到[email protected]。一旦确认是错误，有人（可能是您）可以将其输入到问题跟踪器中。（或者，如果您对错误非常确定，可以直接发布到我们的开发列表[email protected]。但如果您不确定，最好先发布到users@；那里的人可以告诉您您遇到的行为是预期的还是意外的。）

• 如果错误出现在 APR 库中，请将其报告到以下两个邮件列表：[email protected]，[email protected]。

• 如果错误出现在 Neon HTTP 库中，请将其报告到：[email protected]，[email protected]。

• 如果错误出现在 Apache Serf HTTP 库中，请将其报告到：[email protected]，[email protected]。

• 如果错误出现在 Apache HTTPD 2.x 中，请将其报告到以下两个邮件列表：[email protected]，[email protected]。Apache httpd 开发者邮件列表流量很大，因此您的错误报告帖子可能会被忽略。您也可以在https://httpd.apache.ac.cn/bug_report.html提交错误报告。

• 如果错误出现在您的地毯上，请抱抱它，让它保持舒适。

里程碑管理 ¶

问题跟踪器里程碑是 Subversion 开发人员组织工作并与彼此以及 Subversion 用户群进行沟通的重要方面。除了主要用于进行高级问题分类的一些里程碑外，项目的 issue 跟踪器里程碑通常以反映发布版本号及其变体的方式命名。里程碑用于略微不同的目的，具体取决于问题的状态，因此了解这些区别很重要。

问题分类 ¶

当一个问题被提交时，它会进入一个特殊的里程碑 "---"，表示未分配里程碑。这是一个暂存区，问题会在此停留，直到有人有机会查看它们并决定如何处理。

当您按里程碑排序时，未分配里程碑的问题会首先列出，而问题分类是指浏览所有未解决的问题（从未分配里程碑的问题开始），确定哪些问题足够重要需要立即修复，哪些问题可以等到下一个版本再修复，哪些问题是现有问题的重复，哪些问题已经解决等等。对于每个将保持打开状态的问题，还需要确保各种字段设置正确：类型、子组件、平台、操作系统、版本、关键字（如果有）等等。

以下是该流程的概述（在本例中，1.5 是下一个版本，因此紧急问题将被分配到该版本）

    for i in issues_marked_as("---"):
      if issue_is_a_dup_of_some_other_issue(i):
        close_as_dup(i)
      elif issue_is_invalid(i):
        # A frequent reason for invalidity is that the reporter
        # did not follow the "buddy system" for filing.
        close_as_invalid(i)
      elif issue_already_fixed(i):
        version = fixed_in_release(i)
        move_to_milestone(i, version)
        close_as_fixed(i)
      elif issue_unreproducible(i):
        close_as_worksforme(i)
      elif issue_is_real_but_we_won't_fix_it(i):
        close_as_wontfix(i)
      elif issue_is_closeable_for_some_other_reason(i):
        close_it_for_that_reason(i)

      # Else issue should remain open, so DTRT with it...

      # Set priority, environment, component, etc, as needed.
      adjust_all_fields_that_need_adjustment(i)

      # Figure out where to put it.
      if issue_is_a_lovely_fantasy(i):
        move_to_milestone(i, "blue-sky")
      if issue_is_not_important_enough_to_block_any_particular_release(i):
        move_to_milestone(i, "nonblocking")
      elif issue_resolution_would_require_incompatible_changes(i):
        move_to_milestone(i, "2.0-consider")
      elif issue_hurts_people_somewhat(i):
        move_to_milestone(i, "1.6-consider")  # or whatever
      elif issue_hurts_people_a_lot(i):
        move_to_milestone(i, "1.5-consider")
      elif issue_hurts_and_hurts_and_should_block_the_release(i):
        move_to_milestone(i, "1.5")

如何处理安全问题 ¶