NEP 6 — 以不同的錯誤追蹤器取代 Trac#
- 作者:
David Cournapeau, Stefan van der Walt
- 狀態:
延遲
numpy 和 scipy 的一些發布管理員越來越不滿意目前的工作流程，特別是在錯誤追蹤方面。本文件試圖解釋一些有問題的情境、目前的 trac 限制，以及可以如何處理。
情境#
新版本發布#
版本發布的工作流程大致如下：
找出上次版本發布以來的所有已知回歸錯誤，並修復它們
了解自上次版本發布以來報告的所有錯誤
分類回歸錯誤/阻礙問題/等等的錯誤，並將它們分配到相應的藍圖、子套件和維護者。
聯絡子套件維護者
在 scipy 上使用的目前 trac 中，這些任務大多效率很低。
很難追蹤問題。特別是，每次進入 trac，我們都不太清楚哪些是新的，哪些不是。如果你把問題想成電子郵件，目前的情況就像沒有已讀/未讀功能。
批次處理問題：同時更改多個問題的特性很困難，因為唯一可用的 UI 是基於網頁的。對於這種情境，基於命令列的 UI 效率更高。
更廣泛地說，使用目前部署的 trac 產生有用的報告非常笨拙。Trac 0.11 可能會解決這些問題，但它必須比 scipy 網站上實際部署的版本好得多。尋找帶有修補程式的問題、舊修補程式等等，以及製作報告必須比現在更流暢。
子組件維護者#
假設你是 scipy.foo 的維護者，那麼你主要感興趣的是只接收關於 scipy.foo 的錯誤。但一般團隊應該可以輕鬆追蹤你的工作 - casual 使用者（例如，非開發人員）也應該可以輕鬆追蹤一些新功能的開發進度。
程式碼審查，新提交的程式碼#
目標很簡單：盡可能降低門檻，並確保人們知道在每個步驟中該做什麼來貢獻 numpy 或 scipy。
目前，修補程式在 trac 中擱置太久。當然，缺乏時間是一個主要原因；但追蹤新貢獻的過程可以變得更簡單。
應該可以只針對 numpy/scipy 的子集接收審查通知。
對修補程式感興趣的人應該可以追蹤其進展。評論，以及「迷你」時間軸可能很有用，特別是對於大型問題（從程式碼的角度來看是大型的）。
目前 trac 的限制#
注意：trac 指的是目前部署的版本。一些較新的版本可能會解決其中一些問題。
多專案支援：我們有三個 trac 實例，一個用於 scipy，一個用於 numpy，一個用於 scikits。建立帳戶、維護和更新每個帳戶都是維護負擔。沒有人喜歡做這種工作，所以任何可以減輕負擔的事情都是加分項。此外，numpy 的錯誤經常在 scipy trac 上填寫，反之亦然。目前你必須手動處理這些情況。
不是基於網頁 UI 的客戶端。這可以透過 xmlrpc 外掛程式 + 一些客戶端來實現。特別是，對於喜歡 IDE 的人來說，像 http://tracexplorer.devjavu.com/ 這樣的东西可能很有趣。至少有一個人表示他希望盡可能與 Eclipse 整合。
強大的查詢：應該可以快速找到兩個版本之間的 issue、指定日期以來的新 issue、帶有修補程式的 issue、等待審查的 issue 等等。issue 資料必須是可自訂的，因為大多數錯誤追蹤器不支援審查之類的功能，因此我們需要自行處理（透過標籤等等）。
將 issue 標記為已讀/未讀。任何使用者也應該可以「遮罩」 issue 以忽略它們。
ticket 依賴性。根據我的經驗，這對於可以拆分成多個 issue 的大型功能非常有幫助。藍圖只能由 trac 管理員建立，而且它們有點笨重。
可能的候選方案#
更新後的 trac + 外掛程式#
優點
相同的系統
用 Python 寫成，所以如果我們想 hack 它的話就可以。
缺點
Trac 的目標是基礎功能，並透過外掛程式擴展。但大多數外掛程式都已損壞，或未更新。關於哪些外掛程式成熟的資訊不容易取得。
至少 scipy.org 的 trac 很慢，而且需要不斷重新啟動。這簡直無法接受。
Redmine#
優點
支援大多數功能（除了 xmlrpc？）。多專案等等…
（主觀地說）：我 (cdavid) 覺得 Redmine 的開箱即用體驗更令人愉快。更多資訊更容易取得、更少的點擊、更流暢。請參閱 https://redmine.dev.org.tw/wiki/redmine/TheyAreUsingRedmine 以取得範例。
從 trac 轉換的腳本（目前還沒有 numpy/scipy 的經驗）。
社群似乎很友善，並且完成了許多功能。
缺點
新系統，較不成熟？
用 Ruby 寫成：由於我們是一個 Python 專案，大多數開發人員都熟悉 Python。
Wiki 整合等等…？
未知
xmlrpc API
效能
維護成本
Roundup#
待辦事項