NEP 6 — 用不同的缺陷追踪器替换 Trac#

作者:: David Cournapeau, Stefan van der Walt
状态:: 延期

NumPy 和 SciPy 的一些发布经理对当前的开发工作流程，特别是缺陷追踪，越来越不满意。本文档旨在解释一些问题场景、当前 Trac 的局限性以及可以采取的措施。

场景#

新发布#

发布的流程大致如下

找出上次发布以来的所有已知回归，并修复它们

了解自上次发布以来报告的所有缺陷

对回归/阻塞性问题等缺陷进行分类，并将其分配到相应的路线图、子包和维护者

提醒子包维护者

在 SciPy 上当前使用的 Trac 中，大部分这些任务都相当低效

很难追踪问题。特别是，每次访问 Trac 时，我们都不知道哪些是新的，哪些不是。如果将问题想象成电子邮件，那么当前情况就像没有已读/未读功能一样。

批量处理问题：同时更改多个问题的特性很困难，因为唯一可用的 UI 是基于网页的。对于此类场景，基于命令行的 UI 效率要高得多

更普遍地说，使用当前部署的 Trac 生成有用的报告非常不便。Trac 0.11 可能会解决其中一些问题，但它必须比 SciPy 网站上实际部署的版本好得多。查找带有补丁、旧补丁等的问题，并生成报告，必须比现在更加流程化。

子组件维护者#

假设你是 scipy.foo 的维护者，那么你主要感兴趣的是只关注与 scipy.foo 相关的缺陷。但是，整个团队应该能够轻松跟踪你的工作——普通用户（例如，非开发人员）也应该能够轻松跟踪新功能开发进度。

审查，新代码#

目标很简单：尽可能降低门槛，并确保人们清楚每个步骤如何为 NumPy 或 SciPy 做出贡献

目前，补丁在 Trac 中停滞太久。当然，时间不足是一个主要原因；但跟踪新贡献的流程可以大大简化

应该可以只针对 NumPy/SciPy 的一个子集进行审查提醒。

对补丁感兴趣的人员应该能够跟踪其进展。评论，以及“迷你”时间线可能会很有用，特别是对于大规模问题（从编码角度来看是大规模的）。

当前 Trac 局限性#

注意：此处提到的 Trac 是指当前部署的版本。一些更新的版本可能会解决部分问题。

多项目支持：我们有三个 Trac 实例，一个用于 SciPy，一个用于 NumPy，一个用于 Scikits。创建账户、维护和更新每个实例都是一项维护负担。没有人喜欢做这类工作，所以任何能减轻负担的都是一个优势。此外，针对 NumPy 的缺陷经常被填写在 SciPy Trac 上，反之亦然。目前，你必须手动处理这些问题。

非基于网页 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#

待办