做一名开源社区的扫地僧 (上)

[Qian Hong]

做一名开源社区的扫地僧 (上)

今年的软件自由日(SFD), 我在广州Linux用户组的线下活动上做了一个分享, 主题叫做<<做一名开源社区的扫地僧(上)>>.
我把演讲的内容重新整理扩充, 写出了文字版, 希望可以跟更多朋友分享.

金庸笔下有一个传奇人物, 人称扫地僧, 身世隐秘, 武功绝顶. 小说中的扫地僧一出现就是个高手, 没人知道高手怎么炼成的.
这种"扫地僧", 实在可望不可及.
然而, 还有另一种扫地僧, 人人都可以效仿, 人人都可以做到, 不妨称之为"山寨扫地僧".

最近流传一个真实的故事, 有个广外宿管旁听了中大和广外的会计类课程, 考过了注册会计师, 跳槽去了四大会计事务所.
还有一个更著名的例子, 今年伦敦奥运会闭幕式里约八分钟上, 表演桑巴舞的巴西清洁工, 名副其实的"扫地僧", 他是巴西一家舞蹈学校的清洁工.

每一个山寨扫地僧, 都是一个励志帝...

这篇文章要推广的, 就是一条开源社区扫地僧的打怪升级之路. 当然, 起这个标题, 完全是为了骗取点击率, 真正的标题是:
= 从Bug report到Google Summer of Code =
副标题是:
== 从200个bug到5000美金 ==
直白一点, 其实重点是:
=== 怎样骗钱? ===

预告: 这篇文章很长, 读不下去的时候想一想5000美金 XD

报bug跟骗钱有什么关系呢? 这要从Google Summer of Code说起.

GSoC是一个由Google出钱赞助, 由开源项目提供一对一的导师, 由学生给开源项目写代码赚钱的夏令营活动. GSoC项目的时间是3个月,
每一个完成GSoC项目通过考核的学生都可以获得5000美元的奖金.
官方的介绍很长, 读不下去的时候想一想5000美金:
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs

GSoC每年和全球大约200个开源项目组织合作, 每年有4000多个学生申请, 最终有1000多名学生通过,
通过申请的绝大部分学生都能通过中期考核和末期考核. 如果你有幸通过了申请, 那么只要你接下来不偷懒不耍赖不懂多请教,
那么不用担心通不过考核. GSoC学生的通过率可能会影响到开源项目组织下一年分配到的学生名额, 所以导师一定会帮助你克服困难. 当然,
换个角度想, 一旦你通过了申请, 也有责任好好珍惜这个名额, 努力完成目标.

不管是申请, 中期检验还是末期检验, 每个阶段都是开源项目的导师说了算, 因此, 如果你想骗钱, 不妨提前跟开源项目的开发者混熟 ;-)

2011年初, 我开始有预谋地给Wine项目报bug扫地做测试顺便混熟脸, 到了2012年4月, 我申请了Wine项目的GSoC,
没有费多大力气就通过了申请, 并且最终顺利完成骗钱计划 [注1]. 今年有十几个学生报名Wine项目的GSoC,
而Wine项目的学生名额只有5个, 如果不是提前预谋好, 骗钱的好事肯定轮不到我.

独骗骗不如众骗骗, 希望可以把骗钱的经验跟大家分享:
- 提前一年做准备, 从报bug入门参与开源项目, 花一年时间报接近200个bug
- 通过报bug, 了解开源项目的工作流, 认识开源项目的开发者, 从开发者身上"偷学", 入门开源项目开发
- 通过报bug与开源项目开发者建立起信任的关系, "骗取" GSoC 的资格, 最终骗到5000美元奖金.

简单地说, 骗钱的诀窍就是通过报bug加入开源项目不断打怪升级, 从而提升自己的水平和提高GSoC申请的成功率.

正经地说, 一个人能为开源项目报200个bug, 那他肯定对这个项目真心有爱, 也一定会珍惜自己在开源社区中的声誉, 不会只骗钱不干活.
GSoC的本意是培养开源项目的新贡献者, 希望学生在结束夏令营之后仍然愿意为开源项目做贡献. 报200个bug本身就是一种不小的贡献,
而从开源项目开发者的角度看, 愿意提前花一年时间给项目报200个bug的学生, 骗完钱之后继续做贡献的可能性也比较大,
所以把名额给这样的学生也是合理的. 因此, 信任和机会其实是汗水换来的, 所谓"骗"只是开玩笑, 不可当真.

报200个bug似乎很难, 可是只要坚信报完200个bug就可以骗到5000美金, 立刻就变得不难了 :D

怎么报bug呢? 其实每一个成熟的开源项目都有详细的bug report guide line, 只要照着文档去做, 就知道怎么报bug.
如果从来没读过这类文档, 可以试试google一下下面的关键词组合:
XXX + QA / testing / bug report
例如:
http://lmgtfy.com/?q=libreoffice+qa
http://lmgtfy.com/?q=chromium+bug+report
https://www.google.com/search?btnG=1&pws=0&q=ubuntu+testing
等等.

这些文档通常都不短, 读不下去的时候想一想5000美金 ;-)

大多数文档会引用很多外部链接, 这些链接也应该尽可能阅读一下, 它们可能会解释开源项目的测试发布周期, 或者介绍专用的报bug和调试工具,
也可能是介绍项目相关的邮件列表, 还有可能会讲解开源项目的 *工作流* (workflow)

工作流是什么东西呢? 打个比方, 去医院看病, 工作流就是挂号就诊检查化验缴费取药也许还有送红包; 去学校上学,
工作流就是报名注册选课逃课交作业考试也许还有挂科补考; 参加GSoC, 工作流就是选项目选课题混熟脸报名申请写代码考核还有最重要的骗钱.
总之, 工作流就是这类看起来有点烦琐无聊却有时候不得不面对的办事流程.

开源项目的工作流包括, 去什么地方报bug, bug生命周期如何运转, 去什么地方提交补丁, 补丁没有被接受怎么办, 如何获得开源项目bug
tracker的管理权限, 如何获得官方的代码提交权限, 等等.

对新人来说, 有时候加入一个开源项目最大的门槛居然不是技术也不是语言, 而是对工作流的困惑不了解. 不知道去哪反馈问题, 不知道补丁发给谁,
不知道去哪里寻求帮助, 等等各种不知道.
有时候商业公司的开发者也可能会遇到这种问题, 比如在工作中用到了一些开源项目, 修复了一些bug, 却不知道怎么把补丁反馈给社区,
或者补丁发送一次没有被接受就从此放弃改进, 于是长期维护一个本地的分支, 这样就把原本简单的事情变复杂了,
把原本可以共赢的事情变成自己额外的负担. 其实开源项目的工作流大同小异, 只要接触过一个项目,
以后参与其他任何项目都不难根据文档了解工作流.

如果你对报bug的工作流有初步的了解, 就会发现报bug其实跟论坛发贴差不多, 只不过发贴的地方是bug tracker. 这么看来,
报bug的技术门槛其实是很低的, 正是因为没有技术含量, 所以才叫做"扫地".

虽然报bug跟发贴一样容易, 但是如何把bug report写得好仍然是一件需要用心的事情.
前人写过关于报bug的通用教程, 最著名的是 "如何有效地报bug" , 这篇文章具有超级牛力.
另外一篇同样具有超级牛力的文章叫做"提问的智慧". 认真地阅读这两篇文章的任何一篇, 时常反省检查一下自己做到了没有,
就能写出质量不错的bug report.
这两篇文章都很长, 读不下去的时候就想想5000美金, 这两篇文章瞬间都不长了.
如果两篇都认真读过了, 就会发现本质上提问和报bug都需要相同的素质. 当你确信自己"会报bug"的时候, 再看一下论坛上大多数的提问贴,
也许会觉得很多人不会提问, 说不定也包括过去的自己. 不信报200个bug试试? :P

一个高质量的bug report会受到开发者的欢迎, 而劣质的bug report则有可能帮倒忙, 浪费开发者的时间.
也许很多人不愿意仔细阅读 "如何有效地报bug" 和 "提问的智慧" (诅咒他们拿不到5000美金 :P)
为了防止有人真的一下子报200个劣质的bug, 还是得先打一下预防针.
合格的bug reporter需要做到:
- 阅读项目的bug report guide line! 不读guide line就报bug, 是很不负责任的做法.
- 每个bug只报告一个问题
- *精确* 说明相关程序版本号和操作系统版本
- 按 *时间顺序* *分点* 列出重现bug的 *精确* 步骤
- 记得及时回复开发者的问题!!!

本来还需要增加一点:
- 报bug之前先分别在google和项目bug tracker里搜索重复的问题.
但实际上对于新手来说, 搜索重复问题是最难做好的, 尤其对于英文不好的人来说更是如此.

当你知道怎么搜索鉴别重复的bug的时候, 已经不是新手了, 不妨提高对bug质量的要求:
- 养成自己固定的风格. 尽量按照固定的格式写bug报告, 就容易养成习惯, 有助于形成严密的思维, 不会漏掉重要的信息. 很多bug
tracker都有bug报告的"模板", 可以参考这些模板养成习惯.
- 假想自己报了50个bug, 如果半年后随机挑一个给自己看, 能否保证阅读一次就知道如何重现? 带着这样的想法去报bug,
等真正报了很多bug的时候, 回头检验一下. 如果自己都没办法读过一次就知道怎么重现, 那别人怎么知道?
- 订阅/跟踪开源项目的bug tracker, 观察别人怎么报bug, 从老手身上学习, 并主动帮助新手. 帮助别人也是提高自己的一种方法.

读完报bug必读的文档, 领会了报bug的要点, 也许你会发现:
报bug不是问题, 问题是没bug!

的确, 报bug本身不难, 难的是找bug.
在日常使用中发现bug, 通常是一件可遇不可求的事情, 否则肯定没人愿意使用这个软件 ;-)
但是, 如果你非常想报bug, 一定要了解一下 *批量找bug的方法*, 哪怕没有方法, 也要创造方法!

什么? 批量找bug?!
其实批量找bug并不稀奇, 有一类工作干的就是批量找bug的事情, 这种职位或者叫测试, 或者叫QA, 或者叫QE.

要批量找bug, 首先必须做到的一点是 "早".

很多开源项目都有devel版, alpha版, beta版等各种开发测试版, 也有所谓的最终版稳定版,
如果你在开源软件的"稳定版"中遇到不稳定的现象, 不用大惊小怪, 因为很多开源项目都没有足够的人手可以去做充分的测试,
而商业软件背后通常有不少全职的QA. 反过来, 如果你没遇到过什么严重的bug, 其实应该感激为开源项目默默做贡献的QA们.
想抓住"批量报bug"的机会, 就应该 *尽早*, 每当软件发布新版本的时候, 第一时间去测试, 最好是alpha版, 最好是daily
build版, 最好最好是自己从git仓库下载编译的实时版.

早起的鸟儿有bug吃, 但批量找到bug的通常还得是老鸟. 所以, 第二点就是跟老鸟学. 订阅开源项目的bug列表, 观察别人报的bug,
观察哪些是老鸟, 观察老鸟怎么找bug怎么报bug. 详细阅读QA的文档, 也许批量找bug的方法工具就记录在QA文档中.

有时候, 批量找bug的方法很简单, 比如说, 怎么给 wine 报200个bug?
我用过的是最笨的方法:
- 去软件下载站找排行top 100的软件, 有空就在wine上测试一下, 只要有时间, 要多少bug有多少bug.
- 有针对性地下载各家网银的控件进行安装测试, 不知不觉也报了很多bug, 顺便改进了工行和招行等网银的很多问题.
- 关注邮件列表和论坛里其他朋友反馈的Wine的问题, 看到顺眼的帖子就去帮忙测试一下报几个bug ;-)

如果这些笨办法对你实在没有吸引力, 可以看一下比较有技术含量的批量方法:
http://wiki.winehq.org/UnitTestSuites

很多项目都有自己的单元测试, 如果你在Wine上面运行这些单元测试, 就变成一组非常有价值的Wine测试用例.
(如果你恰好是某个Windows软件的作者, 希望借助Wine将软件移植到Linux/Mac, 其实只要在Wine下运行一下单元测试,
就能发现和解决绝大部分问题了.)

上面的例子不是特例, 其实很多项目都有前人总结开发出来的批量报bug方法或工具:

- 怎么批量发现Chromium/Firefox浏览器的bug?
有一个叫做Selenium的开源项目, 它是一个浏览器自动化测试工具, 支持IE, Firefox, Chromium以及一些手机浏览器:
http://seleniumhq.org/

- 怎么批量发现linux桌面环境的bug?
有一个叫做linux desktop testing project的开源项目, 用来做桌面环境和图形界面软件的自动测试工具,
支持linux, windows 和 mac:
http://ldtp.freedesktop.org/wiki

- 怎么批量发现LibreOffice/OpenOffice的bug?
我不知道有什么聪明的办法, 但笨办法倒是很简单: 每个LibreOffice/OpenOffice跟MS
office格式不兼容的地方都是一个bug. 面对格式兼容问题, 有的人只会抱怨, 有的人默默地拿走了5000美金...
从Libreoffice的wiki上可以看到, 已经有好几个GSoC学生做的是改进格式兼容的工作.

其实, 凡是跟兼容靠边的项目, 都很容易"制造"大量不兼容的bug :P
mono, Wine, ReactOS, Haiku OS, LibreOffice/OpenOffice, mingw/mxe,
gnash/lightspark, 这些都是跟兼容有关的项目, 只要google一下 XXX open source
alternative, 可以发现兼容类开源项目还有很多, 这类项目非常需要志愿者去找bug报bug.
兼容性相关的问题常常是很有挑战的技术难题, 开发调试不容易, 还时不时需要逆向工程, 遗憾的是这类项目却被骂得最多, 真是吃力不讨好.
如果我们都能做到多报bug, 少抱怨, 这个世界会变得更好.

批量报bug的方法通常跟自动测试/单元测试工具有关, open source testing项目为我们收集总结了大量的自动测试/单元测试工具:
http://www.opensourcetesting.org/functional.php

如果给一般的项目报bug对你来说太没技术含量怎么办? 不用担心, 总有够硬的骨头可以啃.

- 怎么批量发现gcc的bug?
这个我真不知道, 不过当我搜寻这个问题的答案的时候, 我发现Delta这个工具真是帅呆了:
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
Delta是一个利用二分原理对代码进行裁剪的工具, 对于诊断编译器的bug有很大帮助.
如果报bug可以骗钱, 我会先学习Delta工具, 然后上GCC的bugzilla搜索前人报过的有效的bug, 亲自重现几十个bug.
*重现bug* 其实跟 *报bug* 一样, 也是一种"扫地", 同样能学到很多东西. 俗话说熟读唐诗三百首,不会作诗也会吟,
如果你读过的bug report够多, 重现过的bug够多, 那你也一定会找bug报bug.
像gcc这样基础而重要的项目, 对于新手来说确实不容易找到bug, 但也不是没有机会. gcc在x86平台上可能非常完善,
但在一些冷门的平台上则未必有那么完美, 这也是找bug的一种思路.

怎么批量发现内核的bug?
有一个开源项目叫做linux testing project, 是一个专门针对Linux内核开发的测试套件:
http://ltp.sourceforge.net/
同样, 如果报内核的bug太难, 也可以先从重现别人的bug report开始入手, 照样可以学到很多东西. 给内核找bug同样不容易,
但也不是没有机会, 一些冷门的平台, 例如openrisc, 人手不一定够, 肯定有很多bug等你捉 ;-)

很多人说Linux kernel稳定, 其实linux kernel哪里稳定? 测内核的最伤不起了, 新出的内核动不动就panic,
稳定的内核都是经过多轮测试的. 其实只要有足够多的工业级测试, linux桌面也可以跟内核一样稳定. 开源社区极缺大量志愿QA,
如果你愿意捉虫, 到处欢迎你, 甚至巴不得手把手教你 (就怕人手不够没手教你...) 当你报了200个bug的时候,
会发现原来开源项目bug那么多, 人手那么少...

在批量找bug这件事上, 需要一定的创意和想象力. 比如Selenium原本的作用是测试浏览器, 内置了大量的browser test
case, 而ReactOS是一个开源的仿Windows操作系统, 如果把这两者组合起来,
在ReactOS上运行Windows版的Selenium+Firefox/Chrome, 那就变成一组现成的ReactOS test
case了, 这时候还怕找不到ReactOS的bug吗?

只要肯动脑, 一定能发明出前人没想到过的批量找bug的方法.
还是那句话, 只要想一想5000美金, 办法一定有的 :P

读到这里, 也许你会发现, 报bug不是问题, 找bug也不是问题, 问题是木有项目!

很多人想参与开源项目, 却不知参加什么项目好.
其实这个问题功利的答案很简单: 如果是冲着GSoC的5000美金去报bug的, 那就去GSoC的官方网站查一下最近5年有哪些项目跟google合作过:
http://code.google.com/intl/zh-CN/soc/
看完之后可以猜出哪些项目明年参与合作的机会比较大, 然后就可以从中找感兴趣的项目去研究. 如果过去对开源项目了解不多,
那么不妨花一两个星期的时间广泛浏览然后再筛选一些进一步钻研.

不那么功利的答案: 只要是感兴趣的任何项目都可以.
如果毫无头绪, 不妨到ohloh.net上随便浏览, 比如看看按活跃贡献人数排名的top 1000:
https://www.ohloh.net/p?page=100&sort=active_committers
如果找到一个感兴趣的项目, 还可以在 ohloh.net 上搜索这个项目的related project, 一不小心就会牵出一批有趣的项目.
如果有多个候选项目要筛选出一个进行重点研究, 可以在 ohloh.net 上看一下这些项目的统计数据, 比如:
- 近期代码提交数量
- 最近一个月的new contributor的人数
- 高kudo rank的开发者的人数.

一个开源项目经常有新代码提交, 说明这个项目很活跃, 加入活跃的项目才有活干, 给活跃项目报bug才有人处理;
一个项目经常有新贡献者加入, 说明这个项目很吸引人并且对新人的门槛不是特别高;
一个项目有很多高kudo rank的开发者, 那么加入这个项目可以跟很多大牛学习.

如果找到这样的项目, 但它以前没有参与过GSoC, 也可以怂恿项目开发者明年向Google申请作为GSoC的合作项目, 当然,
申请不一定会成功, 因为每年只有大约200个项目有机会跟Google合作. 另外,Google每年都说不保证明年会继续举办GSoC, 所以,
骗钱要趁早...

很多事情是知易行难, 报bug也一样, 哪怕项目找到了, 批量报bug的方法也找到了, 坚持报200个bug也是一件不容易的事情.

怎样才能找到足够的动力持续去报bug呢? 其实也不难.

报bug被修复带来的成就感, 本身就能激励人继续努力.
问题是, 不是每一个bug都能被及时修复. 很多新手经常问, 一个bug要多久才能修复? 网上流传个段子, 正好回答了这个问题:
===
>> 师爷, 写代码最重要的是什么?
>淡定.
>> 师爷, 调试程序最重要的是什么?
>运气.
===

这个段子很经典, 影响bug修复的因素太多了, 有的bug一天就能修复, 有的陈年老bug很多年都没解决. 一个bug要多久才能被修复,
这个问题本身无法回答, 但是换个说法就能带来希望: 报100个bug一年后会有多少个被修复? 根据我的粗略统计,
给Wine项目报100个bug, 一年后大约会有50个被修复. 换句话说, "bug半衰期" 差不多是1年. 其他开源项目,
只要是活跃开发中, "bug半衰期"应该都不会太长. 所以, 保持报bug的动力的方法之一就是多报bug, 这样必定有一部分bug先被修复,
这些成果就会激励自己继续前进.

实际上, 保持动力的第二个方法仍然是 "多报bug".
当你报的bug足够多的时候, 可能会发现只要你一段时间不上网, 邮箱里就有很多bug邮件等着你处理, 可能是开发者发布了新补丁等你帮忙测试,
也可能是一组相关联的bug状态发生变化需要重测, 这时候bug reporter的作用就很重要. 如果不回复, 开发者的工作就可能被阻塞,
意识到这一点, 就会加倍感受到自己在社区中的价值.

如果我说保持动力的第三个方法仍然是多报bug, 那我一定会被读者骂死 :)
其实, 在我看来, 保持动力的最终极办法, 就是跟开源项目的其他贡献者成为朋友.
加入一个国际性的开源项目, 可以认识到地球上不同角落的朋友, 也许有的角落你一辈子都没有机会到达,
但是那里有个跟你素未谋面却一样为同一个开源项目做贡献的人, 这是多么神奇的事情! 如果你得到某个老外的帮助, 一定要记住她/他的名字,
虽然老外的名字很难记; 如果你得到别人的鼓励, 也不要忘了鼓励别人, 大牛和菜鸟一样都需要鼓励. 如果你跟世界各地的开源项目贡献者成为朋友,
就会加倍享受到开源的乐趣, 那个时候, 地球人都无法阻止你报bug了...

既然决心报bug, 就千万别浪费一边扫地一边偷学的好机会, 这正是扫地僧的真谛所在. 开源社区里虽然不需要"偷",
但要观察到别人忽略的东西, 学到别人没学到的东西, 也需要 "留心", 所谓的 "偷学" 其实就是分外留心地观察和学习. 只要有心,
报200个bug可以学到很多东西.

- 如果开发者反复追问bug的细节和日志, 你可以学习积累排错调试的方法思路.
- 如果开发者关闭了重复的bug, 就应该注意学习搜索方法和积累搜索关键词, 尤其是英文不好的新手.
- 如果一个bug被开发者确诊为上游的bug, 你也可以顺便了解上游项目.
- 对于大型项目, 要阅读完所有代码几乎是不可能的, 报bug的过程可以熟悉局部代码并逐渐入门开发:
- 如果开发者针对bug发布了一个补丁, 可以尝试从这个补丁周围的代码入手阅读和学习, 理解补丁的作用, 暂时忽略无关的代码.
- 如果你自己报的bug足够多, 可能会发现某些bug涉及的代码似曾相识, 这时候不妨尝试自己动手修改代码, 也许是从协助诊断开始,
也许是从dirty hack开始, 慢慢地就可能从报bug进阶到修bug.

值得强调的是, 如果你的目标是从报bug入门进阶为开发, 那么从一开始就应该订阅开源项目的patch列表和devel列表,
一开始读不懂不要紧, 长期耳濡目染, 量变可能会引起质变, 这也是一种"扫地".

如果你像我当初一样对自己的开发能力没有足够自信, 这种看似曲折的道路可以大大降低入门开发的门槛, 不知不觉增长信心. 如果你还是没信心,
想一想5000美金吧 XD

除了这些能直接学到的东西, 报bug还能带来很多间接的好处.

- 报bug的过程可以跟开发者熟悉甚至成为朋友, 将来他们能够对你有很多帮助, 有开发方面的问题可以向他们请教.
- 报bug过程可以锻炼英文!!!
如果你跟我一样, 大学入学英语分班考试考到了最差的班, 那么赶紧去报bug. 当你报了200个bug的时候, 计算机专业英语肯定不是障碍.
我刚开始用英文给开源项目报bug的时候, 很多单词不懂, 一边写bug report一边查, 报一个bug花很多时间,
还战战兢兢生怕自己表达错, 现在虽然英文也不太好, 但至少钱是骗到手了 =)
如果你在一个开源项目里混久了, 那么很容易会认识几个老外朋友, 那时候遇到英语的问题你还可以向老外请教... (用英语请教LOL)

- 报bug的过程会逐渐改变自己的思维方式.
报10个bug跟报200个bug, 学到的东西不一样, 思考方式也不一样, 前者可能是从用户的角度出发去思考问题,
而后者会迫使你从开源项目团队的角度出发去思考问题, 例如:
- 怎么做才能提高bug被修复的概率?
- 怎么节省开发者的时间和自己的时间?
- 这个项目什么地方最需要改进?
- 怎么降低新手报bug的门槛?
- 等等
当你想这些问题的时候, 其实已经逐渐融入项目团队了.
当你融入项目团队了, 可能就会像我一样没事总想骗几个人来帮忙...
所以就有了这篇文章 =)

报bug能学到很多东西, 可惜很多东西记录不下来, 记下来的也可能会失真. 这也正常, 如果读一读别人的分享就能学到这些东西,
那又何必亲力亲为去扫地? 如果真的报了200个bug, 一定会充分掌握扫地僧骗钱大法, 申请GSoC成功的概率一定会很大.
GSoC的学生需要在申请时说明自己想要为项目做什么贡献, 尽管GSoC的合作项目会提供一些可选的任务, 但更鼓励学生提出自己的idea.
如果你对项目很了解, 就容易提出自己的idea, 不会跟其他学生撞车. 如果你对项目很了解, 就会对不同任务的难度心里有数,
申请成功后也容易实现目标. 其实大多数被拒绝的学生, 不是idea太难不现实, 就是idea太容易骗钱意图太明显. 骗钱可以, 但不要太明显
;-)

其实, <<做一名开源社区的扫地僧(上)>>, 到这里就可以结束了. 也许有人会困惑, 这才刚讲完扫地, 还没开始讲骗钱, 怎么就结束了?
有这样的困惑, 正是纸上谈兵的后果. 如果真的按照扫地僧打怪升级的道路去做, 会发现对自己帮助最大的人, 其实是开源项目中的前辈,
而这篇文章最大的作用无非是引诱多几个人去尝试, 真正的价值不大, 属于读过就可以忘掉的类型.

开源项目的前辈, 有的就是GSoC的潜在导师. 骗钱事宜, 都是导师说了算, 所以最重要的还是赶紧找个项目去跟潜在的导师混熟 ;-)

正经地说, 这篇文章希望探讨的问题不仅仅是骗钱, 而是这么一个老大难的问题: 应届毕业生找工作难!
没有工作经验, 所以找不到工作; 找不到工作, 所以没有工作经验.

其实对于未来码农来说, 解决这个问题的办法很简单, 只要愿意在开源项目中找一份扫地的活干, 花个大半年的时间报一两百个bug,
就能积累一定的经验, 这个时候去找测试岗位的实习 [广告1], 肯定很受欢迎, 而有了开源项目经历和靠谱的实习, 肯定不怕找不到工作.
在开源项目中扫地扫久了, 还能逐渐进阶入门开发, 如果成功参加过GSoC, 就更不愁找不到工作了.

当然, 参与开源项目实践, 也不能包治百病.
比如, 参与开源项目不能代替学习计算机基础和算法基础, 不能代替阅读好书. 不过, 多实践对于明白需要学什么会很有帮助,
实践遇到瓶颈的时候也会更容易发现自己读书不够.
再比如, 参与开源项目也不能代替企业的实习经历, 实际上两者都能学到很多东西, 但两者互不可替代. 不过, 如果有开源项目的实践经历,
对于寻找更好的实习机会肯定大有帮助.

希望这篇文章对在读本科新生或者研究生新生有帮助, 尤其是对开源感兴趣却不知如何入手的同学, 或者对开发感兴趣却经验不足的同学.
开发能力很强的同学请不要被这篇文章误导, 你应该向 google-opensource.blogspot.com 中记录的优秀案例看齐,
争取成为下一个优秀案例, 扫地的路径不一定适合你, 我这种骗钱的技俩也不应该是你追求的层次 ;-)

GSoC每年报名申请的时间是4月份, 现在开始扫地距离GSoC2013还有半年的时间, 其实很充裕. 对于接近毕业面临就业压力的学生,
现在开始扫地合不合适我就不知道了 :P

我有一个小小的愿望, 希望以后国内的大学生争先恐后给开源项目报bug, 通过报bug入门参与开源项目, 紧接着成功申请GSoC,
并且在骗完钱之后仍然继续给开源项目做贡献 ;-)
希望将来本科生参与开源项目就像现在的本科生参加数学建模竞赛, ACM竞赛, XXX软件开发比赛一样多. 想一想哪个比赛有5000美金, 就知道谁吸引力大了 XD

我还有一个大一点的愿望, 希望将来我们可以在国内举办比GSoC更大规模的夏令营, 鼓励和支持更多的学生为开源项目做贡献.
每年1000多名参加GSoC的学生中, 印度学生和美国学生是最多的, 都有200人上下, 而中国学生只有50人左右.
如果有更多中国学生愿意走"扫地僧路线", 我相信人数翻一翻两翻完全不是问题. 但是如果大家真的争先恐后都去申请GSoC了,
肯定也没办法全部申请成功, 毕竟机会有限.
我希望我们能够举办一个"本土化类GSoC", 提供更多的机会, 当然这需要钱. 其实现在很多学校都喜欢举办ACM/数模等的院赛和校内赛,
是否以后也可以多举办一些院级或校级的"报bug扫地夏令营"呢?

有人会问, 如果扫地捉bug的人多了, 僧多bug少怎么办? 我只能说, 我非常期待没bug可报的那一天 ;-)
其实很多开源项目每年"制造"的bug远不只200个, 比如Wine项目, 从2011年到2012年就增长了3500个bug. 粗略估计,
凡是ohloh.net上活跃贡献人数排名前1000的项目, 每年都能制造成百上千个bug:
https://www.ohloh.net/p?page=100&sort=active_committers
如果你不信, 你给我钱我找给你看 XD
活跃的开源项目其实是一直在发展中的, 简直可以说是批量生bug, 所以bug是永远捉不完的...

从捉bug入门进阶开发, 不是新鲜事, 我只是跟随前人的脚步走, 应该感谢扫地的前人. 刘未鹏写过一篇文章, 叫做
<<怎样花两年时间面试一个人>>, 我的扫地僧计划有很大程度上受到了这篇文章的启发, 所以我还应该谢谢刘未鹏 ^_^
<<做一名开源社区的扫地僧>>, 其实就是从学生的角度出发, 对 <<怎样花两年时间面试一个人>> 的理论进行实践.
有(上)自然有(下), <<扫地僧(下)>>也大致预谋好了, 但现在仍不能剧透, 否则一旦失败就变成搞笑剧了 冏
其实, 最完美的结果是, 这篇文章的学生读者, 将来写出成百上千各种版本的 <<扫地僧(下)>>.

虽然文章的标题叫做扫地僧, 可是文章的内容其实是"山寨扫地僧", 为了呼应金庸原著中的绝世扫地僧, 在结尾向大家介绍Wine社区的扫地高僧
Anastasius Focht, 十一年来他分析了成百上千个bug, 他的bug report就是Wine的调试教材...
http://goo.gl/TxIvZ

最后, 感谢我的GSoC导师Aric Stewart, 在Wine的开发中给我很多帮助. Aric Stewart是日本人,
我们都希望中日和平友好. 我相信开源不分种族性别信仰和国界. 感谢 Dan Kegal, Bruno Jesus, Austin
English, André Hentschel 等帮助和鼓励过我的开发者, 尽管他们看不懂中文 :-\
感谢Google Open Source Team, 8年来为培养开源社区新人做了很多贡献, 特别要感谢 Carol Smith, GSoC的成功举办离不开她.

亲爱的读者, 如果你读到这里才想起自己已经不是学生, 猛然意识到GSoC骗钱已经与你无关, 那我只能说非常抱歉, 骗你读了这么久...
如果你想报复社会, 就转载这篇文章吧...

小调查: CrossOver (Wine的商业版) 将专门为中文用户提供中文技术支持以及特别优惠.
如果你有时间, 请花3分钟做一份关于 Wine / CrossOver 的调查, 一共只有6个问题, 非常感谢!
http://goo.gl/aEfE4

Qian Hong
fracting AT gmail DOT com
2012-10-12

[注1] 要了解技术性的内容, 可以看一下我的 "分享Wine调试经验" 系列, 比如:
https://groups.google.com/forum/?fromgroups=#!topic/gzlug/dGet0BGOikQ
[广告1] 代Kexin姐发个广告: 红帽北京长期招内核测试实习生, 欢迎在校学生投简历, google一下就可以找到相关信息.
如果感兴趣但担心自己达不到要求, 我建议从扫地开始 ;-) 如果扫地扫够了准备出山, 也可以发信问我要Kexin的联系方式.

--
Regards,
Qian Hong

-
Sent from Ubuntu
http://www.ubuntu.com/

[ghosTM55]

建议贴到个人blog上，然后我帮忙转发一下

2012/10/12 Qian Hong <frac...@gmail.com>:

> --
> 您收到此邮件是因为您订阅了 Google 网上论坛的“广州 GNU/Linux 用户组”论坛。
> 要向此网上论坛发帖，请发送电子邮件至 gz...@googlegroups.com。
> 要取消订阅此网上论坛，请发送电子邮件至 gzlug+un...@googlegroups.com。
> 若有更多问题，请通过 http://groups.google.com/group/gzlug?hl=zh-CN 访问此网上论坛。
>

--
Thomas
Shanghai Linux User Group
GitCafe - Share a cup of open source

http://ghosTunix.org
Twitter: @ghosTM55

[Qian Hong]

2012/10/12 ghosTM55 <ghost...@gmail.com>:
> 建议贴到个人blog上，然后我帮忙转发一下

木有blog... 可以在你blog上租块空地吗 :)

[Maple Valley]

发到 sysulinux.org 吧！ 一血给你拿 :)

-- 

胡淼

Sun Yat-sen University

The Guangdong Key Laboratory of Information Security Technology(IST)
Blog: http://blog.lovemaple.info/

Github: https://github.com/humiaozuzu

Sent with Sparrow

[ghosTM55]

2012/10/12 Qian Hong <frac...@gmail.com>:
> 木有blog... 可以在你blog上租块空地吗 :)

你把完整的博文发给我，我可以用GitCafe的Blog官方来发，如果你觉得可以的话 :D

[Daniel Zhang]

终于来了

[Michael Ding]

哈哈，文字版终于出来了！

[Robin Lee]

也可以转发到 LinuxToy，跟 liangsuilong 说一句就好

2012/10/12 Daniel Zhang <wode...@gmail.com>

[Qian Hong]

谢谢 Maple 和 Thomas 收留 :)

[黄浩松]

Orz

[Liutos]

Qian Hong整个GitHub Pages当博客吧——貌似GitCafe也要有这功能了？

--
您收到此邮件是因为您订阅了 Google 网上论坛的“广州 GNU/Linux 用户组”论坛。
要向此网上论坛发帖，请发送电子邮件至 gz...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 gzlug+un...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/gzlug?hl=zh-CN 访问此网上论坛。

--
Liutos Love Linux LaTeX Lisp Ling

我的GitHub主页：https://github.com/Liutos

[Jactry]

在 2012年10月12日 上午8:54，Qian Hong <frac...@gmail.com>写道：

2012/10/12 ghosTM55 <ghost...@gmail.com>:
> 建议贴到个人blog上，然后我帮忙转发一下

木有blog... 可以在你blog上租块空地吗 :)

可以放到gzlug的网站嘛~ 

Qian Hong应该有账号？ 

[青月]

对新人来说, 有时候加入一个开源项目最大的门槛居然不是技术也不是语言, 而是对工作流的困惑不了解. 不知道去哪反馈问题, 不知道补丁发给谁,
不知道去哪里寻求帮助, 等等各种不知道.

虽说是“有时”，但对我来说。还是语言。一小段的话，还可以连蒙带猜，外加Google翻译。但是整整一满屏或者几页全是E文，就泻了。
非常感谢Qian Hong的帖子。绝大部分帖子都非常好。其实我非常想要money，但考虑自身情况，我只看了全部的四分之三:P

[Qian Hong]

2012/10/12 青月 <liushuiwu...@gmail.com>:

目测你没有读到 "报bug可以锻炼英文" 那一节 :P

[黄浩松]

能坚持不容易啊，很多时候俺都是三分钟热度。。。。。。

[青月]

嘿嘿，没:P

在 2012年10月12日 上午10:40，Qian Hong <frac...@gmail.com>写道：

目测你没有读到 "报bug可以锻炼英文" 那一节 :P

[Robin Lee]

LinuxToy 转了

2012/10/12 青月 <liushuiwu...@gmail.com>

嘿嘿，没:P

在 2012年10月12日 上午10:40，Qian Hong <frac...@gmail.com>写道：

目测你没有读到 "报bug可以锻炼英文" 那一节 :P

--

[青月]

我也算一个。
虽然报bug能提高英语水平，但是面对那长长的英文文档。有些难度:(

坚持挺容易说，做起来就难了

在 2012年10月12日 上午10:42，黄浩松 <haos...@gmail.com>写道：

能坚持不容易啊，很多时候俺都是三分钟热度。。。。。。

[Ma Xiaojun]

2012/10/11 青月 <liushuiwu...@gmail.com>:
> 虽然报bug能提高英语水平，但是面对那长长的英文文档。有些难度:(
我表示很多時候文檔就是代碼而已……

[黄浩松]

其实如果不是报bug，比方说为linux开发了一个软件之类的，能不能也去申请GSoC的呢？我看到好像一定都要通过那些开源组织才行。

[Ma Xiaojun]

我的經驗是，代碼在線瀏覽一般看不出頭緒，下載下來慢慢grep比較好。
也有人推薦ack：
http://betterthangrep.com/

[Robin Lee]

嗯
yum install ack

2012/10/12 Ma Xiaojun <damag...@gmail.com>

我的經驗是，代碼在線瀏覽一般看不出頭緒，下載下來慢慢grep比較好。
也有人推薦ack：
http://betterthangrep.com/

[Jactry]

在 2012年10月12日 上午8:38，Qian Hong <frac...@gmail.com>写道：

>也许很多人不愿意仔细阅读 "如何有效地报bug" 和 "提问的智慧" (诅咒他们拿不到5000美金 :P)

中诅咒了.... :-(

>比如, 参与开源项目不能代替学习计算机基础和算法基础, 不能代替阅读好书. 不过, 多实践对于明白需要学什么会很有帮助,

还比如找妹子…… XD

>我相信开源不分种族性别信仰和国界. 

嗯！赞一个！ PS：想起了Robin那个碉堡主题，“知识共产主义” XD

[青月]

那我用错词了:P

[Qian Hong]

2012/10/12 黄浩松 <haos...@gmail.com>:
> 其实如果不是报bug，比方说为linux开发了一个软件之类的，能不能也去申请GSoC的呢？我看到好像一定都要通过那些开源组织才行。

理论上, 如果你是这个软件的作者, 你可以申请作为合作项目, 以导师的身份参加, 去指导别的学生. 注意GSoC的导师是没有钱的, 而学生有5000美元奖金.
不过, 实际上, 小项目以及新开发者要申请成为合作项目是很难的. GSoC的合作项目中, 大多数项目的主要开发者的kudo rank都是8,9,10这种级别的.

[Qian Hong]

2012/10/12 Robin Lee <robinl...@gmail.com>:
> LinuxToy 转了

谢谢收留~

[黄浩松]

soga，其实是我有一个东西是跟opencv相关的，但是我没给opencv报过bug，这样是不是就不能去GSoC了呢

[Qian Hong]

2012/10/12 黄浩松 <haos...@gmail.com>:
> soga，其实是我有一个东西是跟opencv相关的，但是我没给opencv报过bug，这样是不是就不能去GSoC了呢
报bug只是混熟脸并且提高申请命中率的其中一种手段而已.
如果你对opencv很熟悉, 能够把你的opencv相关项目展现给潜在的导师看, 申请成功的机会同样很大.
不过参加gsoc最终做的事情肯定是直接对opencv本身做贡献, 而不是基于opencv做应用级的开发.
你在读研究生吗?

[Jactry]

在 2012年10月12日 上午10:57，黄浩松 <haos...@gmail.com>写道：

soga，其实是我有一个东西是跟opencv相关的，但是我没给opencv报过bug，这样是不是就不能去GSoC了呢

 

其实，报BUG只是进GSoC的一种途径（也许是比较便捷的？）

因为要项目的负责人审批什么的，通过报BUG可以体现你对他们项目的理解，“混个熟脸”……

这样审批的时候，他们也比较信任你，这样比较容易通过？不知道Qian Hong说的是不是这样？

[Qian Hong]

2012/10/12 Jactry <jact...@gmail.com>:

> 其实，报BUG只是进GSoC的一种途径（也许是比较便捷的？）
>
> 因为要项目的负责人审批什么的，通过报BUG可以体现你对他们项目的理解，“混个熟脸”……
> 这样审批的时候，他们也比较信任你，这样比较容易通过？不知道Qian Hong说的是不是这样？

知我者Jactry也, 是不是偷看我打字了, 居然跟我发了个差不多一样的回复...

[黄浩松]

soga，不过对测试找bug实在坚持不了。。。

[Franks Wu]

好文必须顶

2012/10/12 Daniel Zhang <wode...@gmail.com>

终于来了

在 2012年10月12日 上午8:57，ghosTM55 <ghost...@gmail.com>写道：

2012/10/12 Qian Hong <frac...@gmail.com>:
> 木有blog... 可以在你blog上租块空地吗 :)

你把完整的博文发给我，我可以用GitCafe的Blog官方来发，如果你觉得可以的话 :D

--
Thomas
Shanghai Linux User Group
GitCafe - Share a cup of open source

http://ghosTunix.org
Twitter: @ghosTM55

--
您收到此邮件是因为您订阅了 Google 网上论坛的“广州 GNU/Linux 用户组”论坛。
要向此网上论坛发帖，请发送电子邮件至 gz...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 gzlug+un...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/gzlug?hl=zh-CN 访问此网上论坛。

[Jactry]

在 2012年10月12日 上午11:02，Qian Hong <frac...@gmail.com>写道：

>……是不是偷看我打字了……

这个不细说……XD

[Qian Hong]

2012/10/12 黄浩松 <haos...@gmail.com>:
> soga，不过对测试找bug实在坚持不了。。。

我猜你需要的是5000美金分期付款, 每报一个bug拿一笔 :)

[黄浩松]

....不是，其实对那个钱也不感兴趣，某种程度$5000并不多:-)（开玩笑的），只是觉得应该给开源社区做点事，但是我一直以来就是个写代码的，也只会写代码。。。。。所以如果能通过开发参与到GSoC是最好啦，不过现在看起来应该不可能了，反正无所谓啦:-)

[Ma Xiaojun]

2012/10/11 黄浩松 <haos...@gmail.com>:

> ....不是，其实对那个钱也不感兴趣，某种程度$5000并不多:-)（开玩笑的），只是觉得应该给开源社区做点事，但是我一直以来就是个写代码的，也只会写代码。。。。。所以如果能通过开发参与到GSoC是最好啦，不过现在看起来应该不可能了，反正无所谓啦:-)

Bug的大坑IBus歡迎你……
http://code.google.com/p/ibus/issues/list

我之前做了分component，然後做了一些必要的merge，關閉了一些過時失效的bug，所以找你感興趣的bug應該比較容易了。

[Qian Hong]

2012/10/12 黄浩松 <haos...@gmail.com>:

> ....不是，其实对那个钱也不感兴趣，某种程度$5000并不多:-)（开玩笑的），只是觉得应该给开源社区做点事，但是我一直以来就是个写代码的，也只会写代码。。。。。所以如果能通过开发参与到GSoC是最好啦，不过现在看起来应该不可能了，反正无所谓啦:-)

通过开发参与GSoC就是正常途径, 通过报bug骗钱才是邪门歪道啊...
你直接去看opencv的wiki不就行了? http://code.opencv.org/projects/gsoc2012/wiki

[Qian Hong]

2012/10/12 Ma Xiaojun <damag...@gmail.com>:

Xiaojun就是我文中说的典型的加入开源项目之后就想拉别人下水的例子啊...

[黄浩松]

哈哈，好，多谢各位

[黄浩松]

xiaojun是当年ubuntu 12.04 release party 上拿mac那位演示的童鞋吗:-P

[Jactry]

在 2012年10月12日 上午11:48，黄浩松 <haos...@gmail.com>写道：

> xiaojun是当年ubuntu 12.04 release party 上拿mac那位演示的童鞋吗:-P

（当年……不就今年吗……）

 是的~

[黄浩松]

soga，老了，记不起东西了;-) 。。。。

--

[Ma Xiaojun]

2012/10/11 Qian Hong <frac...@gmail.com>:
> Xiaojun就是我文中说的典型的加入开源项目之后就想拉别人下水的例子啊...
其實我沒找到你文中哪裏說了……

[JunLe Li]

2012/10/12 Qian Hong <frac...@gmail.com>:

> 2012/10/12 黄浩松 <haos...@gmail.com>:
>> soga，不过对测试找bug实在坚持不了。。。
>
> 我猜你需要的是5000美金分期付款, 每报一个bug拿一笔 :)

看到这个回复，会心一笑 XDDD

另外，Qian Hong 应该给文章加上CC的授权信息。
虽然国内的网站都是不怎么管版权问题的，但是加上CC，更利于传播啊 ;-)

[Yang Bai]

给Qian Hong跪了...
不过，说好请我吃的饭那？lol

2012/10/12 JunLe Li <lij...@gmail.com>:

> --
> 您收到此邮件是因为您订阅了 Google 网上论坛的“广州 GNU/Linux 用户组”论坛。
> 要向此网上论坛发帖，请发送电子邮件至 gz...@googlegroups.com。
> 要取消订阅此网上论坛，请发送电子邮件至 gzlug+un...@googlegroups.com。
> 若有更多问题，请通过 http://groups.google.com/group/gzlug?hl=zh-CN 访问此网上论坛。
>

--
"""
Keep It Simple,Stupid.
"""

Chinese Name: 白杨
Nick Name: Hamo
Homepage: http://hamobai.com/
GPG KEY ID: 0xA4691A33
Key fingerprint = 09D5 2D78 8E2B 0995 CF8E 4331 33C4 3D24 A469 1A33

[Michael Ding]

Hi，Hong

我私自做主，已经在我们学校的BBS论坛上发了你的这篇文章，并对作者（你）做了简单的介绍。

希望更多的在校生能够得到启发:-)

在 2012年10月12日 上午8:38，Qian Hong <frac...@gmail.com>写道：

做一名开源社区的扫地僧 (上)

 

--
Michael DING

集盒(geakit.com)创始人，做国内最好的类GitHub服务

weibo/twitter @yandy0725

[Michael Ding]

留下地址：http://bbs.seu.edu.cn/wForum/disparticle.php?boardName=Linux&ID=43811&pos=8

[Robin Lee]

支持

2012/10/12 Michael Ding <yandy...@gmail.com>

[Michael Ding]

呵呵，谢谢:-)

这种文章应该往学生多的地方多发发，各个学校BBS神马的就是一个很好的地方:-)

在 2012年10月12日 下午2:29，Robin Lee <robinl...@gmail.com>写道：

支持

[Qian Hong]

2012/10/12 Michael Ding <yandy...@gmail.com>:

> Hi，Hong
> 我私自做主，已经在我们学校的BBS论坛上发了你的这篇文章，并对作者（你）做了简单的介绍。
> 希望更多的在校生能够得到启发:-)

谢谢 Michael Ding 支持!

[Qian Hong]

2012/10/12 JunLe Li <lij...@gmail.com>:

>
> 另外，Qian Hong 应该给文章加上CC的授权信息。
> 虽然国内的网站都是不怎么管版权问题的，但是加上CC，更利于传播啊 ;-)

你说的对, 我想过的, 但是给忘了...

[Qian Hong]

2012/10/12 Yang Bai <ham...@gmail.com>:

> 给Qian Hong跪了...
> 不过，说好请我吃的饭那？lol

上次去北京待的时间太短了, 下次再请你, 哈哈. 那天披萨店本来可以请你的, 谁让你吃完饭才过来, 哼哼.
Yang Bai参加了GSoC2011, 今年我和另外几个朋友申请GSoC的时候, Yang Bai还专门给我们面授经验, 哈哈 :)

[Qian Hong]

2012/10/12 Ma Xiaojun <damag...@gmail.com>:

> 2012/10/11 Qian Hong <frac...@gmail.com>:
>> Xiaojun就是我文中说的典型的加入开源项目之后就想拉别人下水的例子啊...
> 其實我沒找到你文中哪裏說了……

在这里:
当你想这些问题的时候, 其实已经逐渐融入项目团队了.
当你融入项目团队了, 可能就会像我一样没事总想骗几个人来帮忙...

看来文章太长真的弊大于利.

[青月]

可以考虑分章节:)

[hiphen lee]

文章太长确实不好，没纲没点看着很累。

另外上文更多是号召和经历，没有提到具体方法，要大家去看英文材料，呵呵。

对于如何调试软件，如何报bug，如何进行对bug进行生命周期管理，中文开源社区缺少很好的参考材料，甚至业界。或者只是我没关心不知道。

希望qian hong能case by case的写出如何调试软件，如何报bug的系列中文文章，更希望你出书。

哈哈，但是$5000你已经到手了，还有这个动力么？据我所知，很多公司的CTO就是做QA出身的。因为开发的工作要关注细节，QA的工作要纵览全局。

--
Hiphen

[Qian Hong]

2012/10/13 hiphen lee <hip...@gmail.com>:
> 文章太长确实不好，没纲没点看着很累。
>
有时间我再改一改, 分节分页并加入摘要目录, 计划作成多页的html电子书.

> 另外上文更多是号召和经历，没有提到具体方法，要大家去看英文材料，呵呵。
>
> 对于如何调试软件，如何报bug，如何进行对bug进行生命周期管理，中文开源社区缺少很好的参考材料，甚至业界。或者只是我没关心不知道。

- <<如何有效地报bug>> 跟 <<提问的智慧>> 很多年前就有中文版了, 我认为读过这两篇, 已经能够解决 "如何报bug" 这个问题了.
- 具体到如何给某个项目报bug, 就只能去读这个项目的bug report guide line. 我翻译完wine
faq后会开始翻译wine bug report guide line, 但是其他项目就没有精力去翻译了.
我希望这篇文章的学生读者将来加入各种各样的项目, 在积累一定经验之后, 为各自热爱的项目翻译guide line.
- 如何对bug进行生命周期管理, 这个好像不是初学者关心的问题? 这个已经超出这篇文章的范围了. 如果没有读过一定数量的bug
report和写过一定数量的bug report, 可能看关于bug生命周期管理的东西没有什么实质的帮助.
- 如何调试, 这个话题实在太大了, 超出这篇文章的内容了.

>
> 希望qian hong能case by case的写出如何调试软件，如何报bug的系列中文文章，更希望你出书。
>

我一定会开个博客的 :)
出书就算了, 一般都是倒贴钱的吧 LOL

> 哈哈，但是$5000你已经到手了，还有这个动力么？据我所知，很多公司的CTO就是做QA出身的。因为开发的工作要关注细节，QA的工作要纵览全局。

当然有动力. 现在一部分动力转为做开发, 如果有经历就帮忙triage bug (谁能告诉我triage bug怎么翻译为中文...)
一年前hiphen问过我有没有wine bugzilla的管理权限, 现在有了.
所以, 如果以后大家给wine报bug的话, 处理bug的人可能就是我, 因为我会特别关注中文软件相关的bug. 为了不要增加我的负担,
请报bug的同学一定要阅读bug report guide line, 谢谢~

[JunLe Li]

对于Wine和Libreoffice，其实我一直都有一个疑问。

一直希望用“原生态”的linux程序/思路来处理事情，而不希望在系统中安装一些很“windows”的东西。所以一直在linux没用wine和各种的office软件。（但是，我却有用vbox
-.-）

需要处理文档，都是用文本文档的形式的。

Qian Hong会说服别人去使用wine么？作为一名wine的开发者。

--

LiJ...@gmail.com | Public Key | Twitter | SinaWeibo

2012/10/13 Qian Hong <frac...@gmail.com>:

[Qian Hong]

2012/10/13 JunLe Li <lij...@gmail.com>:
> Qian Hong会说服别人去使用wine么？作为一名wine的开发者。

我会说服别人去给软件报bug.
如果有人遇到office格式兼容问题, 我会建议他, 要么给libreoffice报格式兼容的bug, 要么wine msoffice,
发现问题去给wine报bug.
只要肯报bug, 就是对开源软件的推动.

对于Linux用户, 几乎所有MS平台上的软件都有两个选择, 要么用开源替代版, 遇到问题去给原生的linux版报bug, 要么用wine,
遇到问题给wine报bug. 如何选择, 需要用户自己尝试自己决定.

[JunLe Li]

其实我的意思是，说服别人不用ms的doc和xls；转为使用更加开放的，例如html、markdown；或者更加简单的，例如txt；或者直接更加规范的，例如导出为pdf。

这样子，linux上就没有msoffice的事情了。（虽然这个目标有点遥远，但是我认为应该为此作努力。）

--

LiJ...@gmail.com | Public Key | Twitter | SinaWeibo

2012/10/13 Qian Hong <frac...@gmail.com>:

[Maple Valley]

但是这样没有解决问题。

html没有方便的编辑工具，一般用户不可能去写html，markdown功能太简单，导出为pdf人家不能继续编辑。

-- 

胡淼

Sun Yat-sen University

The Guangdong Key Laboratory of Information Security Technology(IST)
Blog: http://blog.lovemaple.info/

Github: https://github.com/humiaozuzu

Sent with Sparrow

[黄浩松]

所以就这样被微软垄断了。。。。

[Qian Hong]

2012/10/13 JunLe Li <lij...@gmail.com>:

> 其实我的意思是，说服别人不用ms的doc和xls；转为使用更加开放的，例如html、markdown；或者更加简单的，例如txt；或者直接更加规范的，例如导出为pdf。
>
> 这样子，linux上就没有msoffice的事情了。（虽然这个目标有点遥远，但是我认为应该为此作努力。）

如果你将来是公司领导或者学校领导, 你可以规定全公司/学校同一用开放格式.
我知道国内有个很大的软件外包公司内部就用openoffice, 但是他们这么做的原因其实是怕收到微软的律师函.

如果你将来工作的团队不幸用到MS office, 你可以尝试说服你的领导换成开放格式.
等你成功说服领导之后, 可以把说服的方法技巧共享出来, 告诉大家究竟是哪些原因打动了领导才同意更换.

如果你没有自己当领导的经验, 也没有说服领导换开放格式的经验, 那你去说服别人换格式, 如果别人的领导不同意怎么办?
说服别人换格式, 这种事情你去全国任何一个开源软件相关的论坛和邮件列表, 都会看到有人这么做, 而且已经做了很多年了. 这种努力没错, 但是用滥了.

我们想一想, 说服别人报bug, 和说服别人换格式, 哪一种容易得到进展?
- 对于"说服别人报bug", 我可以这么推进: 只要是不涉及机密, 可以请别人把文档发过来, 我帮忙报个bug, 演示一下如何报bug,
授人以渔, 下次别人可以自己报bug, 这个过程所有开源软件用户都可能受益.
- 对于"说服别人换格式", 我想不到太有效的推进方式, 因为我没机会先说服领导换格式, 然后再教会别人怎么说服领导 LOL

对于没办法亲自去推进的方法, 我们都有必要在说出来之前自己怀疑一下, 这种方法究竟是否靠谱?

[JunLe Li]

2012/10/13 Maple Valley <maplev...@gmail.com>:

> 但是这样没有解决问题。
>
> html没有方便的编辑工具，一般用户不可能去写html，markdown功能太简单，导出为pdf人家不能继续编辑。

markdown功能不算简单了，一直文字类型已经可以解决。类似的选择还有rst、texinfo；但是功能和语法肯定是正比的。

而且，我也不能强求别人一定得学习那些比起doc“复杂”很多的语法。只能尽量地劝说“能够劝说”的人不用msoffice。

[Qian Hong]

2012/10/13 JunLe Li <lij...@gmail.com>:

> 其实我的意思是，说服别人不用ms的doc和xls；转为使用更加开放的，例如html、markdown；或者更加简单的，例如txt；或者直接更加规范的，例如导出为pdf。
>
> 这样子，linux上就没有msoffice的事情了。（虽然这个目标有点遥远，但是我认为应该为此作努力。）

如果不是身不由己迫不得已, 能换的人早就换了, 因为论坛和邮件列表上这类说服已经说滥了, 多一个人说, 也不会起很大作用.
说终究是纸上谈兵的事情.

Linux中文社区真正缺少的是正视问题的勇气, 如果有一半的人把说的功夫花在报bug上, 可以解决很多问题.
只要想一想, 多一个人说, 跟多一个人报bug, 哪种边际效益大, 就知道该怎么做了.

[Liang Suilong]

Markdown 和 HTML 对于一般办公文书人员都太复杂了，使用习惯和方便程度都不如 MS Office。一般用户都是很“愚蠢”的。还不如忽悠别人用 WPS 和 Google Docs 好过了。

Sent from Transformer Prime

[JunLe Li]

2012/10/13 Liang Suilong <liangs...@gmail.com>:

> Markdown 和 HTML 对于一般办公文书人员都太复杂了，使用习惯和方便程度都不如 MS Office。一般用户都是很“愚蠢”的。还不如忽悠别人用
> WPS 和 Google Docs 好过了。

其实政府机关（之前在海珠区政府实习了1个月）都必须用wps专业版了，由于版权的问题。

@Qian Hong

> 如果不是身不由己迫不得已, 能换的人早就换了, 因为论坛和邮件列表上这类说服已经说滥了, 多一个人说, 也不会起很大作用.
> 说终究是纸上谈兵的事情.
> Linux中文社区真正缺少的是正视问题的勇气, 如果有一半的人把说的功夫花在报bug上, 可以解决很多问题.
只要想一想, 多一个人说, 跟多一个人报bug, 哪种边际效益大, 就知道该怎么做了.

其实我明白Qian Hong的意思。改变不了“doc格式堕断行业”的现象，那就改变“对doc格式支持不好”的现象。因为相比起前者，后面更加实际和容易操作。

[Ma Xiaojun]

其實我覺得Apache OpenOffice對於例如，打一堆空格來實現居中的人來說，也沒有那麼難用的。一直追LibreOffice的新版倒是覺得LibreOffice有些不夠穩定。

當然同樣是打空格居中，爲什麼要折騰一個格式支持不好的呢？所以你說WPS是不是非常好的選擇呢？當然如果條件允許，用完全不付費的AOO不是更好。

當然在微軟支持Office Open XML
Strict之前我絕對是非常反對直接傳播Office格式的文件的，支持了Strict之後可能傳播帶x的文件也算可以接受了。

[Felix Yan]

赞好文!

我之前总是觉得自己想报的bug太偏门, 解决起来既浪费开发者时间又帮不到多少用户, 所以总是会犹豫报不报. 今天仔细看完这篇文章,
决定还是先报上200个, 哈哈!

Felix Yan
Twitter: @felixonmars
Wiki: http://felixc.at

2012/10/12 Qian Hong <frac...@gmail.com>:
> 做一名开源社区的扫地僧 (上)
>
> 今年的软件自由日(SFD), 我在广州Linux用户组的线下活动上做了一个分享, 主题叫做<<做一名开源社区的扫地僧(上)>>.
> 我把演讲的内容重新整理扩充, 写出了文字版, 希望可以跟更多朋友分享.
>
> 金庸笔下有一个传奇人物, 人称扫地僧, 身世隐秘, 武功绝顶. 小说中的扫地僧一出现就是个高手, 没人知道高手怎么炼成的.
> 这种"扫地僧", 实在可望不可及.
> 然而, 还有另一种扫地僧, 人人都可以效仿, 人人都可以做到, 不妨称之为"山寨扫地僧".
>
> 最近流传一个真实的故事, 有个广外宿管旁听了中大和广外的会计类课程, 考过了注册会计师, 跳槽去了四大会计事务所.
> 还有一个更著名的例子, 今年伦敦奥运会闭幕式里约八分钟上, 表演桑巴舞的巴西清洁工, 名副其实的"扫地僧", 他是巴西一家舞蹈学校的清洁工.
>
> 每一个山寨扫地僧, 都是一个励志帝...
>
> 这篇文章要推广的, 就是一条开源社区扫地僧的打怪升级之路. 当然, 起这个标题, 完全是为了骗取点击率, 真正的标题是:
> = 从Bug report到Google Summer of Code =
> 副标题是:
> == 从200个bug到5000美金 ==
> 直白一点, 其实重点是:
> === 怎样骗钱? ===
>
> 预告: 这篇文章很长, 读不下去的时候想一想5000美金 XD
>
> 报bug跟骗钱有什么关系呢? 这要从Google Summer of Code说起.
>
> GSoC是一个由Google出钱赞助, 由开源项目提供一对一的导师, 由学生给开源项目写代码赚钱的夏令营活动. GSoC项目的时间是3个月,
> 每一个完成GSoC项目通过考核的学生都可以获得5000美元的奖金.
> 官方的介绍很长, 读不下去的时候想一想5000美金:
> http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs
>
> GSoC每年和全球大约200个开源项目组织合作, 每年有4000多个学生申请, 最终有1000多名学生通过,
> 通过申请的绝大部分学生都能通过中期考核和末期考核. 如果你有幸通过了申请, 那么只要你接下来不偷懒不耍赖不懂多请教,
> 那么不用担心通不过考核. GSoC学生的通过率可能会影响到开源项目组织下一年分配到的学生名额, 所以导师一定会帮助你克服困难. 当然,
> 换个角度想, 一旦你通过了申请, 也有责任好好珍惜这个名额, 努力完成目标.
>
> 不管是申请, 中期检验还是末期检验, 每个阶段都是开源项目的导师说了算, 因此, 如果你想骗钱, 不妨提前跟开源项目的开发者混熟 ;-)
>
> 2011年初, 我开始有预谋地给Wine项目报bug扫地做测试顺便混熟脸, 到了2012年4月, 我申请了Wine项目的GSoC,
> 没有费多大力气就通过了申请, 并且最终顺利完成骗钱计划 [注1]. 今年有十几个学生报名Wine项目的GSoC,
> 而Wine项目的学生名额只有5个, 如果不是提前预谋好, 骗钱的好事肯定轮不到我.
>
> 独骗骗不如众骗骗, 希望可以把骗钱的经验跟大家分享:
> - 提前一年做准备, 从报bug入门参与开源项目, 花一年时间报接近200个bug
> - 通过报bug, 了解开源项目的工作流, 认识开源项目的开发者, 从开发者身上"偷学", 入门开源项目开发
> - 通过报bug与开源项目开发者建立起信任的关系, "骗取" GSoC 的资格, 最终骗到5000美元奖金.
>
> 简单地说, 骗钱的诀窍就是通过报bug加入开源项目不断打怪升级, 从而提升自己的水平和提高GSoC申请的成功率.
>
> 正经地说, 一个人能为开源项目报200个bug, 那他肯定对这个项目真心有爱, 也一定会珍惜自己在开源社区中的声誉, 不会只骗钱不干活.
> GSoC的本意是培养开源项目的新贡献者, 希望学生在结束夏令营之后仍然愿意为开源项目做贡献. 报200个bug本身就是一种不小的贡献,
> 而从开源项目开发者的角度看, 愿意提前花一年时间给项目报200个bug的学生, 骗完钱之后继续做贡献的可能性也比较大,
> 所以把名额给这样的学生也是合理的. 因此, 信任和机会其实是汗水换来的, 所谓"骗"只是开玩笑, 不可当真.
>
> 报200个bug似乎很难, 可是只要坚信报完200个bug就可以骗到5000美金, 立刻就变得不难了 :D
>
> 怎么报bug呢? 其实每一个成熟的开源项目都有详细的bug report guide line, 只要照着文档去做, 就知道怎么报bug.
> 如果从来没读过这类文档, 可以试试google一下下面的关键词组合:
> XXX + QA / testing / bug report
> 例如:
> http://lmgtfy.com/?q=libreoffice+qa
> http://lmgtfy.com/?q=chromium+bug+report
> https://www.google.com/search?btnG=1&pws=0&q=ubuntu+testing
> 等等.
>
> 这些文档通常都不短, 读不下去的时候想一想5000美金 ;-)
>
> 大多数文档会引用很多外部链接, 这些链接也应该尽可能阅读一下, 它们可能会解释开源项目的测试发布周期, 或者介绍专用的报bug和调试工具,
> 也可能是介绍项目相关的邮件列表, 还有可能会讲解开源项目的 *工作流* (workflow)
>
> 工作流是什么东西呢? 打个比方, 去医院看病, 工作流就是挂号就诊检查化验缴费取药也许还有送红包; 去学校上学,
> 工作流就是报名注册选课逃课交作业考试也许还有挂科补考; 参加GSoC, 工作流就是选项目选课题混熟脸报名申请写代码考核还有最重要的骗钱.
> 总之, 工作流就是这类看起来有点烦琐无聊却有时候不得不面对的办事流程.
>
> 开源项目的工作流包括, 去什么地方报bug, bug生命周期如何运转, 去什么地方提交补丁, 补丁没有被接受怎么办, 如何获得开源项目bug
> tracker的管理权限, 如何获得官方的代码提交权限, 等等.
>
> 对新人来说, 有时候加入一个开源项目最大的门槛居然不是技术也不是语言, 而是对工作流的困惑不了解. 不知道去哪反馈问题, 不知道补丁发给谁,
> 不知道去哪里寻求帮助, 等等各种不知道.
> 有时候商业公司的开发者也可能会遇到这种问题, 比如在工作中用到了一些开源项目, 修复了一些bug, 却不知道怎么把补丁反馈给社区,
> 或者补丁发送一次没有被接受就从此放弃改进, 于是长期维护一个本地的分支, 这样就把原本简单的事情变复杂了,
> 把原本可以共赢的事情变成自己额外的负担. 其实开源项目的工作流大同小异, 只要接触过一个项目,
> 以后参与其他任何项目都不难根据文档了解工作流.
>
> 如果你对报bug的工作流有初步的了解, 就会发现报bug其实跟论坛发贴差不多, 只不过发贴的地方是bug tracker. 这么看来,
> 报bug的技术门槛其实是很低的, 正是因为没有技术含量, 所以才叫做"扫地".
>
> 虽然报bug跟发贴一样容易, 但是如何把bug report写得好仍然是一件需要用心的事情.
> 前人写过关于报bug的通用教程, 最著名的是 "如何有效地报bug" , 这篇文章具有超级牛力.
> 另外一篇同样具有超级牛力的文章叫做"提问的智慧". 认真地阅读这两篇文章的任何一篇, 时常反省检查一下自己做到了没有,
> 就能写出质量不错的bug report.
> 这两篇文章都很长, 读不下去的时候就想想5000美金, 这两篇文章瞬间都不长了.
> 如果两篇都认真读过了, 就会发现本质上提问和报bug都需要相同的素质. 当你确信自己"会报bug"的时候, 再看一下论坛上大多数的提问贴,
> 也许会觉得很多人不会提问, 说不定也包括过去的自己. 不信报200个bug试试? :P
>
> 一个高质量的bug report会受到开发者的欢迎, 而劣质的bug report则有可能帮倒忙, 浪费开发者的时间.
> 也许很多人不愿意仔细阅读 "如何有效地报bug" 和 "提问的智慧" (诅咒他们拿不到5000美金 :P)
> 为了防止有人真的一下子报200个劣质的bug, 还是得先打一下预防针.
> 合格的bug reporter需要做到:
> - 阅读项目的bug report guide line! 不读guide line就报bug, 是很不负责任的做法.
> - 每个bug只报告一个问题
> - *精确* 说明相关程序版本号和操作系统版本
> - 按 *时间顺序* *分点* 列出重现bug的 *精确* 步骤
> - 记得及时回复开发者的问题!!!
>
> 本来还需要增加一点:
> - 报bug之前先分别在google和项目bug tracker里搜索重复的问题.
> 但实际上对于新手来说, 搜索重复问题是最难做好的, 尤其对于英文不好的人来说更是如此.
>
> 当你知道怎么搜索鉴别重复的bug的时候, 已经不是新手了, 不妨提高对bug质量的要求:
> - 养成自己固定的风格. 尽量按照固定的格式写bug报告, 就容易养成习惯, 有助于形成严密的思维, 不会漏掉重要的信息. 很多bug
> tracker都有bug报告的"模板", 可以参考这些模板养成习惯.
> - 假想自己报了50个bug, 如果半年后随机挑一个给自己看, 能否保证阅读一次就知道如何重现? 带着这样的想法去报bug,
> 等真正报了很多bug的时候, 回头检验一下. 如果自己都没办法读过一次就知道怎么重现, 那别人怎么知道?
> - 订阅/跟踪开源项目的bug tracker, 观察别人怎么报bug, 从老手身上学习, 并主动帮助新手. 帮助别人也是提高自己的一种方法.
>
>
> 读完报bug必读的文档, 领会了报bug的要点, 也许你会发现:
> 报bug不是问题, 问题是没bug!
>
> 的确, 报bug本身不难, 难的是找bug.
> 在日常使用中发现bug, 通常是一件可遇不可求的事情, 否则肯定没人愿意使用这个软件 ;-)
> 但是, 如果你非常想报bug, 一定要了解一下 *批量找bug的方法*, 哪怕没有方法, 也要创造方法!
>
> 什么? 批量找bug?!
> 其实批量找bug并不稀奇, 有一类工作干的就是批量找bug的事情, 这种职位或者叫测试, 或者叫QA, 或者叫QE.
>
> 要批量找bug, 首先必须做到的一点是 "早".
>
> 很多开源项目都有devel版, alpha版, beta版等各种开发测试版, 也有所谓的最终版稳定版,
> 如果你在开源软件的"稳定版"中遇到不稳定的现象, 不用大惊小怪, 因为很多开源项目都没有足够的人手可以去做充分的测试,
> 而商业软件背后通常有不少全职的QA. 反过来, 如果你没遇到过什么严重的bug, 其实应该感激为开源项目默默做贡献的QA们.
> 想抓住"批量报bug"的机会, 就应该 *尽早*, 每当软件发布新版本的时候, 第一时间去测试, 最好是alpha版, 最好是daily
> build版, 最好最好是自己从git仓库下载编译的实时版.
>
> 早起的鸟儿有bug吃, 但批量找到bug的通常还得是老鸟. 所以, 第二点就是跟老鸟学. 订阅开源项目的bug列表, 观察别人报的bug,
> 观察哪些是老鸟, 观察老鸟怎么找bug怎么报bug. 详细阅读QA的文档, 也许批量找bug的方法工具就记录在QA文档中.
>
> 有时候, 批量找bug的方法很简单, 比如说, 怎么给 wine 报200个bug?
> 我用过的是最笨的方法:
> - 去软件下载站找排行top 100的软件, 有空就在wine上测试一下, 只要有时间, 要多少bug有多少bug.
> - 有针对性地下载各家网银的控件进行安装测试, 不知不觉也报了很多bug, 顺便改进了工行和招行等网银的很多问题.
> - 关注邮件列表和论坛里其他朋友反馈的Wine的问题, 看到顺眼的帖子就去帮忙测试一下报几个bug ;-)
>
> 如果这些笨办法对你实在没有吸引力, 可以看一下比较有技术含量的批量方法:
> http://wiki.winehq.org/UnitTestSuites
>
> 很多项目都有自己的单元测试, 如果你在Wine上面运行这些单元测试, 就变成一组非常有价值的Wine测试用例.
> (如果你恰好是某个Windows软件的作者, 希望借助Wine将软件移植到Linux/Mac, 其实只要在Wine下运行一下单元测试,
> 就能发现和解决绝大部分问题了.)
>
> 上面的例子不是特例, 其实很多项目都有前人总结开发出来的批量报bug方法或工具:
>
> - 怎么批量发现Chromium/Firefox浏览器的bug?
> 有一个叫做Selenium的开源项目, 它是一个浏览器自动化测试工具, 支持IE, Firefox, Chromium以及一些手机浏览器:
> http://seleniumhq.org/
>
> - 怎么批量发现linux桌面环境的bug?
> 有一个叫做linux desktop testing project的开源项目, 用来做桌面环境和图形界面软件的自动测试工具,
> 支持linux, windows 和 mac:
> http://ldtp.freedesktop.org/wiki
>
> - 怎么批量发现LibreOffice/OpenOffice的bug?
> 我不知道有什么聪明的办法, 但笨办法倒是很简单: 每个LibreOffice/OpenOffice跟MS
> office格式不兼容的地方都是一个bug. 面对格式兼容问题, 有的人只会抱怨, 有的人默默地拿走了5000美金...
> 从Libreoffice的wiki上可以看到, 已经有好几个GSoC学生做的是改进格式兼容的工作.
>
> 其实, 凡是跟兼容靠边的项目, 都很容易"制造"大量不兼容的bug :P
> mono, Wine, ReactOS, Haiku OS, LibreOffice/OpenOffice, mingw/mxe,
> gnash/lightspark, 这些都是跟兼容有关的项目, 只要google一下 XXX open source
> alternative, 可以发现兼容类开源项目还有很多, 这类项目非常需要志愿者去找bug报bug.
> 兼容性相关的问题常常是很有挑战的技术难题, 开发调试不容易, 还时不时需要逆向工程, 遗憾的是这类项目却被骂得最多, 真是吃力不讨好.
> 如果我们都能做到多报bug, 少抱怨, 这个世界会变得更好.
>
> 批量报bug的方法通常跟自动测试/单元测试工具有关, open source testing项目为我们收集总结了大量的自动测试/单元测试工具:
> http://www.opensourcetesting.org/functional.php
>
> 如果给一般的项目报bug对你来说太没技术含量怎么办? 不用担心, 总有够硬的骨头可以啃.
>
> - 怎么批量发现gcc的bug?
> 这个我真不知道, 不过当我搜寻这个问题的答案的时候, 我发现Delta这个工具真是帅呆了:
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
> Delta是一个利用二分原理对代码进行裁剪的工具, 对于诊断编译器的bug有很大帮助.
> 如果报bug可以骗钱, 我会先学习Delta工具, 然后上GCC的bugzilla搜索前人报过的有效的bug, 亲自重现几十个bug.
> *重现bug* 其实跟 *报bug* 一样, 也是一种"扫地", 同样能学到很多东西. 俗话说熟读唐诗三百首,不会作诗也会吟,
> 如果你读过的bug report够多, 重现过的bug够多, 那你也一定会找bug报bug.
> 像gcc这样基础而重要的项目, 对于新手来说确实不容易找到bug, 但也不是没有机会. gcc在x86平台上可能非常完善,
> 但在一些冷门的平台上则未必有那么完美, 这也是找bug的一种思路.
>
>
> 怎么批量发现内核的bug?
> 有一个开源项目叫做linux testing project, 是一个专门针对Linux内核开发的测试套件:
> http://ltp.sourceforge.net/
> 同样, 如果报内核的bug太难, 也可以先从重现别人的bug report开始入手, 照样可以学到很多东西. 给内核找bug同样不容易,
> 但也不是没有机会, 一些冷门的平台, 例如openrisc, 人手不一定够, 肯定有很多bug等你捉 ;-)
>
> 很多人说Linux kernel稳定, 其实linux kernel哪里稳定? 测内核的最伤不起了, 新出的内核动不动就panic,
> 稳定的内核都是经过多轮测试的. 其实只要有足够多的工业级测试, linux桌面也可以跟内核一样稳定. 开源社区极缺大量志愿QA,
> 如果你愿意捉虫, 到处欢迎你, 甚至巴不得手把手教你 (就怕人手不够没手教你...) 当你报了200个bug的时候,
> 会发现原来开源项目bug那么多, 人手那么少...
>
> 在批量找bug这件事上, 需要一定的创意和想象力. 比如Selenium原本的作用是测试浏览器, 内置了大量的browser test
> case, 而ReactOS是一个开源的仿Windows操作系统, 如果把这两者组合起来,
> 在ReactOS上运行Windows版的Selenium+Firefox/Chrome, 那就变成一组现成的ReactOS test
> case了, 这时候还怕找不到ReactOS的bug吗?
>
> 只要肯动脑, 一定能发明出前人没想到过的批量找bug的方法.
> 还是那句话, 只要想一想5000美金, 办法一定有的 :P
>
>
> 读到这里, 也许你会发现, 报bug不是问题, 找bug也不是问题, 问题是木有项目!
>
> 很多人想参与开源项目, 却不知参加什么项目好.
> 其实这个问题功利的答案很简单: 如果是冲着GSoC的5000美金去报bug的, 那就去GSoC的官方网站查一下最近5年有哪些项目跟google合作过:
> http://code.google.com/intl/zh-CN/soc/
> 看完之后可以猜出哪些项目明年参与合作的机会比较大, 然后就可以从中找感兴趣的项目去研究. 如果过去对开源项目了解不多,
> 那么不妨花一两个星期的时间广泛浏览然后再筛选一些进一步钻研.
>
> 不那么功利的答案: 只要是感兴趣的任何项目都可以.
> 如果毫无头绪, 不妨到ohloh.net上随便浏览, 比如看看按活跃贡献人数排名的top 1000:
> https://www.ohloh.net/p?page=100&sort=active_committers
> 如果找到一个感兴趣的项目, 还可以在 ohloh.net 上搜索这个项目的related project, 一不小心就会牵出一批有趣的项目.
> 如果有多个候选项目要筛选出一个进行重点研究, 可以在 ohloh.net 上看一下这些项目的统计数据, 比如:
> - 近期代码提交数量
> - 最近一个月的new contributor的人数
> - 高kudo rank的开发者的人数.
>
> 一个开源项目经常有新代码提交, 说明这个项目很活跃, 加入活跃的项目才有活干, 给活跃项目报bug才有人处理;
> 一个项目经常有新贡献者加入, 说明这个项目很吸引人并且对新人的门槛不是特别高;
> 一个项目有很多高kudo rank的开发者, 那么加入这个项目可以跟很多大牛学习.
>
> 如果找到这样的项目, 但它以前没有参与过GSoC, 也可以怂恿项目开发者明年向Google申请作为GSoC的合作项目, 当然,
> 申请不一定会成功, 因为每年只有大约200个项目有机会跟Google合作. 另外,Google每年都说不保证明年会继续举办GSoC, 所以,
> 骗钱要趁早...
>
> 很多事情是知易行难, 报bug也一样, 哪怕项目找到了, 批量报bug的方法也找到了, 坚持报200个bug也是一件不容易的事情.
>
> 怎样才能找到足够的动力持续去报bug呢? 其实也不难.
>
> 报bug被修复带来的成就感, 本身就能激励人继续努力.
> 问题是, 不是每一个bug都能被及时修复. 很多新手经常问, 一个bug要多久才能修复? 网上流传个段子, 正好回答了这个问题:
> ===
>>> 师爷, 写代码最重要的是什么?
>>淡定.
>>> 师爷, 调试程序最重要的是什么?
>>运气.
> ===
>
> 这个段子很经典, 影响bug修复的因素太多了, 有的bug一天就能修复, 有的陈年老bug很多年都没解决. 一个bug要多久才能被修复,
> 这个问题本身无法回答, 但是换个说法就能带来希望: 报100个bug一年后会有多少个被修复? 根据我的粗略统计,
> 给Wine项目报100个bug, 一年后大约会有50个被修复. 换句话说, "bug半衰期" 差不多是1年. 其他开源项目,
> 只要是活跃开发中, "bug半衰期"应该都不会太长. 所以, 保持报bug的动力的方法之一就是多报bug, 这样必定有一部分bug先被修复,
> 这些成果就会激励自己继续前进.
>
> 实际上, 保持动力的第二个方法仍然是 "多报bug".
> 当你报的bug足够多的时候, 可能会发现只要你一段时间不上网, 邮箱里就有很多bug邮件等着你处理, 可能是开发者发布了新补丁等你帮忙测试,
> 也可能是一组相关联的bug状态发生变化需要重测, 这时候bug reporter的作用就很重要. 如果不回复, 开发者的工作就可能被阻塞,
> 意识到这一点, 就会加倍感受到自己在社区中的价值.
>
> 如果我说保持动力的第三个方法仍然是多报bug, 那我一定会被读者骂死 :)
> 其实, 在我看来, 保持动力的最终极办法, 就是跟开源项目的其他贡献者成为朋友.
> 加入一个国际性的开源项目, 可以认识到地球上不同角落的朋友, 也许有的角落你一辈子都没有机会到达,
> 但是那里有个跟你素未谋面却一样为同一个开源项目做贡献的人, 这是多么神奇的事情! 如果你得到某个老外的帮助, 一定要记住她/他的名字,
> 虽然老外的名字很难记; 如果你得到别人的鼓励, 也不要忘了鼓励别人, 大牛和菜鸟一样都需要鼓励. 如果你跟世界各地的开源项目贡献者成为朋友,
> 就会加倍享受到开源的乐趣, 那个时候, 地球人都无法阻止你报bug了...
>
> 既然决心报bug, 就千万别浪费一边扫地一边偷学的好机会, 这正是扫地僧的真谛所在. 开源社区里虽然不需要"偷",
> 但要观察到别人忽略的东西, 学到别人没学到的东西, 也需要 "留心", 所谓的 "偷学" 其实就是分外留心地观察和学习. 只要有心,
> 报200个bug可以学到很多东西.
>
> - 如果开发者反复追问bug的细节和日志, 你可以学习积累排错调试的方法思路.
> - 如果开发者关闭了重复的bug, 就应该注意学习搜索方法和积累搜索关键词, 尤其是英文不好的新手.
> - 如果一个bug被开发者确诊为上游的bug, 你也可以顺便了解上游项目.
> - 对于大型项目, 要阅读完所有代码几乎是不可能的, 报bug的过程可以熟悉局部代码并逐渐入门开发:
> - 如果开发者针对bug发布了一个补丁, 可以尝试从这个补丁周围的代码入手阅读和学习, 理解补丁的作用, 暂时忽略无关的代码.
> - 如果你自己报的bug足够多, 可能会发现某些bug涉及的代码似曾相识, 这时候不妨尝试自己动手修改代码, 也许是从协助诊断开始,
> 也许是从dirty hack开始, 慢慢地就可能从报bug进阶到修bug.
>
> 值得强调的是, 如果你的目标是从报bug入门进阶为开发, 那么从一开始就应该订阅开源项目的patch列表和devel列表,
> 一开始读不懂不要紧, 长期耳濡目染, 量变可能会引起质变, 这也是一种"扫地".
>
> 如果你像我当初一样对自己的开发能力没有足够自信, 这种看似曲折的道路可以大大降低入门开发的门槛, 不知不觉增长信心. 如果你还是没信心,
> 想一想5000美金吧 XD
>
> 除了这些能直接学到的东西, 报bug还能带来很多间接的好处.
>
> - 报bug的过程可以跟开发者熟悉甚至成为朋友, 将来他们能够对你有很多帮助, 有开发方面的问题可以向他们请教.
> - 报bug过程可以锻炼英文!!!
> 如果你跟我一样, 大学入学英语分班考试考到了最差的班, 那么赶紧去报bug. 当你报了200个bug的时候, 计算机专业英语肯定不是障碍.
> 我刚开始用英文给开源项目报bug的时候, 很多单词不懂, 一边写bug report一边查, 报一个bug花很多时间,
> 还战战兢兢生怕自己表达错, 现在虽然英文也不太好, 但至少钱是骗到手了 =)
> 如果你在一个开源项目里混久了, 那么很容易会认识几个老外朋友, 那时候遇到英语的问题你还可以向老外请教... (用英语请教LOL)
>
> - 报bug的过程会逐渐改变自己的思维方式.
> 报10个bug跟报200个bug, 学到的东西不一样, 思考方式也不一样, 前者可能是从用户的角度出发去思考问题,
> 而后者会迫使你从开源项目团队的角度出发去思考问题, 例如:
> - 怎么做才能提高bug被修复的概率?
> - 怎么节省开发者的时间和自己的时间?
> - 这个项目什么地方最需要改进?
> - 怎么降低新手报bug的门槛?
> - 等等
> 当你想这些问题的时候, 其实已经逐渐融入项目团队了.
> 当你融入项目团队了, 可能就会像我一样没事总想骗几个人来帮忙...
> 所以就有了这篇文章 =)
>
> 报bug能学到很多东西, 可惜很多东西记录不下来, 记下来的也可能会失真. 这也正常, 如果读一读别人的分享就能学到这些东西,
> 那又何必亲力亲为去扫地? 如果真的报了200个bug, 一定会充分掌握扫地僧骗钱大法, 申请GSoC成功的概率一定会很大.
> GSoC的学生需要在申请时说明自己想要为项目做什么贡献, 尽管GSoC的合作项目会提供一些可选的任务, 但更鼓励学生提出自己的idea.
> 如果你对项目很了解, 就容易提出自己的idea, 不会跟其他学生撞车. 如果你对项目很了解, 就会对不同任务的难度心里有数,
> 申请成功后也容易实现目标. 其实大多数被拒绝的学生, 不是idea太难不现实, 就是idea太容易骗钱意图太明显. 骗钱可以, 但不要太明显
> ;-)
>
> 其实, <<做一名开源社区的扫地僧(上)>>, 到这里就可以结束了. 也许有人会困惑, 这才刚讲完扫地, 还没开始讲骗钱, 怎么就结束了?
> 有这样的困惑, 正是纸上谈兵的后果. 如果真的按照扫地僧打怪升级的道路去做, 会发现对自己帮助最大的人, 其实是开源项目中的前辈,
> 而这篇文章最大的作用无非是引诱多几个人去尝试, 真正的价值不大, 属于读过就可以忘掉的类型.
>
> 开源项目的前辈, 有的就是GSoC的潜在导师. 骗钱事宜, 都是导师说了算, 所以最重要的还是赶紧找个项目去跟潜在的导师混熟 ;-)
>
> 正经地说, 这篇文章希望探讨的问题不仅仅是骗钱, 而是这么一个老大难的问题: 应届毕业生找工作难!
> 没有工作经验, 所以找不到工作; 找不到工作, 所以没有工作经验.
>
> 其实对于未来码农来说, 解决这个问题的办法很简单, 只要愿意在开源项目中找一份扫地的活干, 花个大半年的时间报一两百个bug,
> 就能积累一定的经验, 这个时候去找测试岗位的实习 [广告1], 肯定很受欢迎, 而有了开源项目经历和靠谱的实习, 肯定不怕找不到工作.
> 在开源项目中扫地扫久了, 还能逐渐进阶入门开发, 如果成功参加过GSoC, 就更不愁找不到工作了.
>
> 当然, 参与开源项目实践, 也不能包治百病.
> 比如, 参与开源项目不能代替学习计算机基础和算法基础, 不能代替阅读好书. 不过, 多实践对于明白需要学什么会很有帮助,
> 实践遇到瓶颈的时候也会更容易发现自己读书不够.
> 再比如, 参与开源项目也不能代替企业的实习经历, 实际上两者都能学到很多东西, 但两者互不可替代. 不过, 如果有开源项目的实践经历,
> 对于寻找更好的实习机会肯定大有帮助.
>
> 希望这篇文章对在读本科新生或者研究生新生有帮助, 尤其是对开源感兴趣却不知如何入手的同学, 或者对开发感兴趣却经验不足的同学.
> 开发能力很强的同学请不要被这篇文章误导, 你应该向 google-opensource.blogspot.com 中记录的优秀案例看齐,
> 争取成为下一个优秀案例, 扫地的路径不一定适合你, 我这种骗钱的技俩也不应该是你追求的层次 ;-)
>
> GSoC每年报名申请的时间是4月份, 现在开始扫地距离GSoC2013还有半年的时间, 其实很充裕. 对于接近毕业面临就业压力的学生,
> 现在开始扫地合不合适我就不知道了 :P
>
> 我有一个小小的愿望, 希望以后国内的大学生争先恐后给开源项目报bug, 通过报bug入门参与开源项目, 紧接着成功申请GSoC,
> 并且在骗完钱之后仍然继续给开源项目做贡献 ;-)
> 希望将来本科生参与开源项目就像现在的本科生参加数学建模竞赛, ACM竞赛, XXX软件开发比赛一样多. 想一想哪个比赛有5000美金, 就知道谁吸引力大了 XD
>
> 我还有一个大一点的愿望, 希望将来我们可以在国内举办比GSoC更大规模的夏令营, 鼓励和支持更多的学生为开源项目做贡献.
> 每年1000多名参加GSoC的学生中, 印度学生和美国学生是最多的, 都有200人上下, 而中国学生只有50人左右.
> 如果有更多中国学生愿意走"扫地僧路线", 我相信人数翻一翻两翻完全不是问题. 但是如果大家真的争先恐后都去申请GSoC了,
> 肯定也没办法全部申请成功, 毕竟机会有限.
> 我希望我们能够举办一个"本土化类GSoC", 提供更多的机会, 当然这需要钱. 其实现在很多学校都喜欢举办ACM/数模等的院赛和校内赛,
> 是否以后也可以多举办一些院级或校级的"报bug扫地夏令营"呢?
>
> 有人会问, 如果扫地捉bug的人多了, 僧多bug少怎么办? 我只能说, 我非常期待没bug可报的那一天 ;-)
> 其实很多开源项目每年"制造"的bug远不只200个, 比如Wine项目, 从2011年到2012年就增长了3500个bug. 粗略估计,
> 凡是ohloh.net上活跃贡献人数排名前1000的项目, 每年都能制造成百上千个bug:
> https://www.ohloh.net/p?page=100&sort=active_committers
> 如果你不信, 你给我钱我找给你看 XD
> 活跃的开源项目其实是一直在发展中的, 简直可以说是批量生bug, 所以bug是永远捉不完的...
>
> 从捉bug入门进阶开发, 不是新鲜事, 我只是跟随前人的脚步走, 应该感谢扫地的前人. 刘未鹏写过一篇文章, 叫做
> <<怎样花两年时间面试一个人>>, 我的扫地僧计划有很大程度上受到了这篇文章的启发, 所以我还应该谢谢刘未鹏 ^_^
> <<做一名开源社区的扫地僧>>, 其实就是从学生的角度出发, 对 <<怎样花两年时间面试一个人>> 的理论进行实践.
> 有(上)自然有(下), <<扫地僧(下)>>也大致预谋好了, 但现在仍不能剧透, 否则一旦失败就变成搞笑剧了 冏
> 其实, 最完美的结果是, 这篇文章的学生读者, 将来写出成百上千各种版本的 <<扫地僧(下)>>.
>
> 虽然文章的标题叫做扫地僧, 可是文章的内容其实是"山寨扫地僧", 为了呼应金庸原著中的绝世扫地僧, 在结尾向大家介绍Wine社区的扫地高僧
> Anastasius Focht, 十一年来他分析了成百上千个bug, 他的bug report就是Wine的调试教材...
> http://goo.gl/TxIvZ
>
> 最后, 感谢我的GSoC导师Aric Stewart, 在Wine的开发中给我很多帮助. Aric Stewart是日本人,
> 我们都希望中日和平友好. 我相信开源不分种族性别信仰和国界. 感谢 Dan Kegal, Bruno Jesus, Austin
> English, André Hentschel 等帮助和鼓励过我的开发者, 尽管他们看不懂中文 :-\
> 感谢Google Open Source Team, 8年来为培养开源社区新人做了很多贡献, 特别要感谢 Carol Smith, GSoC的成功举办离不开她.
>
> 亲爱的读者, 如果你读到这里才想起自己已经不是学生, 猛然意识到GSoC骗钱已经与你无关, 那我只能说非常抱歉, 骗你读了这么久...
> 如果你想报复社会, 就转载这篇文章吧...
>
> 小调查: CrossOver (Wine的商业版) 将专门为中文用户提供中文技术支持以及特别优惠.
> 如果你有时间, 请花3分钟做一份关于 Wine / CrossOver 的调查, 一共只有6个问题, 非常感谢!
> http://goo.gl/aEfE4
>
> Qian Hong
> fracting AT gmail DOT com
> 2012-10-12
>
> [注1] 要了解技术性的内容, 可以看一下我的 "分享Wine调试经验" 系列, 比如:
> https://groups.google.com/forum/?fromgroups=#!topic/gzlug/dGet0BGOikQ
> [广告1] 代Kexin姐发个广告: 红帽北京长期招内核测试实习生, 欢迎在校学生投简历, google一下就可以找到相关信息.
> 如果感兴趣但担心自己达不到要求, 我建议从扫地开始 ;-) 如果扫地扫够了准备出山, 也可以发信问我要Kexin的联系方式.

>
>
> --
> Regards,
> Qian Hong
>
> -
> Sent from Ubuntu
> http://www.ubuntu.com/
>

[OnMyWay]

我在wine上跑广发的股票软件，以前在fedora10平台上是没有问题的，但是升级到fedora17后就出现地址越界这种问题，不知道这种问题会不会太有难度了。
现在考虑把WES7装载U盘上凑合用。

在 12-10-14，Felix Yan<felix...@gmail.com> 写道：

--
实事求是

[Jactry]

在 2012年10月16日 下午12:38，OnMyWay <onmy...@gmail.com>写道：

我在wine上跑广发的股票软件，以前在fedora10平台上是没有问题的，但是升级到fedora17后就出现地址越界这种问题，不知道这种问题会不会太有难度了。

尽管跑下，有什么问题就报BUG，又没有难度交给开发者去解决好了 XD

PS:我也在测试其他一些证券软件，现在发现中国银河证券的两个软件（双子星、海王星）是可以跑的了，虽然还有一点乱码，但基本是稳定的。

但是我没有这个公司的账户，有兴趣同时有账户的朋友不妨试下，但是如果是测试交易时，要注意风险！风险自担，我不负责的哦……

 

现在考虑把WES7装载U盘上凑合用。

 

能不用M$就不要吧…… 

[Ma Xiaojun]

表示wine很需要有人報那樣的bug……

[Jactry]

在 2012年10月16日 下午12:48，Jactry <jact...@gmail.com>写道：

在 2012年10月16日 下午12:38，OnMyWay <onmy...@gmail.com>写道：

我在wine上跑广发的股票软件，以前在fedora10平台上是没有问题的，但是升级到fedora17后就出现地址越界这种问题，不知道这种问题会不会太有难度了。

尽管跑下，有什么问题就报BUG，又没有难度交给开发者去解决好了 XD

纠错 “又没有”=“有没有”……

另外如果有安信证券账号的朋友，可以wine这个安信交易端登陆试下（http://222.200.98.151/ubuntu/Downloads/client.tar.gz） 

是我从安信证券里面提取出来的，为了方便和主程序分开测试。

已知道这个交易端的BUG有两个地方（其实是用一个BUG）：就是退出是程序崩溃，换程序风格时程序崩溃。

再一次说明下：如果是测试交易的，注意风险，风险自担……

[Qian Hong]

2012/10/16 OnMyWay <onmy...@gmail.com>:

> 我在wine上跑广发的股票软件，以前在fedora10平台上是没有问题的，但是升级到fedora17后就出现地址越界这种问题，不知道这种问题会不会太有难度了。
> 现在考虑把WES7装载U盘上凑合用。

你的意思是fedora和wine都升级, 还是升级了fedora, 但是wine没升级?
wine是自己编译的, 还是fedora的包?

[Bill Chen (CHEN, Zhechuan)]

通达信系列的，貌似能正常使用，交易过程没测试，进入交易界面很正常。

Best Regards,
Bill Chen (CHEN Zhechuan)

[OnMyWay]

>> 现在考虑把WES7装载U盘上凑合用。
>
>
> 能不用M$就不要吧……
>
我也不想用M$,但是有些应用只能用. 两年前就因为招商的网银问题投诉到深圳总部, 一个IT经理打电话过来吵了半小时, 最后无果,不知道现在有无改善.

很多应用的安全领域都是与IE绑定, Linux桌面这些小众用户, 他们没精力也没动力去研发.

[Jactry]

在 2012年10月16日 下午2:57，Bill Chen (CHEN, Zhechuan) <chen.bi...@gmail.com>写道：

通达信系列的，貌似能正常使用，交易过程没测试，进入交易界面很正常。

以前用Wine的安信通达信交易过~ 

“通达信内核”的程序都没啥大问题，主要还是有些乱码分布…… 

[Ma Xiaojun]

2012/10/16 OnMyWay <onmy...@gmail.com>:
> 很多应用的安全领域都是与IE绑定, Linux桌面这些小众用户, 他们没精力也没动力去研发.
有一種旁門左道是用電腦上手機銀行。
https://addons.mozilla.org/en-US/firefox/addon/wmlbrowser/

[Bill Chen (CHEN, Zhechuan)]

招行现在貌似能在mac上用，但照样还是不能在linux下用。
不要说招行、工行这类单一的银行，就算是支付宝这样的应用，linux的桌面部分的插件，现在随着firefox的升级，已经完全失效了，过了好几个月，厂家都没更新。

Best Regards,
Bill Chen (CHEN Zhechuan)

2012/10/16 OnMyWay <onmy...@gmail.com>

我也不想用M$,但是有些应用只能用. 两年前就因为招商的网银问题投诉到深圳总部, 一个IT经理打电话过来吵了半小时, 最后无果,不知道现在有无改善.

很多应用的安全领域都是与IE绑定, Linux桌面这些小众用户, 他们没精力也没动力去研发.

[Jactry]

在 2012年10月17日 上午10:19，Bill Chen (CHEN, Zhechuan) <chen.bi...@gmail.com>写道：

招行现在貌似能在mac上用，但照样还是不能在linux下用。

你是说招商证券Mac版吗？ 也是通达信做的~  ;-)

[Bill Chen (CHEN, Zhechuan)]

我说的是网银。。。

Best Regards,
Bill Chen (CHEN Zhechuan)

2012/10/17 Jactry <jact...@gmail.com>

[Jactry]

在 2012年10月17日 上午10:56，Bill Chen (CHEN, Zhechuan) <chen.bi...@gmail.com>写道：

我说的是网银。。。

哦，明白，没看折叠…… 

[OnMyWay]

因为电脑在公司，所以迟了回复。开始还以为是selinux对low mem 保护导致。后来根据提示设置后还是不行。

wine was installed by yum.

＝＝cut==
Unhandled exception: page fault on read access to 0x0cb46cc4 in 32-bit
code (0x5f40430d).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:5f40430d ESP:0033ec5c EBP:0033ec88 EFLAGS:00010202( R- -- I - - - )
EAX:0cb46cb0 EBX:6863aff4 ECX:5f4d0000 EDX:00000000
ESI:00000000 EDI:0033ed10
Stack dump:
0x0033ec5c: 00000000 0033ed98 6863aff4 00000000
0x0033ec6c: 01412000 00000002 0033ecc0 00123608
0x0033ec7c: 0033fda4 5f492db2 ffffffff 0033ed58
0x0033ec8c: 685a2cda 00000003 000e0114 0033ed08
0x0033ec9c: ffffffff 01768018 00000001 00000000
0x0033ecac: 00000000 01412000 017683b8 0033ed08
Backtrace:
... ...
00000024 (D) C:\new_gfzq_v6_fhzx\TdxW.exe
00000073 0
00000072 0
0000002b 0
0000002a 0
00000029 0
00000028 0
00000027 0
00000026 0
00000025 0 <==
System information:
Wine build: wine-1.5.13
Platform: i386
Host system: Linux
Host version: 3.3.4-5.fc17.i686

[Qian Hong]

Hi,

2012/10/17 OnMyWay <onmy...@gmail.com>:

> 因为电脑在公司，所以迟了回复。开始还以为是selinux对low mem 保护导致。后来根据提示设置后还是不行。

你没有回答很重要的问题: 你的wine升级过没有? 如果crash是发生在升级之后的, 那就是regression,
只要花点时间做bisect测试, 就能定位到出bug的补丁, 这种情况很好修复的.

[Jactry]

在 2012年10月17日 下午12:00，OnMyWay <onmy...@gmail.com>写道：

因为电脑在公司，所以迟了回复。开始还以为是selinux对low mem 保护导致。后来根据提示设置后还是不行。

wine was installed by yum.

＝＝cut==
Unhandled exception: page fault on read access to 0x0cb46cc4 in 32-bit
code (0x5f40430d).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
 EIP:5f40430d ESP:0033ec5c EBP:0033ec88 EFLAGS:00010202(  R- --  I   - - - )
 EAX:0cb46cb0 EBX:6863aff4 ECX:5f4d0000 EDX:00000000
 ESI:00000000 EDI:0033ed10
Stack dump:
0x0033ec5c:  00000000 0033ed98 6863aff4 00000000
0x0033ec6c:  01412000 00000002 0033ecc0 00123608
0x0033ec7c:  0033fda4 5f492db2 ffffffff 0033ed58
0x0033ec8c:  685a2cda 00000003 000e0114 0033ed08
0x0033ec9c:  ffffffff 01768018 00000001 00000000
0x0033ecac:  00000000 01412000 017683b8 0033ed08
Backtrace:
... ...
00000024 (D) C:\new_gfzq_v6_fhzx\TdxW.exe
   

 广发证券的？咦，怎么主程序命名和中国银河证券海王星那个的命名是一样的，TdxW.exe，而且路径命名貌似也是同种规制，“new_yhzq_v21” ，很有可能是用同一家软件公司的产品。

不过银河证券是可以跑起来的了。

[Jactry]

在 2012年10月17日 下午12:00，OnMyWay <onmy...@gmail.com>写道：

因为电脑在公司，所以迟了回复。开始还以为是selinux对low mem 保护导致。后来根据提示设置后还是不行。

wine was installed by yum.

我刚刚用wine 1.1.15试了下，软件还是通达信的，winetricks -q mfc42 ，然后很顺利就能跑起来。

不知道你用的是什么版本的wine？然后哪里，什么操作导致crash？

 

[Jactry]

在 2012年10月17日 下午12:26，Jactry <jact...@gmail.com>写道：

我刚刚用wine 1.1.15试了下，软件还是通达信的，winetricks -q mfc42 ，然后很顺利就能跑起来。

错了，我用的是wine 1.5.15 ，然后软件是在这里下载的：http://121.14.2.33/download/wsjy/zhiqiang/new_gfzq_v6_fhzx.exe

不知对否？ 

[Bill Chen (CHEN, Zhechuan)]

TdxW.exe
用这个启动的证券交易软件，都是通达信系列。通达信系列的市场占有量很大，且公司有出Linux版，详情和推测可以Google后找到。但估计众多证券交易公司觉得Linux是个小众用户，所以没有推出相应的Linux系列个人版。（传闻证券交易公司的行情机都是Linux系统）
注意wine环境下应该安装相应的Windows依赖框架（详情请Google，中文常用软件，一般在ubuntu中文论坛内能搜到）。
经过我国庆假期的测试，如果是wine1.4系列，是会报错的，程序崩溃，原因，我估计是mfc42的问题。
wine1.5.6系列以后，基本正常，除了初始化时候的登录框乱码。

[Ma Xiaojun]

2012/10/17 Bill Chen (CHEN, Zhechuan) <chen.bi...@gmail.com>:
> 注意wine环境下应该安装相应的Windows依赖框架（详情请Google，中文常用软件，一般在ubuntu中文论坛内能搜到）。
一般推薦用乾淨的Wine哦，雖然mfc42很多時候避開不了……

[OnMyWay]

System information:
Wine build: wine-1.5.13
Platform: i386
Host system: Linux
Host version: 3.3.4-5.fc17.i686

=================
fedora和wine都是全新安装的, 广发也是新装的.

在 12-10-17，Ma Xiaojun<damag...@gmail.com> 写道：

> 2012/10/17 Bill Chen (CHEN, Zhechuan) <chen.bi...@gmail.com>:
>> 注意wine环境下应该安装相应的Windows依赖框架（详情请Google，中文常用软件，一般在ubuntu中文论坛内能搜到）。
> 一般推薦用乾淨的Wine哦，雖然mfc42很多時候避開不了……
>

[Qian Hong]

2012/10/17 OnMyWay <onmy...@gmail.com>:
> fedora和wine都是全新安装的, 广发也是新装的.

1. 有没有用winetricks安装过除了mfc42之外的windows dll?
2. 能不能提供一下完整的日志? 你的backtrace中最重要的信息被你用省略号代替了,
最好就是把终端完整的日志都贴到pastebin上, 我们一起研究一下 :)

[OnMyWay]

Sorry for late.

The attachment is the trace log. I remember installed vc60dll as well.

[Qian Hong]

2012/10/17 OnMyWay <onmy...@gmail.com>:

> Sorry for late.
>
> The attachment is the trace log. I remember installed vc60dll as well.

从日志看, crash的地方是在mfc42内的, 这种情况比较少见, 我怀疑跟mfc42的具体版本有关.
我建议你先删除或备份 ~/.wine , 然后通过 winetricks -q mfc42 来安装mfc42,
不要自己手动从windows复制mfc42.dll, 也不要安装mfc42之外的任何其他windows dll, 然后重新安装广发股票软件.

如果这样仍然崩溃, 我建议按照下面的步骤获取日志:

$ winetricks nocrashdialog
$ WINEDEBUG=+relay,+tid,+seh wine TdxW.exe &> tdxw_crash.txt

然后把日志压缩之后再上传到某个地方.
日志可能会从1m到几百m不等, 但压缩后应该不至于太大.

[Jactry]

在 2012年10月17日 下午2:10，OnMyWay <onmy...@gmail.com>写道：

System information:
    Wine build: wine-1.5.13
    Platform: i386
    Host system: Linux
    Host version: 3.3.4-5.fc17.i686

其实不妨试试最新的开发版（1.5.15）？我刚刚翻了自己下之前的debug记录，银河证券那个在1.5.14的时候也是不能跑的，但是当时的backtrace现在找不到了，也没办法确定我当时跑不了的原因了……

[Qian Hong]

2012/10/18 Jactry <jact...@gmail.com>:

> 其实不妨试试最新的开发版（1.5.15）？我刚刚翻了自己下之前的debug记录，银河证券那个在1.5.14的时候也是不能跑的，但是当时的backtrace现在找不到了，也没办法确定我当时跑不了的原因了……

为了预防backtracke和log找不到之类的情况, 我尽量发现bug尽早报, 等于是把backtrace储存在云端 :)

[Jactry]

在 2012年10月18日 下午10:30，Qian Hong <frac...@gmail.com>写道：

2012/10/18 Jactry <jact...@gmail.com>:

> 其实不妨试试最新的开发版（1.5.15）？我刚刚翻了自己下之前的debug记录，银河证券那个在1.5.14的时候也是不能跑的，但是当时的backtrace现在找不到了，也没办法确定我当时跑不了的原因了……

为了预防backtracke和log找不到之类的情况, 我尽量发现bug尽早报, 等于是把backtrace储存在云端 :)

不是，这个好像和你说过，就是我前一天发现了这个BUG，打算有空报，然后发现你说1.5.15出来，然后我就更新再试，然后就没有然后了……（损失了一个报BUG的机会啊 :-( 

[Qian Hong]

2012/10/18 Jactry <jact...@gmail.com>:

> 不是，这个好像和你说过，就是我前一天发现了这个BUG，打算有空报，然后发现你说1.5.15出来，然后我就更新再试，然后就没有然后了……（损失了一个报BUG的机会啊
> :-(

如果你想知道是哪个patch修复了这个bug, 你也可以先降级到能重现bug的版本, 然后借助git bisect把起作用的patch查找出来 :)
参见 http://wiki.winehq.org/RegressionTesting (注意这种情况下, wiki中的bad和good要互换一下)

[JunLe Li]

2012/10/18 Jactry <jact...@gmail.com>:

不过我报bug，都会被评论“请用git的HEAD尝试”，然后bug被关掉。 =.=||

[Jactry]

在 2012年10月19日 上午12:59，JunLe Li <lij...@gmail.com>写道：

不过我报bug，都会被评论“请用git的HEAD尝试”，然后bug被关掉。 =.=||

Wine?  

Wine要求好像是last development version：http://wiki.winehq.org/BugReports

不过可能是你报的BUG有人报过，然后在git上的已经fixed，只是还没有进入last development version？坐等Qian Hong解答 XD

[Qian Hong]

2012/10/19 Jactry <jact...@gmail.com>:

哪个bug? 贴个链接来看看?

[JunLe Li]

怎么分解另外的邮件了。不是wine，是tmux。
我那天看orhol（不知道是不是这样子拼），才发现tmux只有2个contributor。这样子算是小型项目吧？