trac简易指南

trac系统有三大块主要功能:

  • Wiki
  • 码库浏览
  • Ticket

Wiki的功能很快就可以上手,如果没有什么特别需要的排版功能的话,使用上没有问题。如果需要类似重构方案的表现的话,可以参考wiki排版功能以及wiki宏
代码库浏览也没什么好说的,只是一个和SVN的集成
最重要的是Ticket。Ticket中文不好翻译,因为它有底下几种类型(可能还会扩充),但却有共同的属性和操作:描述、优先级、组件、里程碑、版本、分配人员;同时可以被关闭

  • defect,就是bug
  • enhancement,中文我也没有很好的对应翻译,在有些地方也叫做RFE(Request for Enhancement),可以理解成一种需求,对功能扩充的需求。enhancement在社区里出现的情况是这样:用户使用某个软件过程中,发现软件 的功能不够完善,比如不支持某一种格式、操作或者协议,导致程序出现错误的结果。但这种情况又不是bug,因为在开发的过程中并没有犯错,是用户的进一步 要求或者是需求有误的结果。这种情况下就归成了enhancement。区别于defect或者task
  • task 是任务分配。这个也好理解,是一个人在做任务的分配。任务解决了把ticket关闭
  • patch 本来没有的,我后来加上去的,学的sourceforge里的概念。这主要用于用户或者开发人员对程序提交的修正文件。开发人员查看补丁的内容过后关闭这个ticket

下面是ticket的状态图:
http://projects.edgewall.com/trac/attachment/wiki/TracTickets/Trac%20Ticket%20State%20Chart%2020060603DF.png?format=raw
下面以defect为例,描述一个ticket的生命周期:

  1. 客服或者测试人员新建一个ticket,类型为defect,并描述bug的主要问题
  2. 管理人员根据描述的问题,决定是否接受这个defect,或者直接关闭。接受后把ticket分配给开发人员
  3. 开发人员解决了问题,更新了代码,把ticket关闭
  4. 如果客服觉得问题没有解决,reopen这个ticket
  5. 开发人员解决了问题,关闭ticket

其中当有新的ticket出现时或者被分配了新的ticket,开发人员可以通过订阅RSS(已支持)或者email(还要研究怎么配置)得到通知。同时可以通过设定固定的cc地址把所有的ticket归档到邮件列表中。