错误报告

来自Ubuntu中文
Happyaron（留言 | 贡献）2009年11月29日 (日) 23:10的版本 （→‎什么时候不需要报告bug）
(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)
跳到导航跳到搜索

Ubuntu 使用 Launchpad 记录和追踪bug，所以在开始报告bug前需要在Launchpad上注册一个帐号。

报告 bug

使用帮助菜单里的“报告一个问题”

如果你想要报bug的程序能够启动运行，那么打开程序的“帮助”菜单，选择“报告一个问题”

这样做是最好的办法之一，因为它可以自动收集程序和系统的信息且上传到相应的位置。
如果程序发生崩溃，尤其是在使用开发版本的Ubuntu时，错误报告程序会自动启动询问是否要提交bug，建议在此时选择提交，以便开发者改进程序。

使用 ubuntu-bug 填写错误报告

如果您处于以下集中情况，可能无法打开帮助菜单：

  • 正在使用服务器版的Ubuntu
  • 程序本身没有错误报告的菜单项
  • 程序根本无法启动
  • 要报告的程序没有图形界面，比如Linux内核或者显卡驱动

这时可以使用 ubuntu-bug 命令来报告。

Ubuntu 8.10 及后续版本


按下 Alt+F2 组合键打开 "运行程序" 窗口，输入ubuntu-bug 软件包名 然后点击“运行”。(如上图)
服务器用户应该使用命令行来确定是哪个软件包出现了问题。

如果要报告错误的程序正在系统中运行，那么可以通过运行 系统 > 系统管理 > 系统监视器，找出该程序的进程ID，服务器用户应该使用 ps aux

系统监视器的进程标签页

这样可以在 Alt+F2 组合键打开 "运行程序" 的应用程序窗口输入这个ID代替软件包名称。

Ubuntu 8.04 LTS

在 Ubuntu 8.04 LTS 中你需要输入的不仅仅是ubuntu-bug，当用软件包名报告时应当输入ubuntu-bug -p 软件包名 (小写的 p)，当用进程ID报告时则为ubuntu-bug -P 进程ID (大写的 P)，其他情况同上。

如果网络连接不可用

如果需要报告的bug造成了网络连接不可用，那么仍然可以通过程序收集相应的信息来到其他可以连接网络的地方进行报告。
在出错系统的一个终端上上运行 apport-cli -f -p 软件包名 ，稍后它会提供一个选项“K: 保存报告文件以便稍后发送或者复制到其他地方(K)”，这时按 K 键。这样一个以 .apport 为后缀的报告文件会保存在 /tmp 目录下，注意这个目录会在重启时被清空，所以需要把文件复制出来。 可以把这个文件复制到其他能联网的地方，再运行 ubuntu-bug -c .apport文件的位置，就可以继续完成报告。

报告翻译错误和国际化支持问题

所有与翻译和国际化支持相关的Bug (l10n和i18n)都应该报告到 Ubuntu Translations (ubuntu-translations) 项目 之下。在这里会有人对bug进行分类和处理。
在报告这类bug的时候需要用到下一节的方法，所以请接着往下读。

以下是应该发送到 Ubuntu Translations 项目 (ubuntu-translations) 的几种问题：

  • 程序中存在未翻译或者翻译错误的地方
  • 软件在 main 仓库中但是在 Launchpad 上找不到如何翻译它
  • 已经在 Launchpad 翻译过的程序没有更新到 Ubuntu 语言包里
  • 你发现在 Launchpad 上有两个翻译模板是相同的
  • Launchpad 上有已经不再需要的翻译模板
  • 拼写检查程序出现错误

以下是应该关联到 Ubuntu Translations 项目 (ubuntu-translations) 的几种问题(操作方法见下节中的图文指南)：

  • 乱码问题
  • 字体问题
  • 输入法问题

在以上三种问题中，如果是中文支持问题，还应该把Ubuntu CJK Testers (ubuntu-cjk-testers)小组加到订阅列表中。


直接在 Launchpad.net 上报告

如果您没有办法使用上述方法报告bug，也可以手工到Launchpad报告。这时您需要找清楚应该向哪个软件包报告bug。通常情况下应该把bug报告到相应软件的源代码包之下。这时可以充分利用Launchpad的搜索功能。
例如我们要向ibus这个软件包报告bug，那么ibus-开头的大多数程序都是由名为ibus的源代码包产生的，那么我们可以访问这样的地址：
https://bugs.launchpad.net/ubuntu/+source/ibus/+filebug?no-redirect
其中的ibus就是我们要报告的软件的源代码包的名字。
如果只是通过网页上点击Report a bug，那么访问的链接是没有后面的 ?no-redirect 的，这样你就会被转接到Ubuntu官方英文文档站点的bug报告页面。

上面提到翻译和语言支持相关的bug应该提交到Ubuntu Translations项目，那就不能使用程序报告，只能使用网页。这时要访问的链接是： https://bugs.launchpad.net/ubuntu-translations/+filebug
不需要再添加 ?no-redirect ，因为跳转只对 Ubuntu 项目本身起作用，其他在Launchpad上的项目都不需要这样做。

如何添加 Bug Task

亦即前面在Ubuntu Translations项目中所提到的“关联”到其他项目，图文指南：
1.首先打开已有的一个bug (图略)
2.点击Also affects project



3.选择要添加Bug Task的项目(即要关联的项目)



4.具体选择项目，可以使用Launchpad的搜索功能，如果知道确切的名称也可以直接填写，比如本例中的ubuntu-translations就是Ubuntu Translations项目的名称



5.最后确认，这一步将显示哪些人会被通知，比如本例中会提示"Ubuntu Translations Coordinators will be notified"。如果没有问题，那么就大胆地确认！

至此就为原bug添加了一个Ubuntu Translations项目的Bug Task。可以重复操作以关联多个项目。

如何关联多个软件包

有时问题不只来自于单独一个软件包，那么应该先通过任意一个包把bug提交上来，然后再按照下面的方法把剩下的软件包关联上： 1.打开已经报告的bug (图略)
2.点击Also affects distribution



3.选择软件包，注意是源代码包，本例中没有改变ibus这个包，实际操作时必须改变



4.最后确认，这一步也是显示哪些人会被通知。如果没有问题，就大胆确认！

至此就为原bug添加了一个关联的软件包。可以重复操作以关联多个软件包。

向已有 bug 添加 Apport 收集的信息

有时需要向已有 bug 添加 Apport 收集的信息，这时只要在 Alt-F2 组合键调出的“运行程序”对话框里输入 apport-collect bug号 即可。

如何描述你要报告的问题

开发者开始修理bug时，会先按照报告里描述的信息来进行测试，试图重现所描述的问题；如果确认问题存在，再通过不断地修改程序来试图修正问题。 可能为了修正一个问题需要运行很多次测试，所以你的报告中要包含以下的信息：

  • 你希望程序应该怎么做(比如说正确显示文件名，或者是应该能正常地处理任务)
  • 实际上程序发生了什么(比如文件名显示乱码了，或者没有正常处理任务却提示了一些警告或者干脆崩溃掉了)
  • 你如何重现这个错误(要详细描述重现的过程，例如第一步是启动程序，然后依次点击、输入什么，到哪一部或者运行大约多长时间程序会出现你所描述的问题)

注意：

  • 如果你的bug描述不能让其他人把错误重复出来，那么它不可能得到解决。如果你实在不知道如何向开发者说明这些问题，那么应该向周围人或者是论坛、邮件列表上寻求帮助。
  • 即使你报告的bug最终发现不是什么问题，只是一些操作或者其他的使用不当，那也不是什么丢脸或者其他严重的问题。这一切最多就是在bug上标记上Invalid，之后就自动在搜索结果里隐藏了，即使是你自己也只能通过找到当初的bug号才可以查到，它不会在任何列表里再出现。
  • 把发现的问题尽可能都报告上去才是正确的选择，即使不小心或者是因为自己不了解报告错了，也比把潜在的问题都等着别人报告好很多。开发者也没有很多是英语母语，而且报告bug也不需要即时的交流，只要把意思表达清楚即可，没有人会问你英语考试得了多少分。
  • 在bug报告中应该尽量写出相关的全部内容，提供尽可能多的信息。在bug的处理过程中正确填写bug是让它快速得到解决的首要条件。
  • 在处理的过程中其他关注的人可能会在bug上留言来提供更多的信息，也可能是开发者询问你一些他需要而你之前没有提供的信息，这时应当积极配合。对bug的回复都会发送到注册Launchpad帐号时所用的电子邮件地址里，回复时可以直接回复通知邮件，也可以打开其中的链接然后通过网页回复。

Bug 的状态

Bug 的状态一共有9种，下面以此做简要解释：

  1. New - 报告bug时的初始状态，代表这个bug需要人来进行最初的查看。查看的人不一定是开发者自己，也可能是一些专门替开发者分类和确认bug的志愿者(bug triager)，或者是其他有兴趣的人。应该尽可能找更多的人来验证你报告的问题，并且到bug上留下评论，哪怕只是一句"I can confirm this."
  2. Incomplete - 开发者或者是其他人认为bug描述不完整，在标记为这个状态的同时向提交bug的人提问他们还需要知道哪些信息。处于这个状态的bug如何60天内没有活动就会自动过期。
  3. Invalid - 被标记为这个状态的bug说明报告的问题不存在，或者与特定的项目、软件包无关。以后该bug不会出现在一切搜索结果里，只有通过确切的bug号，或者是查看特定软件包曾经被报告的全部bug时才能看到，因此它不会出现在报告者或者其他参与者的bug列表里。
  4. Won't Fix - 开发者觉得没有意义修复的问题，比如即将有大的版本升级且新的版本里已不再受此问题影响。
  5. Confirmed - 这个状态是比较常见的状态，也就是bug被确认存在。如果报告者十分自信也可以自己把状态改变为这个。如果你看到别人提交的bug，而且确认自己这里也有同样的问题，那么可以毫不犹豫地把状态切换到这里。
  6. Triaged - bug已经看过，这代表着一个专门的小组已经有人看过此问题，并且可能已经以某些方式联系了相关的人，但是他们暂时无法确定bug的状态。遇到bug被标记为这个状态，应该做的是找更多的人验证你的bug并且留下评论，但不要轻易把状态更改。
  7. In Progress - 开发者或相关的人员正在处理问题，能做的只有等待，以及随时配合开发人员可能的提问。实际在这种状态下，开发人员可能已经不再需要问很多问题了。
  8. Fix Committed - 修改已经提交，但是还没有随更新发布。这时只能等待。
  9. Fix Released - 修改已发布。应该在这时赶快验证问题是否真的解决了，如果没有解决就赶快去把状态改回Confirmed并且留言说"This problem still persist." 要注意的是可能标记released的时候因为服务器同步还会有些延迟，也不要过早地去验证然后就下结论说没解决。

Bug 的重要程度

Bug 通常会被定义一个重要程度，下面依次介绍：

  1. Critical - 非常严重的bug，会因此影响到大多数用户的正常使用
  2. High - 严重的bug，会因此影响很多用户，并导致其中相当数量的人不能正常使用或使用困难
  3. Medium - 最常见的重要程度，会影响一部分用户，但不至于使一切完全停顿或非常艰难
  4. Low - 重要度较低，比如翻译错了一个单词
  5. Wishlist - 希望实现的事，自然重要程度最低

Bug分配、Milestone和指定Release

Bug 有“Assigned to”和“Milestone”，另外还有一个“Nominate for release”，下面分别简要介绍：

  • Assigned to 下的就是指派谁解决这个问题，被指派者就是所谓的 Assignee，除非你知道自己在做什么，否则不要随意修改这个项。更不要把自己作为 Assigned to 的对象(Assignee)，那样就几乎不会有人理你了，因为你说你能为大家解决这个问题。
  • Milestone 是指目标到什么时候解决这个问题，很多时候这项是空的。临近发布的时候一般会被设置，只有专门的小组才能设置此项。
  • Nominate for release 是说你指定这个问题出现在哪个特定的发行版本里，比如 Nominated in Karmic 代表这个问题出现在9.10中。

Bug订阅

Bug 的右侧有一列订阅列表，如下图：



如果你想要订阅这个bug，点第一行的"Subscribe"；如果你想把别人添加到订阅列表，点第二行的“Subscribe someone else”。不要滥用第二种情况，你必须明确知道这样做是对的才能这么做。
Subscribers是订阅者列表，这里的人都是通过以上两种方式订阅的；“Also notified”是订阅了该软件包或者该项目的人或小组，他们会收到关于该软件包或项目的全部bug报告信息，比如简体中文小组就订阅了全部中文语言包的bug。如果有下面要说到的重复的bug，那么在以上两者之间还会多出一项"From duplicate"，其中包含来自于和当前bug重复的那些bug的订阅者们。

Bug标签(Tag)

Bug标签和我们博客里的标签用途相似，是用来过滤同一类bug的，官方使用的标签可以在这个列表里找到，里面描述了每个标签的作用，以及什么时候使用它们：
常见的Bug标记(Bug Tags)
对于Ubuntu Translations项目，还有一套附加的Bug标记和处理办法：
HandlingBugs

重复的Bug

重复报告Bug是不可能完全避免的事，一旦发生了重复的bug报告，那么可以把重复的多个bug合并为一个处理。

  • 标记重复，在bug报告页右侧找到入下左图所示位置，点击红圈处，在弹出的地方输入准确的重复bug的号码。



  • 已经被标记与当前bug重复的其他bug，依然在bug报告页的右侧，可以看到如上中图的位置。
  • 当前bug是其他bug的一个重复品，状态会分别显示在右侧(如上右图)和评论栏上方(如下图)


什么时候不需要报告bug

  • 需要帮助 那么应该到 Launchpad 上提一个 Question，到 中文论坛发个帖子，或者是到#ubuntu-cn IRC 频道询问，以及发送邮件到 ubuntu-zh 邮件列表请教。
  • 特性和政策讨论 和 开发设想 应该到 ubuntu-zh 或 ubuntu-devel-discuss 邮件列表讨论。
  • 已经有人填写了bug - 如果已经有人填写了同样问题的bug报告，那么你只需要在bug上留言说明自己也遇到了同样的问题，如果觉得其他人有哪些没有说明的还应该进一步补充。也许你的一句"I can confirm this"就会让开发者和其他人注意到这个bug，那么它可能就会吸引更多的目光，并更快地被解决。

仍然对报告错误有疑惑

如果读了上述内容还不能满足你需要的信息，那么有以下几个办法让你获得进一步的帮助“

以下是英文的资源：

其他参考信息

取自“https://wiki.ubuntu.org.cn/index.php?title=错误报告&oldid=134800”