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