Replacing Trac with a different bug tracker

作者：David Cournapeau，Stefan van der Walt

一些numpy和scipy的发布管理者对当前的开发工作流程越来越不满意，特别是对于错误跟踪。本文档是暂时解释一些有问题的情况，当前trac限制，以及可以做什么。

Scenario

new release

发布的工作流程大致如下：

• 找到所有已知的回归从上一版本，并解决它们
• 了解自上次发布以来报告的所有错误
• 在回归/阻塞问题中的分类错误/ etc ...，并在相应的路线图，子包和维护人员
• ping子包维护器

大多数这些任务在当前trac中使用的scipy是相当低效的：

• 很难跟踪问题。特别是，每当一个人去trac，我们真的不知道什么是新的，从什么不是。如果你把问题看成电子邮件，当前的情况就好像没有读/未读功能。
• 批处理问题：同时改变几个问题的特性很困难，因为唯一可用的UI是基于Web的。基于命令行的UI对于这种场景更有效率

更一般来说，制作有用的报告是非常尴尬与目前部署的trac。Trac 0.11可以解决这些问题，但它必须比实际部署的版本在scipy网站上更好。找到补丁，旧补丁等问题，并使报告更加流线化，现在是。

subcomponent maintainer

说你是scipy.foo的维护者，那么你最感兴趣的是只获取关于scipy.foo的错误。但是一般团队应该很容易跟随你的工作 - 对于临时用户（例如不是开发人员）来说，也应该很容易地遵循一些新的功能开发速度。

Review, newcoming code

目标是简单的：使酒吧尽可能低，并确保人们知道在每一步中做什么来贡献numpy或scipy：

• 现在，补丁在trac中过长了。当然，缺乏时间是一个大原因；但是新的贡献的过程可以变得更简单
• 它应该是可能的ping只有评论一个numpy / scipy的子集。
• 对补丁感兴趣的人应该可以跟随它的进展。评论，还有“迷你”时间表可能是有用的，特别是对于大规模问题（来自编码POV的巨大问题）。

Current trac limitation

注意：由trac，我们指的是目前部署的。一些更新的版本可能会解决一些问题。

• 多项目支持：我们有三个trac实例，一个用于scipy，一个用于numpy，一个用于scikits。创建帐户，维护和更新每个帐户是一个维护负担。没有人喜欢做这种工作，所以任何可以减轻负担的东西是一个加号。此外，它发生很频繁，对numpy的错误填充scipy trac和反之亦然。你必须手动处理这个，目前。
• 客户端不基于web-ui。这可以通过xmlrpc插件+一些客户端。特别地，像http://tracexplorer.devjavu.com/这样的东西对于喜欢IDE的人来说是很有趣的。至少有一个人表示他希望尽可能多地与Eclipse集成。
• 强大的查询：应该可以快速找到两个版本之间的问题，给定日期的新问题，修补程序的问题，等待审查的问题等...问题数据必须是可定制的，因为大多数错误跟踪不支持审查等事情，所以我们需要自己处理这些（通过标签等...）
• 将问题标记为已读/未读。任何用户都应该可以“屏蔽”问题以忽略它们。
• 票据依赖。这是非常有用的我的经验，大的功能，可以分为几个问题。路线图只能由trac admin创建，并且它们是重量级的。

Possible candidates

Updated trac + plugins

优点：

• 相同的系统
• 在python，所以我们可以黑客它，如果我们想要

缺点：

• Trac旨在是基本的，并扩展与插件。但是大多数插件都坏了，或者不是最新的。关于哪些插件成熟的信息不容易获得。
• 至少scipy.org trac很慢，需要不断重新启动。这是根本不能接受的。

Redmine

优点：

• 支持大多数功能（xmlrpc除外）。多项目等...
• （主观）：我（cdavid）找到开箱即用的redmine体验更愉快。更容易获得更多信息，减少点击次数，更简化。有关示例，请参见http://www.redmine.org/wiki/redmine/TheyAreUsingRedmine
• 转换脚本从trac（没有经​​验，它尚未numpy / scipy）。
• 社区似乎友好，并获得了一大堆功能做

缺点：

• 新系统，不成熟？
• 在Ruby中：因为我们是一个python项目，大多数dev都熟悉python。
• Wiki集成等...？

未知：

• xmlrpc API
• 表演
• 维护成本

Roundup

去做