# Appendix?B.?自由Bug跟蹤系統
無論項目使用哪個bug跟蹤系統,某些開發者總會有些抱怨。在這一點上bug跟蹤系統比其他標準開發工具更具代表性。我想這是因為bug跟蹤系統是這樣可視化和可交互,可以輕松的想象出一個人可以做的改進(如果某人有時間),并說出這些改進的描述。把這些不可避免的抱怨當作可信也可疑的吧—下面說的跟蹤系統都已經足夠好了。
在這個列表中,”問題(issue)“用于代表跟蹤系統跟蹤的條目。但是請牢記每個系統都會有自己的屬于,對應的術語包括”制品(artifact)“或”bug“或其它。
### **Bugzilla**?—?[http://www.bugzilla.org/](http://www.bugzilla.org/)
Bugzilla非常流行,活躍的維護中,看起來讓它的用戶都很快樂。我曾經有四年在工作中使用了一個修改的變種,很喜歡它。它并不能高度的自定義,而是以一種可以看作其特性的古怪方式:Bugzilla看起來和它創建時差不多,意味著許多開發者已經習慣了它的界面,而且感覺它位于熟悉的版圖。
### **GNATS**?—?[http://www.gnu.org/software/gnats/](http://www.gnu.org/software/gnats/)
GNU GNATS是最古老的開源bug跟蹤系統之一,被廣泛使用。它最大的長處是界面的多樣性(可以僅僅通過瀏覽器,也可以通過郵件或命令行工具),以及純文本問題存儲。所有問題數據以文本文件存放在磁盤上這一事實,使我們可以輕松的編寫自定義工具獲取并解析數據(例如,生成統計報告)。GNATS也可以用多種方法自動吸收郵件,并根據郵件頭的模式將其加入到合適的問題中,使得對于用戶/開發者的對話的記錄非常簡單。
### **RequestTracker (RT)**?—?[http://www.bestpractical.com/rt/](http://www.bestpractical.com/rt/)
RT的網站說”RT是一個企業級問題系統,可以讓一組人智能和有效的管理任務、問題和一個團隊的用戶提交的請求,以及所有的匯總。“RT有一個相對優美的web界面,也有相當廣泛的安裝基礎。界面在視覺上有些復雜,但當你熟悉后就不會覺得那么亂了。RT的許可證是GNU GPL(出于某些原因,他們的web站點說的并不是那么清楚)。
### **Trac**?—?[http://trac.edgewall.com/](http://trac.edgewall.com/)
Trac不僅僅是一個bug跟蹤系統了,它也是一個集成wiki的bug跟蹤系統。它使用wiki鏈接來關聯問題、文件和版本控制變更集和wiki頁面。它也很易于設置,并與Subversion集成(見[Appendix?A, *自由版本控制系統*](# "Appendix?A.?自由版本控制系統"))。
### **Roundup**?—?[http://roundup.sourceforge.net/](http://roundup.sourceforge.net/)
Roundup相對來說很易于安裝(只需要Python 2.1或更高版本),而且很簡單。它包括web,email和命令行接口。問題數據模板、web接口和部分狀態轉換邏輯是可以自定義的。
### **Mantis**?—?[http://www.mantisbt.org/](http://www.mantisbt.org/)
Mantis是一個基于web的bug跟蹤系統,由PHP編寫,并使用MySQL數據庫作為存儲。它擁有你所期望的特性。個人來見,我覺得web界面非常干凈、本能,看起來很簡單。
### **Flyspray**?—?[http://www.flyspray.org/](http://www.flyspray.org/)
Flyspray是一個使用PHP編寫的基于web的bug跟蹤系統。它的網頁將其描述為“非復雜的”,特性列表包括:支持多種數據庫(目前支持MySQL和PGSQL);多項目;‘關注’任務,包括發生變更時提醒(通過email或Jabber);復雜的任務歷史;CSS主題;文件附件;高級搜索特性(簡單易用);RSS/Atom供稿;wiki和純文本輸入;表決;依賴圖表。
### **Scarab**?—?[http://scarab.tigris.org/](http://scarab.tigris.org/)
Scarab是一個高度可自定義的,完全特性的bug跟蹤系統,提供了其他bug跟蹤系統所支持的特性的組合:數據條目、查詢、報告、相關方通知、評論的交互式累加和依賴跟蹤。
它是通過管理web網頁實現的。在單個Scarab安裝中你可以有多個“模塊”(項目)。在給定模塊中,你可以創建新的問題類型(缺陷、改進、任務和支持請求等)。并可以增加任意屬性,以滿足你的項目特定需求。
2004末,Scarab已經接近于1.0發布版本。
### **Debian Bug跟蹤系統(DBTS)**?—?[http://www.chiark.greenend.org.uk/~ian/debbugs/](http://www.chiark.greenend.org.uk/~ian/debbugs/)
Debian Bug跟蹤系統的不尋常之處在于所有問題的輸入和處理都是通過郵件完成:每個問題都有自己的專用郵件地址。DBTS的擴展性很好:例如[http://bugs.debian.org/](http://bugs.debian.org/)有277,741個問題。
因為交互是通過普通的郵件客戶端,這個大多數人都熟悉并可以輕松訪問的工具完成的,DBTS非常適合處理需要快速分類和響應的大規模數據。當然也有缺點。開發者需要花費時間學習郵件命令系統,用戶必須在沒有引導他們選擇編寫信息的web表單的情況下編寫bug報告。也有工具可以幫助用戶發送更好的bug報告,例如命令行。**reportbug**程序或Emacs的包`debbugs-el`。但大多數用戶不會使用這個工具;他們只會手工編寫郵件,他們可能有,也可能沒有遵循你的項目所發布的bug報告指南。
DBTS有一個只讀的web界面,用于查看和查詢問題。
### **Trouble-Ticket Trackers**
這更像是一個面向服務臺的問題跟蹤系統,而不是軟件bug跟蹤。你或許可以在普通的bug跟蹤中正常工作,但是因為完整性這里要列出,因為可以理解某個非同一般的項目可能更需要一個trouble-ticket系統,而不是傳統的bug跟蹤。
-
**WebCall**?—?[http://myrapid.com/webcall/](http://myrapid.com/webcall/)
-
**Teacup**?—?[http://www.altara.org/teacup.html](http://www.altara.org/teacup.html)
(Teacup好像已經不再繼續開發了,但是還有下載。請注意它同時擁有web和郵件界面。)
### **Bluetail Ticket Tracker (BTT)**?—?[http://btt.sourceforge.net/](http://btt.sourceforge.net/)
BTT算是處于標準trouble-ticket tracker和bug跟蹤之間。它提供了隱私特性,這在開源bug跟蹤中并不常見:系統的用戶被分為Staff、Friend、Customer或Anonymous,取決于不同的類別,會有或多或少的數據。它提供了一些郵件集成,一個命令行界面和將郵件轉化為問題的機制。它也提供了一種維護與特定問題不相關信息的特性,例如內部文檔或FAQ。
- 前言
- 為什么寫這本書?
- 誰應該讀本書?
- 資料來源
- 致謝
- 免責聲明
- 1. 介紹
- 歷史
- 現狀
- 2. 起步
- 從你擁有的開始
- 選擇許可證并應用
- 設置風格
- 通告
- 3. 技術基礎設施
- 一個項目需要什么
- 郵件列表
- 版本控制
- Bug跟蹤
- IRC / 實時聊天系統
- RSS供稿
- Wikis
- 網站
- 4. 社會和政治的基礎架構
- 慈善獨裁者
- 共識為基礎的民主(Consensus-based Democracy)
- 寫下所有的內容
- 5. 金錢
- 參與的類型
- 長期雇傭
- 作為一些個體出現,而不是一個整體
- 公開你的動機
- 錢不能讓你可愛
- 契約
- 資助非編程活動
- 市場營銷
- 6. 交流
- 人如其文
- 避免常見的陷阱
- 刺兒頭
- 處理成長
- Bug跟蹤系統中無對話
- 公開性
- 7. 打包、發布和日常開發
- 版本號
- 發布分支
- 穩定發布版本
- 打包
- 測試和發布
- 維護多發布線
- 發布和日常開發
- 8. 管理志愿者
- 從志愿者中獲取最多
- 像分擔技術任務一樣分擔管理任務
- 轉化
- 提交者
- 榮譽
- 分叉
- 9. 許可證,版權和專利
- 術語
- 許可證的方面
- GPL和許可證兼容性
- 選擇一個許可證
- 版權分配和所有權
- 雙許可證模式
- 專利
- 深入資源
- A. 自由版本控制系統
- B. 自由Bug跟蹤系統
- C. 為什么我要關注車棚的顏色?
- D. 報告bug的樣例指導
- E. 版權