1. 宣言

我们的奋起宣言！

每天至少挤一刻钟, 认真解答邮件列表/IRC/QQ群中初学者问题!
每周至少挤两小时, 整理自己的新学将成功或失败体验分享出来!
    通过Blog/Wiki/邮件列表/个人网站/weibo ...
每旬至少挤四小时, 翻译并分享自己喜爱的技术文档;
每月至少挤出两天, 提交bug报告给开源社区;
每季至少挤出一周, 快乐编程, 推进自己或是他人的开源项目;
每年至少参加一次, 宣传/推广FLOSS软件的活动,分享开源体验/自由软件思想;

只要每个有心人都能坚持下去!
10年,就足以改变中国软件的生存环境!

引发自圣・RMS ！！！ // 初版宣言 //如何报bug //同质思考:InfoQ: 叠飞机与敏捷项目知识传递

1.1. v0.0 版宣言

我们的奋起宣言！ ^{~ 2006 Zoom.Quiet 私人感悟}

每日至少抽一刻钟,解答邮件列表中初学者的问题，
每周至少抽两小时,整理新学知识将体验发表/分享出去，
    通过Blog/Wiki/邮件列表/个人网站……
每旬至少抽四个小时, 来翻译自个儿喜爱的自由软件的文档，
每月至少抽八小时, 快乐的编程，推进自个儿的项目，
每年至少参加一次, 自由软件的活动，传播自由软件思想，
    发展一名“自由人”……

只要我们每个人都坚持下去……
10年！就足以改变中国软件的整体风貌！

引发自圣・RMS ！！！ // 同质思考:InfoQ: 叠飞机与敏捷项目知识传递

1.2. 反馈

• Ma Xiaojun damage3025 # gmail dot com

发件人当地时间:         发送时间 22:09 (GMT+08:00)。发送地当前时间：下午10:56。 ✆
回复:      [email protected]
主题:      Re: [shlug] mac brew Emacs 24 只有gui ?!

> 每日至少抽一刻钟,解答邮件列表中初学者的问题，

• 有些问题折腾之后可以解决/避开，但这往往是Bug的表现。比如PDF中文乱码问题，我看到的解决方式是装poppler-data加删除/修改49-sansserif.conf。可是这样配置了，解决了并不算完事。没集成poppler-data是否使Bug，自带的49-sansserif.conf的内容是否有Bug，都是值得考虑的问题。

> 每周至少抽两小时,整理新学知识将体验发表/分享出去，通过Blog/Wiki/邮件列表/个人网站……

• 最好的地方是上游的Wiki，想办法把事情解释清楚。我觉得写个人Blog基本改善不了FOSS文档不佳的现状，很多个人Blog列了一大堆命令配置，却没有几句话解释为什么，我理解这对原作者来说是很好的笔记，只不过没什么贡献力。现在的Linux用户几乎没有不懂得Google的。但是会尽力Google并且鉴别各种信息然后折腾，只是一小部分人，有些人的性格就决定了他/她懒得去干这些事情。如果所谓自由软件非折腾不可，那我想很多普通人会中立甚至支持Apple/Microsoft的Trusted Computing，搞得不好大家都没得玩FOSS。

> 每旬至少抽四个小时, 来翻译自个儿喜爱的自由软件的文档，

• 也可以用来改进上游的文档，很多时候上游的文档也很不完善，我觉得有完善的英文版比有残缺的中文版和英文版好。相信中国大陆的英语水平在提高~

• 2012/3/3 Kang-Hao (Kenny) Lu <kennyluckco # gmail dot com>:

> 重造輪子這事的確是不怎麼支持，但是貢獻項目有時候的確是像是在幫外國人擦屁
> 股，其實貢獻國內主持的開源項目也蠻好的啊。另外，Fork 已有的項目的我一直
> 覺得不錯，就是搞不懂為什麼國內前端不少卻沒有弄出一個 jQuery 或 Node.js
> 的 fork 再弄一個社區來維護。我們 Web 技術的規範翻譯算是小 Fork 吧，畢竟
> 加了一些為了理解瀏覽器內核 Web 標準實現的「實現註解」和讓前端比較容易懂
> 的其他註解。

• 谢谢Kang-Hao的分享.;

• 我唯独对这一段不太同意

• 对我来说, 开源项目是没有国界的.如果一个开源软件对中文用户, 或者更泛一点, 对CJK字符集用户, 支持不够好, 那我认为责任并不在于以非中/日/韩文为母语的开发者, 而在于中日韩社区的参与不够.
• 对于母语不是中/日/韩文的开发者, 即使想帮助解决中日韩的问题, 也非常困难.

这时候, 最理想的情况, 就是我们的开发者去贡献补丁, 而所谓的"外国"的开发者, 能做的最多的就是尽量帮助我们改善补丁以符合项目的代码标准.

• 我觉得做开源项目很重要的一点, 就是知道什么时候不该fork, 不要轻易fork, fork

之后就需要新的人手来维护, fork以后如果新项目缺乏人手发展不下去, 那么能合并 回去的可能性是极低的, 而不合并又白白浪费了很多人力, 这是一个很纠结的问题.

> 每月至少抽八小时, 快乐的编程，推进自个儿的项目，

• 也可以用来找找已有的大型上游项目有没有和自个儿有关的问题待解决，有没有优雅的容易被接受的解决方案，有的话提交patch。我觉得最好不要重复写已经有的东西。Patch或者Fork已有的更好。就算是新东西，也尽量与已有的东西集成，尽量依赖已有的库。

1.2.1. 为什么应该坚持报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, 少抱怨.

1.2.2. 报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成为一个永远的迷。。

1.2.2.1. 实例:wps in wine

这里主要是记录一次完整的报bug的经过，时间精确到分钟。

• 现象：

WPS在wine下不能使用，每次打开wps， wps就会试图加载一个空文档， 但是wps将这个空文档识别为乱码，弹出了一个编码选择窗口。 在编码选择窗口中， 如果选择GBK， 那么会看到 “邢 唷” 这样的字符。

以下是报bug的经过：

1. 首先，搜索一下有没有重复的bug：

   • 打开 http://bugs.winehq.org/

   • 输入wps进行搜索
   • 发现结果是0
   • 初步判断， 这个bug没人报过。 甚至从来没人报过任何关于wps的bug
   • 这一步耗时一分钟： 12:42 to 12:43
2. 然后，在windows下也测试一下wps，确保Windows下没有这个问题，证明这是Wine的bug:
   • 打开virtualbox winxp

   • 从我的Ubuntu host开启一个python -m SimpleHTTPServer , 下载wps到winxp里

   • 在winxp里安装wps
   • 打开wps， 一切正常
   • 这一步花了3分钟： 12:44 to 12:47
3. 接下来， 在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
4. 紧接着，简单google一下相关的信息：
   • google “邢 唷”， 发现有人说用记事本打开doc就是这种现象在gedit下打开一个doc文件试试， 没能重现， 都是16进制 用wine notepad打开同一个doc文件，发现确实是“邢 唷”
   • 这一步，花了3分钟： 13:01 to 13:04
5. 然后，开始写bug report。
   • 一开始，不知道wps怎么用英文描述才能简洁地说明这是什么东西，因为老外不一定用过wps上了一下wps的官网，发现其实很简单，就写 wps office writer就ok了。
   • 这一步，花了两分钟： 13:04 to 13:06
   • 然后，不知道“乱码”英文怎么翻译，google translate一下，翻译为 garbled，不知对不对 :p
   • 这一步，花了4分钟： 13:06 to 13:10
   • 真正开始写bug report的正文， 花了11分钟：13:10 to 13:21
6. 写完， 上传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相关的信息，所以这一步也省时间。
• 不同的人英文水平不一样，我英文比较差，所以经常要依赖翻译工具，这一点，有的人省点时间，有的人多花点时间，不好定论。

记录结束，欢迎评论

Zoom.Quiet === Zoomq = 仨儿我的”怪癖”
我去ed  ;-)

Time is unimportant, only life important!
所有文章使用