NEP 6 — 用不同的错误跟踪器替换 Trac #
- 作者：
大卫·库纳波、斯特凡·范德沃尔特
- 地位：
延期
numpy 和 scipy 的一些发布经理对当前的开发工作流程越来越不满意，尤其是错误跟踪。本文档尝试解释一些有问题的场景、当前的 trac 限制以及可以采取的措施。
设想＃
新版本#
发布的工作流程大致如下：
找到上一个版本中所有已知的回归，并修复它们
了解自上次版本以来报告的所有错误
对回归/阻塞问题/等中的错误进行分类，并将它们分配到相应的路线图、子包和维护人员中
ping 子包维护者
大多数这些任务在 scipy 上使用的当前 trac 中效率相当低：
很难跟踪问题。特别是，每次访问 trac 时，我们都不知道什么是新的，什么是旧的。如果您将问题视为电子邮件，那么当前的情况就像没有已读/未读功能。
问题的批量处理：同时更改多个问题的特征很困难，因为唯一可用的 UI 是基于 Web 的。对于这种情况，基于命令行的 UI 效率更高
更一般地说，使用当前部署的 trac 来制作有用的报告非常困难。 Trac 0.11 可以解决这些问题，但它必须比 scipy 网站上实际部署的版本好得多。查找补丁、旧补丁等问题……并制作报告必须比现在更加简化。
子组件维护者#
假设您是 scipy.foo 的维护者，那么您最感兴趣的是仅与 scipy.foo 有关的错误。但一般团队应该很容易跟随您的工作 - 对于临时用户（例如，不是开发人员）也应该很容易跟随一些新功能的开发节奏。
审查，新代码#
目标很简单：使门槛尽可能低，并确保人们知道每一步该做什么来为 numpy 或 scipy 做出贡献：
目前，补丁在 trac 中搁置了太久。当然，时间不够也是一大原因；但跟踪新贡献的过程可以变得更加简单
应该只能对 numpy/scipy 的一个子集的评论进行 ping 操作。
对补丁感兴趣的人应该可以跟踪其进展。评论以及“迷你”时间表可能很有用，特别是对于大量问题（来自编码 POV 的大量问题）。
当前跟踪限制#
注意：trac 是指当前部署的。一些较新的版本可能会解决一些问题。
多项目支持：我们有三个 trac 实例，一个用于 scipy，一个用于 numpy，一个用于 scikit。创建帐户、维护和更新每个帐户都是一项维护负担。没有人喜欢做这种工作，所以任何能减轻负担的事情都是有利的。此外，经常发生针对 numpy 的错误被 scipy trac 填充，反之亦然。目前，您必须手动处理此问题。
客户端不基于 web-ui。这可以通过 xmlrpc 插件 + 一些客户端来完成。特别是，像 http://traceexplorer.devjavu.com/这样的东西对于喜欢 IDE 的人来说可能会很有趣。至少有一个人表达了他希望尽可能多地与 Eclipse 集成的愿望。
强大的查询：应该能够快速找到两个版本之间的问题、给定日期的新问题、补丁问题、等待审核的问题等……问题数据必须是可定制的，因为大多数错误跟踪器不支持诸如评论等之类的事情......所以我们需要自己处理这个问题（通过标签等......）
将问题标记为已读/未读。任何用户都应该可以“掩盖”问题以忽略它们。
票据依赖性。这对我对大功能的体验非常有帮助，这些大功能可以分为几个问题。路线图只能由 trac admin 创建，而且它们是重量级的。
可能的候选人#
更新了 trac + 插件#
优点：
相同系统
在Python中，所以如果我们愿意的话我们可以破解它
缺点：
Trac 的目标是基础，并通过插件进行扩展。但大多数插件都已损坏，或者不是最新的。有关哪些插件成熟的信息不容易获得。
至少 scipy.org trac 很慢，并且需要不断重新启动。这根本不可接受。
Redmine #
优点：
支持大多数功能（除了 xmlrpc？）。多项目等...
（主观）：我（cdavid）发现 redmine 的开箱即用体验更加令人愉快。轻松获取更多信息，点击次数更少，流程更精简。有关示例，请参阅 http://www.redmine.org/wiki/redmine/ TheyAreUsingRedmine
来自 trac 的转换脚本（对于 numpy/scipy 还没有使用经验）。
社区看起来很友好并且完成了很多功能
缺点：
新系统，不太成熟？
in Ruby：由于我们是一个python项目，所以大多数开发人员都熟悉python。
维基整合等……？
未知：
xmlrpc API
表演
维护成本
围捕＃
go做