NEP 6 — 使用不同的缺陷跟踪器替换 Trac#
- 作者:
David Cournapeau, Stefan van der Walt
- 状态:
已延迟
NumPy 和 SciPy 的一些发行版管理人员越来越不满于当前的开发工作流程，特别是对于缺陷跟踪。本文档尝试解释一些问题场景、当前 Trac 的局限性以及可以采取的措施。
场景#
新版本#
版本的流程大致如下：
查找自上次发布以来所有已知的回归问题，并修复它们。
了解自上次发布以来报告的所有缺陷。
对回归/阻塞问题/等进行分类，并在相应的路线图、子包和维护人员中分配它们。
通知子包维护人员。
在当前 SciPy 使用的 Trac 中，大多数这些任务效率都非常低。
很难跟踪问题。特别是，每次访问 Trac 时，我们实际上并不知道什么是新的，什么不是新的。如果你将问题视为电子邮件，那么当前的情况就像没有已读/未读功能一样。
批量处理问题：同时更改多个问题的特性很困难，因为唯一可用的 UI 是基于 Web 的。基于命令行的 UI 对于这种情况效率更高。
更一般地说，使用当前部署的 Trac 制作有用的报告非常笨拙。Trac 0.11 可能会解决这些问题中的一些，但它必须比 SciPy 网站上实际部署的版本更好得多。查找带有补丁、旧补丁等的问题以及制作报告必须比现在更加简化。
子组件维护人员#
假设你是 scipy.foo 的维护人员，那么你主要感兴趣的是只获取有关 scipy.foo 的缺陷。但是，对于整个团队来说，跟踪你的工作应该很容易——对于普通用户（例如，非开发人员）来说，跟踪一些新功能的开发进度也应该很容易。
审查，新代码#
目标很简单：将门槛降到最低，并确保人们知道在每个步骤中应该做什么才能为 NumPy 或 SciPy 作出贡献。
现在，补丁在 Trac 中停留的时间过长。当然，时间不足是一个主要原因；但是，跟踪新贡献的过程可以简化很多。
应该可以只针对 NumPy/SciPy 的子集收到审查通知。
对补丁感兴趣的人应该能够跟踪其进度。评论以及“迷你”时间线可能会有用，特别是对于大型问题（从编码角度来看是大型问题）。
当前 Trac 的局限性#
注意：Trac 指的是当前部署的版本。一些更新的版本可能会解决一些问题。
多项目支持：我们有三个 Trac 实例，一个用于 SciPy，一个用于 NumPy，一个用于 Scikits。创建帐户、维护和更新每个帐户都是维护负担。没有人喜欢做这种工作，因此任何可以减轻负担的事情都是一个好处。此外，针对 NumPy 的缺陷经常在 SciPy Trac 上填写，反之亦然。目前，你必须手动处理这个问题。
不是基于 Web UI 的客户端。这可以通过 xmlrpc 插件 + 一些客户端来实现。特别是，像 http://tracexplorer.devjavu.com/ 这样的东西对于喜欢 IDE 的人来说可能很有趣。至少有一人表达了他希望尽可能多地与 Eclipse 集成的愿望。
强大的查询：应该能够快速查找两个版本之间的发行版、给定日期以来的新问题、带有补丁的问题、等待审查的问题等。问题数据必须是可定制的，因为大多数缺陷跟踪器不支持像审查这样的东西，因此我们需要自己处理这个问题（通过标签等）。
将问题标记为已读/未读。任何用户也应该能够“屏蔽”问题以忽略它们。
工单依赖关系。根据我的经验，这对于可以拆分为多个问题的重大功能非常有帮助。路线图只能由 Trac 管理员创建，它们有点重量级。
可能的候选者#
更新的 Trac + 插件#
优点
相同的系统
使用 Python，因此如果需要，我们可以对其进行修改。
缺点
Trac 的目标是基础，并通过插件进行扩展。但是大多数插件都已损坏或未更新。有关哪些插件成熟的信息不容易获得。
至少 scipy.org 的 Trac 速度很慢，需要不断重启。这根本不可接受。
Redmine#
优点
支持大多数功能（除了 xmlrpc？）。多项目等。
（主观）：我（cdavid）发现 Redmine 的开箱即用体验更令人愉快。更容易获得更多信息，更少的点击次数，更简化的流程。有关示例，请参见 https://redmine.ruby-lang.org.cn/wiki/redmine/TheyAreUsingRedmine
来自 Trac 的转换脚本（对于 NumPy/SciPy 还没有经验）。
社区看起来很友好，并且完成了很多功能。
缺点
新的系统，不太成熟？
使用 Ruby：因为我们是 Python 项目，所以大多数开发人员都熟悉 Python。
Wiki 集成等？
未知
xmlrpc API
性能
维护成本
Roundup#
待办事项