錯誤/問題 ¶

如何回報錯誤 ¶

首先，請確定這是一個錯誤。如果 Subversion 沒有按照您的預期運作，請在文件和郵件清單檔案中尋找證據，證明它應該按照您的預期運作。當然，如果這是一個常識性的問題，例如 Subversion 剛剛毀損了您的資料並導致您的顯示器冒煙，那麼您可以相信自己的判斷。但是如果您不確定，請先在使用者郵件清單 users@subversion.apache.org 上詢問，或在 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 的運作方式，並與實際運作方式做對比。雖然對您來說錯誤可能很明顯，但對其他人來說可能並非如此，因此最好避免猜謎遊戲。接著說明環境描述和重現步驟。如果您還想加入對原因的推測，甚至提供修正錯誤的修補程式，那就太好了 — 請參閱修補程式提交指南。

將所有這些資訊發佈到 dev@subversion.apache.org，或者如果您已經在那裡並被要求提交問題，請前往問題追蹤器並按照那裡的說明進行操作。

謝謝。我們知道提交有效的錯誤報告需要花費大量時間，但一份好的報告可以節省開發人員數小時的時間，並讓錯誤更有可能獲得修正。

報告錯誤的地方 ¶

• 如果錯誤出在 Subversion 本身，請將郵件寄送至 users@subversion.apache.org。一旦確認為錯誤，某人（可能是您）可以將其輸入問題追蹤器。（或者如果您對錯誤相當確定，請繼續直接發佈到我們的開發人員清單 dev@subversion.apache.org。但如果您不確定，最好先發佈到 users@；那裡有人可以告訴您遇到的行為是否預期。）

• 如果錯誤出在 APR 函式庫中，請將錯誤回報給以下兩個郵件清單：dev@apr.apache.org、dev@subversion.apache.org。

• 如果錯誤出在 Neon HTTP 函式庫中，請將錯誤回報給：neon@webdav.org、dev@subversion.apache.org。

• 如果錯誤出在 Apache Serf HTTP 函式庫中，請將錯誤回報給：dev@serf.apache.org、dev@subversion.apache.org。

• 如果錯誤出在 Apache HTTPD 2.x 中，請將錯誤回報給以下兩個郵件清單：dev@httpd.apache.org、dev@subversion.apache.org。Apache httpd 開發人員郵件清單流量很大，因此您的錯誤回報貼文可能會被忽略。您也可以在 https://apache-httpd.dev.org.tw/bug_report.html 提交錯誤回報。

• 如果錯誤出在地毯上，請給它一個擁抱，並讓它保持舒適。

里程碑管理 ¶

問題追蹤器里程碑是 Subversion 開發人員如何組織其工作並與彼此和 Subversion 使用者基礎進行溝通的重要面向。除了在執行高階 問題分類 時主要使用的一些里程碑之外，專案的問題追蹤器里程碑通常會命名為反映版本號碼及其變體。里程碑會根據問題的狀態用於略有不同的目的，因此了解這些區別非常重要。

問題分類 ¶

當問題提交時，它會進入特殊里程碑「---」，表示未設定里程碑。這是一個暫存區，問題會保留在其中，直到有人有機會檢視它們並決定如何處理。

當您按里程碑排序時，未設定里程碑的問題會首先列出，而問題分類是瀏覽所有 開放問題（從未設定里程碑的問題開始）的程序，確定哪些問題重要到現在必須修復，哪些可以等到另一個版本，哪些是現有問題的重複，哪些已經解決，等等。對於每個仍保持開放的議題，這也表示必須確保適當地設定各種欄位：類型、子元件、平台、作業系統、版本、關鍵字（如果有）等等。

以下是程序的概觀（在此範例中，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")

如何處理安全性問題 ¶