[ 教学 ] 如何汇报 bug(使用 bugzilla)

前言

历来中文区提交的 bug 数量都非常之少,少到可以忽略不计的地步。

因为他们更倾向于「找人」、「去论坛哭诉」、「去贴吧痛骂」,一片同仇敌忾的大好局面,然后…bug 不来不去。(当然这不是种族优越论,老外也会这么做,只不过他们去抱怨的地方比较靠谱:邮件列表,G+ openSUSE 社群,直接能接触到开发者,而我们更倾向于找一个「靠山」,让这个靠山来给你过一倒手。)

这本质上说是一种内心不够强大的表现(当然也不能太强大,太强大就完全不抱怨地跟 bug 一起过了…),或者说脸皮不够厚(怕鸡同鸭讲啊、怕英文不好丢人啊,但你要知道,openSUSE 不像别的发行版,我们的母语其实是德文,回复你那位就不怕鸡同鸭讲吗?还有英文不练永远不好),或者说患得患失(我这算不算一个 bug?算与不算不是你说就算的,要开发者来鉴定,bugzilla 上有一个分类叫做 invalid),或者说封闭倾向(我天朝地大物博,还内部消化不了一个 bug?但是开源的精神就是:即使内部能消化,也要公开化。最终还是要有个人把那个 fix 提交,既然如此,为什么要麻烦我们本来基数就不大的讲中文的开发者呢。只有越封闭落后的地方,「开眼看世界」的桥梁纽带才越多,然后桥梁纽带的自利心理又会去阻止更多的人变成桥梁纽带,比如某咸平。但我们 openSUSE 社区不会是这样)

我成为不了你的人生导师,你的心理问题我解决不了,只能解决流程问题。

正文:

我们以汇报 gettext-runtime 的一个 regression 为例。(所谓 regression,也是 bug 的一种,意思就是比如之前版本本来好好的东西,现在这个版本不行了,这主要是因为版本过渡时的某一个 bugfix,触发了更多的问题,让本来好好的东西不好了)

发现过程:

是我在 M17N 源里的 scim-anthy 原来编译得好好的,突然我们的 release manager coolo 给我发提醒说 13.1 Beta 里面这个包已经 fail 7 天了。于是我去 M17N 源看了一下,openSUSE 12.3 是成功的,openSUSE Factory 是失败的。点开两者的编译日志对比了一下,发现在 autopoint 这个命令后面,openSUSE Factory 并没有去 copy intl 文件夹。

于是我祭出万能的 Google,搜索「autopoint copy intl」(注意,到这里我依然不知道 autopoint 是干嘛的),看到了这个:

里面有说

大概意思是那人认为复制 intl 有个 bug,于是提供了一个 patch。问题在于,你帮忙修复的心是好的,但是现在是我不复制 intl 就编译不了啊。于是这是一个 regression。

上面是正面的例子,我现在要看看有没有人已经汇报过这个 bug 了,于是搜一下反面「autopoint not copy intl」,一下子就出来了:

bug #39536: autopoint 0.18.3 does not copy “intl” directory any more
savannah.gnu.org/bugs/?39536

跟进阅读,发现了这个官方人员的 commit:

git.savannah.gnu.org/cgit/gettext.git/commit/?id=c0d3ce9120fc24d2b78af59c5760ce1ec0dc0ad4

果真是之前那位犯二了。现在我知道这是 gettext 的问题了。因为 gettext.git 修的嘛。

但是这个 bugfix openSUSE 有没有呢?看下提交时间是 7 月 20 号。

于是去 build.opensuse.org,右上角搜 gettext,看到 openSUSE Factory 里有一个 gettext-runtime。点进去看发现它的最后更新日期是 8 周前,也就是 7 月初。所以没有。于是我要报一个 bug。

汇报过程:

注意:全程英文

  1. 登入 bugzilla.novell.com(你需要一个 Novell 帐号)

( 用 Firefox 登,Chrome/Chromium 会报「重定向循环错误」,我也不知道为什么 )

  1. 点击「Home」旁边的「New」

  2. 产品线选择「openSUSE」,产品选「openSUSE Factory」(你要是 12.3 出的问题就选 12.3)


  1. 第一步是让你看你遇到的问题有没有人报告过了,往下拉有个搜索框。


我们来搜索下,关键字从小到大,比如 autopoint 是 gettext 的一部分,我就先搜它后搜 gettext。

autopoint 没搜到。gettext 搜到两个:

第一个是 OBS 管理员 Adrian 报的,名字就叫「build fails」,汗,看到了吧,即使是开发者自己,有时候写的 bug report 跟我们也都是一样二的,点进去看下,通篇没提 autopoint,是无关的; 第二个人家在标题就写明白了 libvirt,这是虚拟化的事情,也是无关的。

于是我们需要自己报

  1. 「组件」那里自己选,都比较好理解,我选的是 BaseSystem,因为刚才在 OBS 上我已经看到 gettext 是在 Base:System 开发源里面开发的了。


「硬件平台」是指出错误的 CPU 架构(CPU 架构是跟编译器相关的),我这里选 All(因为编译都失败了),如果你是 32 位上遇到的问题就选 i586,否则选 x86-64(当然开发者也想到你可能搞不明白,所以直接给了两个选项:32 bit/64 bit 23333…)。

「操作系统」是指出错误的操作系统,一般就是你正在跑的操作系统,选 openSUSE 12.3,当然也有别的,不过你是 Debian 也不需要来 SUSE 报 bug 对吧…

「产品版本」这不需要讲了。我选的 13.1 Beta1,因为 coolo 发的邮件就是说那包在 13.1 Beta 里 fail 了 7 天。

重点来了:「摘要 Summary」。

摘要的写法要起到开宗明义的作用,就是不点开看你的 report,看标题就大概知道这是什么问题。比如我写的就是「Gettext-runtime autopoint not copy intl dir due to upstream fixed bug」

要点明:出错误的软件包(gettext-runtime),出错误的程序(autopoint),问题(not copy intl dir)。

至于后面的 「due to upstream fixed bug」是点出这东西上游已经修了。这样开发者比较的开心,因为不用自己修啦,于是心理上抵触就不会太大,比较愿意点开看。

至于之后是怎样,是进入 13.1 呢,还是怎样,你在正文里表达希望就行了。

有两点是要避免的:

  1. 摘要其实是一个标签系统,只要双方能看懂,别用冠词 a/the 什么的去占位置,也可以用一些缩写,比如 directory(文件夹)我就写了 dir,因为 它有长度限制
  2. 不要把出错消息整条的贴在那里。 Linux 下有各种各样的日志,如果不是开发者写在维基上面(Category:Reporting bugs - openSUSE Wiki 有整整一个分类告诉你报各种不同的 bug 需要提供的信息,有些我翻译成了中文,你进去看左边的多语言标签有没有简体中文就行了)明确说了需要的日志里面产生的错误消息,没人有心情去关注你系统上的日志,这是时间的浪费。

「细节」就把我前面的「发现过程」言简意赅的描述一下就可以了。

你遇到的情况、相关的日志节选(注意是节选,完整日志请用附件,实在不知道贴啥也没关系,开发者会管你要的,除非是他写到维基要啥了然后你还不给,那这样的 bug report 会被主观地判定为低质量的,于是就放在那里不管)说明下。我写的是


「重现频率」:是肯定会发生啊,还是频繁啊,还是偶尔啊,还是别的啊。我这个是肯定会发生的,要是「频繁」或者「偶尔」,你得继续在下面的「重现步骤」里写怎么重现它。「期望结果」和「实际结果」也都要写。你不能期望得太离谱以至于这程序还没实现呢,那就不叫 bug 叫 feature 了。

然后最后还有一个「严重性」,就是说你这个 bug 需要被优先处理还是怎样,一般崩溃类的是优先处理的,但是你也不能太虚张声势,明明没崩溃的 bug 选了个 crash,那样第一印象就不好了,因为你在跟别人抢开发者的时间。

都填好了,点击提交。

恭喜!

2赞

报告过 LibreOffice Writer 的 bug,后面懒得关注了,也不知道怎么样了…现在也没电脑,我记得之前收到邮件说有人提交了 fix,至于这个 bug 是否已经标记为 fixed 我就不太记得了…

send from my openSUSE using Tapatalk

受教了,谢谢

先 Mark 一个,做完毕设再看