# 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。