4. Bugs 报告与功能加强要求
上一页 | 4. Bugs 报告与功能加强要求 | 下一页

## 4. Bugs 报告与功能加强要求

不幸的是，任何版本的 GIMP 都不是十分完美，更糟糕的是，也没有一个版本看上去象。尽管花费了许多精力使其中所有东西都能工作，但像 GIMP 这样复杂的程序难免有时会出现问题，甚至是崩溃。

Bugs 无法避免的事实并不意谓着就接受它了。如果您找到了 GIMP 中的 Bug，开发者愿意知道并至少试着去修复它。

当您找到一个 Bug，或至少您认为自己找到了：尝试做某个操作，但结果出乎意料。您该这么做？如何报告它？

| 注意
功能加强要求是告诉开发者添加一些没有的特性，其步骤和报告 Bug 基本相同，只是在相应阶段用“enhancement”标记该报告，下面会进行介绍。

和其它许多自由软件项目一样，GIMP 也使用叫作 Bugzilla 这种会 Bug 报告机制。这是一种非常强大的系统，它能够管理上百个 Bug 报告而不会丢失线索。实际上，GIMP 与整个 Gnome 项目共享同一个 Bugzilla 数据库。Gnome Bugzilla 现有 148632 个 Bug 报告。不，这里是第 148633 个。

### 4.1. 确认是个 Bug

在报告 Bug 之前首先需要做的就是花点时间验证您所碰到的是不是一个真正的 Bug。虽然很难给出一个在各种情况下都适用的确认 Bug 的方法，但阅读文档，在 IRC 或邮件列表上讨论通常是非常有帮助的。当您碰到崩溃而不是偶然的不正常时，则它是一个真正 Bug 的机率就比较高：健壮的软件程序在任何情况下都不应该崩溃。不管怎么说，在您花了一定时间都无法确定它是不是真正 Bug 时也没关系，可以直接报告它：不过这会浪费开发者团队一些时间。

| 注意
实际上有些操作已知会导致 GIMP 崩溃，不过要修复它们非常困难而不值得。其中一个就是让 GIMP 进行需要大量内存的操作，比如创建一个百万像素的图像。

还应该确认使用的是最新的 GIMP 版本：报告已经被修复的 Bug 是浪费每个人的时间。(GIMP 1 已经没有维护了，因此使用它并发现 Bug 时，只能自己通过其它办法解决或升级到 GIMP 2。)特别是在使用 GIMP 开发版本时，在报告 Bug 前要确认使用的是最近发行的。

在经过上面这些思考后，如果还有 Bug 报告和功能加强要求，下一步就是到 GIMP Bugzilla 查询网页 (http://bugzilla.gnome.org/query.cgi)，寻找是否有人已经报告了相同的问题。不过该网页有些过于复杂，下面有些基本的介绍：

Summary:(摘要)

  将这里设为“contains any of the words/strings”。

(相连的输入区域)

  在这里输入一个或多个单词，它会到其它人的 Bug 报告的一句话摘要中查询。比如，如果 GIMP 是由于缩放太多而崩溃，就可以输入“zoom”进行查询。

Product:(项目)

  将这里设为“GIMP”

Component:(组件)，Version:(版本)，Target:(目标)

  这里不需要设置

Text information:(文字信息)

  现在不必管这里。当搜索后没有结果返回时，可能就有必要在“comment”区域输入您所要搜索的，不过其结果常常要么是很多，要么是什么都没有。

Status:(状态)

  该区域显示 Bug 报答的当前状态：是仍然开放，还是已经解决等。不过您可能想看所有相关 Bug 报告，而不管其状态，可以按住鼠标在所有项上拉动。

当上面设置完毕后，点击顶部或底部的“Search”按钮;它们都一样。得到的结果要么是 Bug 报告列表(希望不会太长)，要么出现一条“Zarro boogs found”的消息。通过这种方式如果没有找到相关 Bug 报告，可以用其它关键词再进行一次搜索。也许您费了九牛二虎之力，其结果却是“Duplicate(重复)”，这时也不必太失望：该文档的作者几乎每天都使用 GIMP Bugzilla，但这种事也常常发生。

上一页 | 上一级 | 下一页
3. GIMP 的历史 | 起始页 | 4.2. 报告 Bug