跟踪器讨论

来自 PostgreSQL wiki
跳转到导航跳转到搜索

这只是一个空间，用来倾倒一些在现已停用的跟踪器列表中讨论过，但没有真正官方性质的东西。

有关我们测试跟踪器的信息，请参阅 Tracker:BugzillaTest。

讨论要点

这是对 pgsql-hackers 线程中 提出的主要观点的总结。

需求

按大体接受程度排序

  • 免费/开源软件（PE）
  • 必须运行在 PostgreSQL 上（GSM）
  • 必须具有电子邮件界面（GSM）
    • 提供将抄送或转发邮件转换为错误报告的界面（SK）
  • 通过网页界面，将状态与每个错误相关联（RH）
    • 建议的状态：“打开”、“已修复”、“非错误”、“不会修复”（RH）
  • 给出错误编号，在 pgsql-bugs 中查找其主题行中提及该编号的邮件（RH）

问题（含一些回复）

  • 人们在 网页界面 或邮件列表 pgsql-bugs 之外报告错误。如何跟踪这些错误？(TGL)
    • 由经验中等的用户进行初步分类 (BJ) [隐含意义：并非所有内容都需要跟踪]
    • 如果有合理的跟踪器，许多黑客/用户会注册（PE）
    • 一个“经验中等的用户”可以将电子邮件的副本转发到错误跟踪器，以便对其进行跟踪。
  • 谁来维护它？(TGL)
    • “错误管理员”每天可以花 20 分钟（BJ）

当前情况的弊端

根据 Greg Sabino Mullane 的说法

  • 无法搜索以前的/现有错误
  • 无法了解错误的状态
  • 无法对错误进行分类和分组（按版本、平台、组件、严重程度等）
  • 无法知道谁正在处理错误
  • 无法防止错误被遗漏

“购买”选项短名单

由 Peter Eisentraut 从维基百科列表中提出。包括实现语言、许可证以及是否没有电子邮件界面（根据维基百科）。

其他提及，由 Chris Browne 提出

  • Fossil：SCM + 错误跟踪、C、BSD、SQLite
  • SD (Simple Defects)：P2P 错误跟踪器、Perl、MIT、SQLite 或 FS 后端
  • Bugs Everywhere：分布式错误跟踪器、Python、GPL，使用 DVCS 存储
  • debbugs：Perl、GPL、Berkeley DB，主要交互界面是电子邮件

先前内容

根据需要合并。

基本标准

基本技术和操作需求

  • 必须在常用的 Unix 平台上工作
  • 必须支持 PostgreSQL 作为后端
  • 必须不需要/只需要最少的自定义工作才能被社区采用
  • 必须具有社区登录集成

错误和问题的管理

需求（是/否/可选） Bugzilla 3.0
创建错误 是 是
通过网页界面创建错误 可选 是
通过邮件界面创建错误 是 是
通过外部界面创建错误 可选 是
查询打开的错误的能力 是 是
通过网页界面查询打开的错误的能力 是 是
通过外部界面查询打开的错误的能力 是 是（SOAP/XML-RPC）
查询历史错误数据的能力 是 是
更改/设置错误状态的能力 是 是
设置和跟踪处理特定错误的人员的能力 是 是
按严重程度和版本对错误进行分类的能力 是 是
对错误列表进行审核的能力（在评估人员接受之前不公开列出） 是 ?
对错误报告进行全文搜索 是 ?
链接到源代码控制系统事件 可选 ?

功能请求的管理

需求（是/否/可选） Bugzilla 3.0
创建功能请求 是 是
通过网页界面创建功能请求 是 是
通过邮件界面创建功能请求 是 是
通过外部界面创建功能请求 可选 是（SOAP/XML-RPC）


记录保存

  1. 以某种方式捕捉有关功能请求的讨论
  2. 以某种方式捕捉有关功能请求的邮件列表讨论的链接
  3. 拒绝功能请求的能力（出于历史目的）
  4. 功能请求/讨论与触发该请求的错误之间的链接

开发者易用性

  1. 访问系统的低开销
  2. 电子邮件界面
    包括通过电子邮件执行以下操作的能力
    1. 创建错误
    2. 更改错误状态
    3. 将错误与修复它的 Postgres 版本相关联
    4. 将错误与修复它的提交相关联
    5. 将讨论错误的电子邮件线程与错误相关联
  3. 以某种方式上传内容（设计计划等）
  4. 将故障报告轻松链接在一起的方法
  5. 清晰的划分（即正好数量的类别、模块等）
  6. 使用方法一目了然（开始使用不需要太多工作）
  7. 可以被“专家”使用（例如，不会让工具变得太愚蠢，以至于经验丰富的用户每次都需要点击 43 个东西。）
  8. 至少与 CVS 一样可靠
  9. 灵活“分类”工作设施

社区成员易用性

  1. 网页界面
  2. 有关错误的沟通是规律的且易于理解的（不会出现“报告/请求到黑洞”的情况）

“非社区成员”易用性（例如新用户、不定期关注邮件列表的用户等）

  1. 错误报告很容易创建（不需要创建帐户才能提交错误）。
取自“https://wiki.postgresql.ac.cn/index.php?title=TrackerDiscussion&oldid=17559”