如果这些笨办法对你实在没有吸引力, 可以看一下比较有技术含量的批量方法:http://wiki.winehq.org/UnitTestSuites 很多项目都有自己的单元测试, 如果你在Wine上面运行这些单元测试, 就变成一组非常有价值的Wine测试用例. (如果你恰好是某个Windows软件的作者, 希望借助Wine将软件移植到Linux/Mac, 其实只要在Wine下运行一下单元测试, 就能发现和解决绝大部分问题了.) 上面的例子不是特例, 其实很多项目都有前人总结开发出来的批量报bug方法或工具:
其实, 凡是跟兼容靠边的项目, 都很容易"制造"大量不兼容的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对你来说太没技术含量怎么办? 不用担心, 总有够硬的骨头可以啃.
很多人说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先被修复, 这些成果就会激励自己继续前进. |
