NEP 6 — 替换 Trac 为不同的 Bug 跟踪器#
- 作者:
David Cournapeau, Stefan van der Walt
- 状态:
Deferred
NumPy 和 SciPy 的一些发布管理员对当前的开发工作流程，特别是 Bug 跟踪方面，越来越感到不满。本文档旨在解释一些存在问题的场景、当前 Trac 的局限性以及可以采取的措施。
场景#
新版本发布#
版本发布的流程大致如下：
找出上一个版本以来的所有已知回归 Bug 并修复它们。
了解自上次发布以来报告的所有 Bug。
对 Bug 进行分类，如回归/阻塞性问题等，并将其分配到相应的路线图、子软件包和维护者。
通知子软件包维护者。
在目前 SciPy 上使用的 Trac 中，这些任务中的大部分都效率低下。
难以跟踪问题。特别是，每次访问 Trac 时，我们都无法真正区分哪些是新问题，哪些不是。如果将问题视为电子邮件，那么当前的情况就像没有已读/未读功能一样。
批量处理问题：同时更改多个问题的特性非常困难，因为唯一可用的界面是基于 Web 的。基于命令行界面在此类场景下效率更高。
总的来说，使用当前部署的 Trac 来生成有用的报告非常麻烦。Trac 0.11 可能会解决其中一些问题，但它必须比 SciPy 网站上当前部署的版本好得多。查找带有补丁的问题、旧补丁等，以及生成报告，必须比现在更加 streamlined。
子组件维护者#
假设你是 scipy.foo 的维护者，那么你主要关心的是只获取与 scipy.foo 相关的 Bug。但对于整个团队来说，跟踪你的工作应该很容易——对于普通用户（例如非开发者）来说，能够关注一些新功能的开发进展也应该很容易。
代码审查，新进代码#
目标很简单：尽可能降低参与门槛，并确保人们知道在每个步骤中应该做什么，以便为 NumPy 或 SciPy 做出贡献。
目前，补丁在 Trac 中滞留时间过长。当然，时间不足是一个主要原因；但是，跟踪新贡献者的流程可以做得更简单。
应该能够仅针对 NumPy/SciPy 的某个子集进行审查时才收到通知。
对此类补丁感兴趣的人应该能够跟踪其进展。评论，以及“迷你”时间线可能很有用，特别是对于大规模问题（从编码的角度来看）。
当前 Trac 的局限性#
注意：这里说的 Trac 指的是当前部署的版本。一些较新版本可能解决了其中一些问题。
多项目支持：我们有三个 Trac 实例，一个用于 SciPy，一个用于 NumPy，一个用于 Scikit。创建帐户、维护和更新每个实例都是一项维护负担。没有人喜欢做这种工作，所以任何可以减轻负担的事情都是有益的。此外，经常发生针对 NumPy 的 Bug 被提交到 SciPy Trac，反之亦然。您必须手动处理这种情况。
非基于 Web 界面的客户端。这可以通过 xmlrpc 插件 + 一些客户端来实现。特别是像 http://tracexplorer.devjavu.com/ 这样的工具可能对喜欢 IDE 的人很有吸引力。至少有一个人表达了希望与 Eclipse 进行尽可能多的集成的愿望。
强大的查询：应该能够快速查找两个版本之间的问题、自给定日期以来的新问题、带有补丁的问题、等待审查的问题等。问题数据必须是可定制的，因为大多数 Bug 跟踪器不支持审查等功能，所以我们需要自己处理（通过标签等）。
标记问题为已读/未读。任何用户还应该能够“屏蔽”问题以忽略它们。
问题依赖关系。在我的经验中，这对于可以分解为几个问题的大型功能非常有用。路线图只能由 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
待办事项