不管开源闭源程序，总有那么意外崩溃的时候。那么程序崩溃了之后，接下来该做什么呢？且看 Fedora 中文邮件列表的一番讨论，或许能告诉你更多。
先看起因吧：
这程序的设定让我很难接受，
Ctrl+V粘贴中文 乱码，需要 无格式粘贴才正常
我费半天编辑一个DOC文档，正要保存，程序提示无法保存，
然后我保存副本，程序直接崩了
再打开先前保存的，中文全部乱码,但是打开自动保存的文件却是正常的
不知道是我人品差还是什么原因。
Xfce-cd 版本 默认带的奇葩软件还有midori 这个浏览器，标榜lightweight，但是打开网页很卡，容易崩掉
我很费解Xfce-live-cd这种默认自带的软件为什么不选择质量高，难道就是为了表示有，并且方便截个图
之后 Qian Hong 指出说其实是报 Bug 不够：
这程序的设定让我很难接受，
Ctrl+V粘贴中文 乱码，需要 无格式粘贴才正常
我费半天编辑一个DOC文档，正要保存，程序提示无法保存，
然后我保存副本，程序直接崩了
再打开先前保存的，中文全部乱码,但是打开自动保存的文件却是正常的
不知道是我人品差还是什么原因。
不是你人品差，是上n个遇到相同bug的人没报bug，或者是有人报bug但开发者人手不足来不及修。也有可能你真的是第一个遇到这个bug的人，但这也不能说是人品问题。（画外音：其实明明就是233）
从ohloh的统计来看，abiword的开发还算活跃：https://www.ohloh.net/p/abiword
这意味着崩溃之类的严重bug，只要你能重现，报告之后应该会有人修复的。
如果你将来计划仍然使用abiword，那么建议搜bug报bug，参见
http://www.abisource.com/support/bugs/；如果你被坑过一次之后决定将来不用abiword了，那么不妨做第n+1个不报bug的人：）
如果想找其他开源替代品，可以参考：
https://www.ohloh.net/p/compare?project0=LibreOffice&project1=Apache+OpenOffice&project_2=AbiWord
从活跃开发人数，可以估计出将来遇到问题求助时得到解决的容易程度。
Xfce-cd 版本 默认带的奇葩软件还有midori 这个浏览器，标榜lightweight，但是打开网页很卡，容易崩掉
Midori的开发同样还算活跃：https://www.ohloh.net/p/midori
如果Midori对你来说是刚需，崩溃这样的严重bug值得去报。参见：http://midori-browser.org/contribute/
同样，如果不是刚需，大多数人可能没有足够的精力/动力去报bug，这时候最经济的方式可能是换一个软件，但是一旦选定了自己喜爱的开源软件，报bug才是真爱：）
我理解你感觉被坑是因为困惑/不满 Xfce-live-cd
为什么默认选择这些软件。这个问题，理论上的解决方案是，给xfce项目本身报bug，叫他们不要预装这两个软件，换成你认为更好的软件；但是这样做不会
有太大的说服力，除非你能证明大量用户给abiword/midori报过bug但是他们都不修或者修不了--于是又回到了开头的问题，要先给他们俩项目
报bug：）
从用户的角度来说，崩溃的bug几乎是最不能忍受的bug了，可是其实从软件开发的角度来说，凡是代码全开源的软件，出现能稳定重现的崩溃bug，
一般都不会太难修复，所以报告崩溃bug对于用户和开发者双方来说，时间利用上的性价比是最高的。但是崩溃的bug是那么讨厌，以致新用户直接就被吓跑
了，还没爱上就死心了，所以就不会去报bug了
：）
提问者 Szopen Xiao 表示赞同，且提出了更进一步的问题：怎么样改善汇报 Bug 的过程？
对此，Ubuntu 打包者 Felix Yin 对于依靠软件打包者汇报 Bug 有自己的看法：
其实已经有很多 Bug 是这样完成的了. 但是你也应该明白, 一个复杂到 Abiword 这样的软件, 如果没有那种需要跑较长时间的集成测试, 几乎是没什么
办法测到所有功能的 (这种测试写起来费时费力, 所以我遇到的开源项目很少会提供);而且即使有了, 也不能完全保证是没问题的, 毕竟图形显示等各种其他因素也
会影响实际体验.
作为发行版打包人, 我们一般会保证:
- 项目能跑过自己的 self-test, 如果跑不过, 至少要保证上游知道这个情况.
- 我们在打包发行之前, 自己会去用这个软件. 但是就如刚才所说, 我们是完全不能保证会用到所有功能的.
- 如果我们在测试中发现了问题(无论是项目自己的单元/集成测试, 还是自己使用体验中), 通常是肯定会向上游提交 bug 报告的. 如果涉及的 bug 比
较重大 (比如启动时 segfault 等使得软件完全无法使用的问题), 我们会暂缓发布直到上游给出解决方案, 或者我们自己有时也会尝试寻找解决方案. 这里
的解决方案包括提供 patch 给下游打上, 或者直接发布新版本.
至于"产品质量控制标准", 通常完全是由项目管理人员的喜好决定的. 有的项目比较随意, 对提交的 patch 几乎是来者不拒. 这种情况下, 如果项目本身没
有带测试, 或者测试覆盖太少, 会经常产生质量方面的问题.
用户提交BUG除非用户对这个软件十分关注并且十分熟悉BUG提交流程，并且用户十分热衷干这个事，并且用户时间比较宽，有没有什么办法改善这些问题？
有很多努力改善这个问题的方案了, 比如 Ubuntu 的 Apport 会在软件崩溃/升级失败等问题时产生相当详尽的错误报告, 并且以图形界面引导用户报告.
不过这样的方案也有比较明显的问题:
- 这类方案会大幅加大发行版 Bug Tracker 的维护难度, 因为很多用户 (包括我以前) 都会在懵懵懂懂的状态提交一个几乎只有 Apport 收集
的信息的错误报告, 而且由于自己不知道这个问题是不是和别人一样, 面对同一问题的这样的错误报告会出现很多重复. 因此 Launchpad 上有相对较多的
Bug 分类/整理人员来应付这种情况.
- 大量用户并不跟进错误报告. Qian Hong 同学曾经在某篇巨著(忘记是哪篇了 :P)里提到过, 跟进错误报告需要的时间精力比报告还要多, 而且通常
是直接决定错误报告处理速度/结果的重要因素. Apport 虽然引入了方便的报告 Bug 的流程, 但是对跟进 Bug 的流程没有做出任何帮助 (也的确是很
难帮上忙), 所以导致 Bug Tracker 上报告但不跟进的 Bug 明显变多了 (普通用户不知道/懒得跟进的还是相当多的).
不过总的来说, Apport 依然是对用户报告 Bug 困难问题的一个相当有效的解决方案.
相应的 Fedora 的打包者 Christopher 也给出了自己体会，未来的大方向将是自动化：
本来打字不太方便不想说了，不过同作为包工（Fedora），也趁机谈谈我的看法。
软件测试究竟谁来做，基本这3（也可以是4）个：
上游（例：https://mail.gnome.org/mailman/listinfo/gnome-qa-list）
- unit 测试，integration 测试，regression 测试；
- 绝大部分大厂软件出厂或者发行前会有 QA 来做；Google，有委员会；RH 的内核工程师，还有 QA 工程师；
- 代码测试，使用第三方测试工具（travis，jenkins，coverity，xxx ）；
- 其他 whitebox 测试；
- 模拟 blackbox 测试（目前用户上报的问题中不少如果上游考虑细致，这一步可以验出来的，很不幸这一步很不好弄）；
- 开源软件一般来路复杂，可能测试者和作者就是一个人，每个人都有脑洞，有时候看不出来 bug；
- bug 究竟是什么，也是一个问题，比如马同学；
包工（例：https://admin.fedoraproject.org/pkgdb/users/packages/cicku）
- 自带测试套件执行通过；
- 编译完能够运行。我会使用一下，但不可能都天天用；
- 大部分情况包工不是上游，我只负责编译，链接出来的东西不是 corrupt 即可。至于是不是造轮子，是不是渣代码，不管；
- 严重的预处理错误会修复并提交；
- 严重的潜在语法 bug 会修复并提交；
- 追踪上游 trac；严重的 bug 直接上 patch 重新编译提交更新（比如 mate/kde 桌面，mate 的开发者在
Fedora 有2个，经常看见有更新），不严重的推到下一个版本发布（xfce? XD）；
- ABRT 支持的语言如果有 backtrace 提交上来，我会直接开调试工具，能够修复的一般自己修复了然后交 pull
request，不能修复的直接扔给上游；
- 上游也不管就算了 XDDD（上游已死）；
下游 QA 组（例：https://qadevel.cloud.fedoraproject.org/）
- 一部分人就是包工；
- 一部分来自 RH，负责基础包（https://fedoraproject.org/wiki/User:Adamwill，Mandriva 前社区经理）；
- proventester 测试更新（http://fedoraproject.org/wiki/Proven_tester）；
- 发行版发布前 Fedora QA 只测基础包有无严重缺陷（RHEL @base
的，4大桌面环境，还能看见人测试），这部分最重要，能否定期发布就看这个。（https://qa.fedoraproject.org/blockerbugs）；
- 发行版发布后主要测试包更新是否有 regression，比如 upgrade path
失效，文件冲突（http://autoqa.fedoraproject.org/）；
- 源码完整性审计防止后门（最近一次：https://lists.fedoraproject.org/pipermail/devel/2014-January/193537.html）；
- RH 安全响应团队监控 CVE（https://fedoraproject.org/wiki/SecurityResponseTeam）；
- Fedora 基础设施有专门的 QA，讨论很多（我能看，你们恐怕不行
https://phab.qadevel.cloud.fedoraproject.org/）
用户（奇葩问题探索者）
- 小白鼠发行版用户大部分日常使用说白了就是在做 blackbox 测试，只要看是否 “结果 == 预期” 即可，也就是能不能用；
- ABRT 反馈（https://retrace.fedoraproject.org/）；
- 胡诌，有些是个人问题，也弄成 bug 差评。
部分问题就来了：
- 我使用的时候是英文环境，某些国际化处理相关的工具，比如文本编辑器，文档管理器，处理 CJK
等字符会有问题；上游不是语言学家，也没有人协助上游搞国际化测试；
- 抱歉，实话说，你遇到的问题的确是问题，但是之前我遇不到 :)；
- 不提交 backtrace，然后指望短短几行问题描述让我解决的；
- 有时候维护的仅仅是软件，比如 mldonkey，个人平时用它下载，可是这玩意儿是 ocaml 写的，会的人少，包工解决不了；
- ABRT 只不过界面带中文，Bugzilla 照样是英文，看不懂，提交不了；
于是某倒霉群体就会抛出“怎么这么难用”之类的话语。现实：
- 越小众的工具出了问题越没人管；
- 软件测试有一本巨厚的书，还出了第二版，可见是门学问（http://www.amazon.com/Foundations-Software-Testing-2nd-Edition/dp/8131794768）；
所以测试真的好复杂的。bug 提交流程短期内不会提高，考虑到用户综合水平，语言表达能力等因素。
包工如果认真起来可以报的 bug 多了去了，可惜太浪费时间了。
PS:
- anaconda 等图形界面工具，有 AutoQA 来自动创建虚拟机模拟图形界面来测试，SUSE
正在搞（https://openqa.opensuse.org）。
看来指望靠打包者汇报 Bug 来提高软件质量是不切实际的，那么精简特性可行否？
在 Qian Hong 看来事情并没有表面上那么简单：
做加法容易，做减法难。
假设abiword有三个用户：
A说，砍掉支持那么多格式的功能，我只要支持doc就好，我只要支持中文就好！
B说，砍掉那么多语言支持，我只要支持英文就好，支持越多格式越好！
C说，我用abiword编辑xxx格式很多年了，绝对不要砍掉这个功能！
开发者听谁的？
这里有一个误区是，以为减少功能特性真的能减少bug，实际情况却很复杂，没有量化的证据能证明减少功能一定能减少bug，也没有量化的证据能证明相反的观点。
可以做一个思想实验，看看减少功能是否真的一定能减少bug：假设abiword砍掉了二十多种格式支持，只支持一种格式，那么中文支持会不会自动
变好呢？如果没有中文用户/开发者参与开发和测试，那么我认为少几种格式支持并不会让中文支持自动变好，因为原来的开发人员和测试人员仍然不懂中文，并不
会因为格式支持少了，他们就自动懂中文了。（但是，有可能因为格式支持少了，他们有更多的时间陪伴家人，这是好事）
我举一个没有办法量化的佐证，试图证明增加功能和减少bug并不是矛盾的。
以Wine项目为例：
几年前，Wine项目不支持ActiveX控件；几年前，Wine项目中文字体乱码问题非常严重（累计有十几个不同的bug引起不同条件下的乱码）；几年
前，Wine项目几乎没有中国开发者。
2010年，Wine开始支持ActiveX控件，为了解决网银的问题，我开始给Wine项目报bug，后来报了太多bug，遭到了报应，转变为一名
Wine开发者自己面壁修bug，而我最早修复的几个bug都是中文乱码的问题。在这个特例上，“增加功能”吸引了“更多用户”，“更多用户”意味着“更
多潜在贡献者”，”更多潜在贡献者”最终帮助完成“减少bug”这个目标。
你可能觉得这是个特例，不过我认识的其他开源开发者朋友，大部分也有自己的一段从用户转变为开发者的故事，这类故事一般都不违背“增加功能”-“增加用户”-“增加贡献者”-“减少bug”这样的套路。
一个更有说服力的例子是编译器。如果把支持的语言算作功能特性，把支持的平台算作功能特性，那么功能特性越多的编译器，核心功能的bug会越少，因
为功能越多用户群越大，越多人参与测试bug就越容易得到暴露，恰好编译器的用户群又有不小的几率能转变为临时/长期的贡献者。
举这些例子，并不是为了证明“减少功能特性能减少bug”是错的，也不是为了证明“增加功能特性能减少bug”是对的，只是为了说明：事情往往没有一眼看上去那么简单。
关于开源软件质量的讨论还在继续，如果有兴趣，不妨加入进来。不管如何，可以肯定的是一个高质量的 Bug 报告对于开源软件的质量不无裨益。
此外，这里有 tonghuix 近期对于开源社区运营的一些看法，“下载-使用-骂娘”的吐槽风气其实并不可取。 | 
