【转帖】为什么应该坚持报bug?!
-
Qian Hong fracting AT gmail.com
发件人当地时间: 发送时间 16:30 (GMT+08:00)。发送地当前时间：下午4:34。 ✆
回复: ubuntu-zh mailing lists <[email protected]>
主题: Re: [Ubuntu-zh] Ubuntu下大家多怎麼用QQ？
虽然我个人不使用QQ很久, 但是并不赞赏向别人宣扬"Linux上还是放弃QQ吧"之类的言论,
尤其对于Linux老用户, 如果能够给出一些更积极的回复, 会对别人更加有启发意义.
首先, 在Linux上可以使用WebQQ, 这个是大家都知道的; 其次,有些用户认为WebQQ不能满足
自己的要求, 这个时候Linux老用户如果可以引导别人给Wine报bug, 会更加符合hacker的精 神. 当然, 自己hack协议也是hacker精神的体现, 但不一定适合每个人, 而报bug完全是只 要有心为开源软件做贡献就能做到的.
类似的, 如果Office格式在Linux下不兼容, 应该去给Libreoffice/Openoffice报bug. 想一
想, 如果几年前就有人去报bug, 现在是不是已经到了收割的季节? 现实情况是, 报bug的 人少, 报怨的人多, 说空话的人多, 干活的人少. 现实是, 有多少人在遇到bug的时候, 以 种种借口为由, 各种阿Q, 却不去报bug? 不从自己做起, 不主动学习报bug, 不积极承担起 推动软件进步的责任, 却希望开源软件进步, 这是很天真的想法. 如果自己真的认认真真报 过bug, 负责任地跟进自己报的bug, 像对待自己的作品一下经历bug从打开到修复的完整过 程, 不厌其烦地回复开发者的测试要求, 体会全程的酸甜苦辣, 那就会对自由软件社区的运 作有更多认识, 也会更加感激在一线做贡献的人, 知道有多么不容易. 如果自己不亲历这些 , 是难以体会到作为一个普通人也一样可以实实在在地推进自由软件进步的. 并且, 遇到问 题的时候, 找不到出路, 只会重复瞎折腾.
最过分的一种误导, 是当新手遇到硬件相关的问题的时候, 有的人用 "人品问题" 来解释.
硬件相关的问题, 唯一的解决方式就是使用者本人亲自去报bug,在这个时刻, 老用户如果不 去引导新用户报bug, 那么Linux用户社区就失去意义了.
只有报bug解决不了的问题, 才是Linux用户社区真正难以解决的问题. 然而, 我们反复提到
的, 网银, 股票软件, 淘宝旺旺, QQ, 迅雷, 游戏, 浩方, Office, 甚至部分校园网认证客 户端的问题, 都是报bug能解决的问题. 解决方法就在那里, 多少人视而不见? 视而不见没 有关系, 不去报bug没有关系, 不过至少要让社区的新成员知道, 报bug是解决问题的根本途 径. 同时, 如果是我, 我还会补充上一句: 抱歉, 老子当年舍不得花时间去报bug, 所以你 今天又遇到这个该死的问题了. 换句话说, 很多老大难的问题, 如果多年前就有人坚持报 bug, 现在恐怕已经到了收割的季节. 有数据为证: 我08年到现在报的bug, 累计应该有200 个了, 其中超过一半已经修了. 如果你觉得自由软件好用, 不要忘了世界上某个角落, 有 个人在某个时刻把你遇到的该死的 bug报了. 如果你希望自由软件变好, 即使你自己不报 bug, 也不要忘了告诉别人什么时候应该报bug. 如果你一直热衷于推广自由软件, 那么不 妨自己多报bug, 也告诉别人怎么报bug, 除非你有把握能解决你发展的新用户遇到的所有 问题.
Linux社区应该是一个主动解决困难的社区, 而不是一个逃避困难和阿Q精神泛滥的社区.
多报bug, 少抱怨.
报bug
Qian Hong fracting # gmail dot com
发件人当地时间: 发送时间 02:08 (GMT+08:00)。发送地当前时间：下午1:32。 ✆
回复: [email protected]
主题: Re: [shlug] 如何有效的支持开源? [via: mac brew Emacs 24 只有gui ?!]
> 这里主要是记录一次完整的报bug的经过，时间精确到分钟。
bug的链接在这里：http://bugs.winehq.org/show_bug.cgi?id=30060
感兴趣的朋友可以注册一下wine的bugzilla，订阅这个bug，看看这个bug将来会经历什么样的命运,我们可以一起把观测一个bug的生命周期当作一次实验。
也许很平淡，小问题，一个小patch就修了；
也许惊心动魄，从一个表面的bug追索出linux内核的bug。。。（wine bugzilla真有这样的bug）
也许，根本不是bug，是报bug的人哪里弄错了。。
也许，这是另一个bug的duplicate；
也许，这虽然是bug，却是一个won't fix。。。
也许，2012世界末日了，这个bug成为一个永远的迷。。
实例:wps in wine
这里主要是记录一次完整的报bug的经过，时间精确到分钟。
现象：
WPS在wine下不能使用，每次打开wps， wps就会试图加载一个空文档， 但是wps将这个空文档识别为乱码，弹出了一个编码选择窗口。 在编码选择窗口中， 如果选择GBK， 那么会看到 “邢 唷” 这样的字符。
以下是报bug的经过：
首先，搜索一下有没有重复的bug：
打开 http://bugs.winehq.org/ br />输入wps进行搜索
发现结果是0
初步判断， 这个bug没人报过。 甚至从来没人报过任何关于wps的bug
这一步耗时一分钟： 12:42 to 12:43
然后，在windows下也测试一下wps，确保Windows下没有这个问题，证明这是Wine的bug:
打开virtualbox winxp
从我的Ubuntu host开启一个python -m SimpleHTTPServer , 下载wps到winxp里
在winxp里安装wps
打开wps， 一切正常
这一步花了3分钟： 12:44 to 12:47
接下来， 在Wine里重复一次，这次重复的目的，一是确保每次都能重现， 二是要把终端输出重定向到文本文件里记录下来。
清空WINEPREFIX, 一切从头开始 $ rm ~/.wine
重新安装和测试
$ wine office_suite_free_2012.exe
$ cd ~/.wine/drive_c/Program\ Files/Kingsoft/Kingsoft Office/office6
$ wine wps.exe &> wps.log
这一步，花了13分钟： 12:48 to 13:01
紧接着，简单google一下相关的信息：
google “邢 唷”， 发现有人说用记事本打开doc就是这种现象在gedit下打开一个doc文件试试， 没能重现， 都是16进制 用wine notepad打开同一个doc文件，发现确实是“邢 唷”
这一步，花了3分钟： 13:01 to 13:04
然后，开始写bug report。
一开始，不知道wps怎么用英文描述才能简洁地说明这是什么东西，因为老外不一定用过wps上了一下wps的官网，发现其实很简单，就写 wps office writer就ok了。
这一步，花了两分钟： 13:04 to 13:06
然后，不知道“乱码”英文怎么翻译，google translate一下，翻译为 garbled，不知对不对
这一步，花了4分钟： 13:06 to 13:10
真正开始写bug report的正文， 花了11分钟：13:10 to 13:21
写完， 上传log，再试一下，补充说明一些必要的信息：8分钟 13:21 to 13:29
设置一下bugzilla的一个keyword “Download” ，并在“URL”一栏填写一下下载地址不到一分钟： 13:29 to 13:29
到这里， 一次完整的报bug经历结束。
总时间： 13:29 减 12:42 , 47分钟， 比我预计的长。 我经常蛊惑别人报bug，说报一个bug只要花15分钟时间，看来我错了。
当然，这个时间不是很有代表性。
有的人没有bugzilla的帐号，因此第一次报bug需要注册和登录，需要花一定时间
这本身也是一个bug，是bugzilla的bug。bugzilla社区已经在开发支持openid登录的bugzilla扩展了。
有的人不会像我一样反复确认，比如在winxp下确认一遍，在wine下确认三四遍。这也可以省时间，不过我建议报bug还是认真负责一些比较好。
因为我其实不是wps的用户，所以我这次报bug的经历其实是一次实验。对于日常用户来说，比我做实验的时候也会省一些时间。
对于普通用户，出了bug不一定会去google相关的信息，所以这一步也省时间。
不同的人英文水平不一样，我英文比较差，所以经常要依赖翻译工具，这一点，有的人省点时间，有的人多花点时间，不好定论。
记录结束，欢迎评论
