本文内容适用于任意的开源项目。
对于用户来说,没有编程技能什么的都是很正常的事情,但是除此之外还是有很多事情可以做。
1、汇报bug
这是我个人最看重的一点,因为相对而言这个占用时间最少,但是非常重要。有时候经常见到讲这里是废品,那里是废品的问题。但不知道大家都有没有去实际汇报bug。有时候你的情况可能是少数情况,但不代表它不重要。开发人员能覆盖用例是有限的。bugs.kde.org也不完全是汇报bug的地方,同时也有一个选项是wishlist,如何区分bug和wishlist最简单的方法就是某个功能是否应该这么做还是你想要让它这么做。
KDE的站点为:bugs.kde.org
在汇报bug时的几个注意事项:
在汇报之前先进行搜索,当然由于具体文字使用问题,很可能找不到duplicate的bug,意思是这个bug已经有人汇报过了(我其实汇报过不少最后成为dup的…),即使成为了dup也没关系。
尽量详细的描述bug,主要体现在几点上:
1)你的环境,包括版本,cpu架构,发行版,你认为相关的软件包版本。
2)可以重现这个bug的步骤。
开发者debug是很困难的,尤其是遇见一个他不能重现的bug的时候,这种情况就只能靠猜了。所以一个可以重现的步骤和环境异常重要,第一条也是保证开发者可以有一个确定的环境可以重现这个bug。
KDE还提供了一个工具可以帮助你,就是Dr. Konqi,在发生崩溃类的bug时,一般它就会跳出来,显示进程的调用堆栈。已经提供一个向导帮助你提交bug(如果堆栈不达到3星是不能使用这个向导最终提交的,请注意)。
调用栈会有一个评分,这牵涉到它包含了多少信息。并非1星的就是没用的,一般我的判断标准就是有没有相关的函数名和库名。这可能需要一些知识。无法判断的时候其实也可以交给开发人员判断。
另外一个问题就是如何提高这个评分。这牵涉到编译器的优化,一般来说,发行版在编译这些软件包的时候会将这这些帮助debug的信息都drop掉,减少包的大小,因此有些发行版也提供了包含有debug信息的软件包,我所知道的有fedora(其他我是真不了解,没有提到不代表偏见),一般包的命名就是原包名-debug或者-dbg,可能在不同的发行版中保存于特别的软件仓库中需要手动开启。
如果有条件的话,当然是自己编译一下也ok。由于Archlinux的打包文件异常简单,因此我以Archlinux为例。首先最好去找发行版的打包文件,减少configure的量,以及保证编译选项一致,以及卸载时方便。
对于Arch来说首先需要在PKGBUILD的options里面加入!strip,strip的功能是将文件中的符号去掉,所以需要添加。其次就是设置CFLAGS,CXXFLAGS,在build函数的开头开始写入:
export CFLAGS="-g -O0" export CXXFLAGS="-g -O0"
-g的含义是保留符号,-O0的含义是编译优化等级为0。这都能在显示调用栈的时候显示出具体代码的行数,以及中间被优化掉的函数调用名称。CFLAGS对应C语言,CXXFLAGS对应C++语言,对于KDE来说,大部分程序都是C++开发的。
然后你可能需要在配置时修改一些参数。对传统./configure , make , make install的方式来说,可以先手动./configure –help看看有没有和debug相关的选项。
对于cmake来说(也就是大部分KDE程序),会有这样一个参数-DCMAKE_BUILD_TYPE=Release,这里可以修改为-DCMAKE_BUILD_TYPE=Debug。
以上提升调用栈质量最直接的办法。如果有时间或者空闲自己编译下当然好,没有的话做到前面所说的也没有问题。
2、身体力行帮助宣传
当然不需要像传教士一般,我觉得做到这个程度就ok了:例如在别人询问推荐的时候,回个帖推荐自己喜欢的程序,如果帮到了别人不也是一件很开心的事情吗?
3、参与一些非代码类工作
比如本地化翻译。对于小项目来说,可能就是和开发者直接联系,对于KDE这种,一般都会有一个本地的邮件列表/组织可以联系,比如简体中文就是kde-china at kde.org。
可以帮助编辑的工具有以下几个,poedit(GNU提供,gtk),gtranslator(GNOME),lokalize(KDE)。功能大同小异,选择自己喜欢的就好。
4、提供自己的建议
前面所说的wishlist可能不足以描述复杂的例子,这里有个更合适的地方:http://forum.kde.org/viewforum.php?f=83
这可能需要你做一些关于界面的mockup来帮助表达你自己的建议,也更加适合讨论。
5、donate
细节咱就不说了,别找错位置和帐号打错款,Paypal干这事很容易的。
ONE FEEDBACK