Size: 7974
Comment:
|
Size: 7985
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 22: | Line 22: |
* Ma Xiaojun damage3025@gmail.com | * Ma Xiaojun damage3025 # gmail dot com |
Line 43: | Line 43: |
Qian Hong fracting@gmail.com | Qian Hong fracting # gmail dot com |
Line 96: | Line 96: |
* 这一步,花了11分钟: 13:01 to 13:04 | * 这一步,花了3分钟: 13:01 to 13:04 |
Contents
宣言
我们的奋起宣言!
每日至少抽一刻钟,解答邮件列表中初学者的问题, 每周至少抽两小时,整理新学知识将体验发表/分享出去, 通过Blog/Wiki/邮件列表/个人网站…… 每旬至少抽四个小时, 来翻译自个儿喜爱的自由软件的文档, 每月至少抽八小时, 快乐的编程,推进自个儿的项目, 每年至少参加一次, 自由软件的活动,传播自由软件思想, 发展一名“自由人”…… 只要我们每个人都坚持下去…… 10年!就足以改变中国软件的整体风貌!
引发自圣・RMS !!! // 同质思考:InfoQ: 叠飞机与敏捷项目知识传递
反馈
- 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。
> 每旬至少抽四个小时, 来翻译自个儿喜爱的自由软件的文档,
- 也可以用来改进上游的文档,很多时候上游的文档也很不完善,我觉得有完善的英文版比有残缺的中文版和英文版好。相信中国大陆的英语水平在提高~
> 每月至少抽八小时, 快乐的编程,推进自个儿的项目,
- 也可以用来找找已有的大型上游项目有没有和自个儿有关的问题待解决,有没有优雅的容易被接受的解决方案,有的话提交patch。我觉得最好不要重复写已经有的东西。Patch或者Fork已有的更好。就算是新东西,也尽量与已有的东西集成,尽量依赖已有的库。
报bug
Qian Hong fracting # gmail dot com 发件人当地时间: 发送时间 02:08 (GMT+08:00)。发送地当前时间:下午1:32。 ✆ 回复: [email protected] 主题: Re: [shlug] 如何有效的支持开源? [via: mac brew Emacs 24 只有gui ?!]
2012/3/4 Qian Hong <[email protected]>:
> 这里主要是记录一次完整的报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:
- 输入wps进行搜索
- 发现结果是0
- 初步判断, 这个bug没人报过。 甚至从来没人报过任何关于wps的bug
- 这一步耗时一分钟: 12:42 to 12:43
- 然后,在windows下也测试一下wps,确保Windows下没有这个问题,证明这是WPS的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,不知对不对 :p
- 这一步,花了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相关的信息,所以这一步也省时间。
- 不同的人英文水平不一样,我英文比较差,所以经常要依赖翻译工具,这一点,有的人省点时间,有的人多花点时间,不好定论。
记录结束,欢迎评论