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#

待办事项