从Lu申请maintainer被拒看什么是社区

Jia.Liu@hellogcc

今天下雨,回不去,随便写点儿盲人摸象的个人观点,解解闷,自娱自乐总行吧。

关于技术方面的东西,限于我的工作岗位,我能开放的不多,但是我已经把一些能够和大家分享的拿了出来,而且还会继续和大家分享。技术这玩意儿,你偷着藏着掖着,他也不会生出一窝小的来,反而会过时,无用。就像20年前吧(好古老的历史哦),gcc-2.95的时候,某玩意儿说gcc不行,我们比gcc强多了,我们要取代gcc。结果,20年过去了(一代人啊!一代人的青春啊!),我们gcc依然是世界的主流!为什么?因为我们是真正的开源项目!我们有一个真正的开源社区!我们是真正开放的社区!我们是真正公平的社区!

Lu说自己参与binutils和gcc开发20年了,想申请Linux/x86的maintainer。
iant说,不行,你是一个好的开发者,但是你从不review别人的patch,maintainer是对社区有责任的,你没有做到。
Lu说,我申请是因为DT_INIT_ARRAY问题一直得不到解决。
Jan说,这个问题存在很久了,我们在解决。(非常官方的回答哦。)

拒绝Lu可是需要勇气的啊,毕竟参与20年的老人了,而且还“代表”某特。但是,社区不在乎某个公司,某一个人,社区就是社区!是大家的社区!

让我们邪恶的猜想一下,Lu是因为看到很多maintainer的patch不怎么review就进去了,想自己的patch好进。
你可以说我没有根据瞎说,自己可以去check一下binutils的changelog,他的patch都是经过review并接受的么?
好在google的人开始申请binutils和gdb的帐号了,我们期待这两个社区变得越来越规范吧,为了全社区的利益,为了大家的利益。只有规范的社区才能带来更多的好处,如果你希望社区是有几个人控制的,那么我只能怀疑你动机不良,想作为“人治”的一分子,祸害社区的发展了。

这就是典型的权力欲望,只想享受权利,不想承担责任。没有意识到,一个人权力越大,责任也就越大。所以,他越远当不了蜘蛛侠。

OK,不扯了,什么才是社区?什么才叫社区!

gcc社区才是社区!所有的代码都是通过patch的形式,通过了maintainer的review才能进去的!不会因为某种原因走后门的,不会因为你跟某个maintainer关系好,他就接受你的patch,不会因为你是某个公司的,你就能左右patch是否被接受。

社区,是一个开放的,任何人都可以参与,只要你愿意,你真心给社区提交代码,做测试,找bug等等。

社区,是一个公平的,社区负责人(主要是maintainer),不能只享受权力带来的好处,而不负责任。不能为了一己私利而损害别人的利益,损害社区的利益。

社区,不是小圈子,只有某两个公司和某几个高校还有某个研究所的人才能参与,别人都靠边站。

你弄个伪开源的项目,弄个网站,自己管自己叫社区,那不行的,没有人参与,没有人承认你的。

社区是什么?是一个奉献和索取的平衡体,你只有奉献了你的精力,不仅仅是代码哦,还有文档,还有帮助他人成长。才能得到社区成员的尊重,经济利益就不用说了,哪个global都不缺钱的。
但是!社区的前提是公平开放的!RMS那老头子玩儿了一辈子,最后不做技术了,一直想制定一套相对公平开放的规则,为什么?
一个社区要发展壮大,不可能只为极个别的人服务的,社区要为全社区,甚至社区外的人都带来好处才行。
还有非常关键的一点就是开放!开放!开放!社区不是封闭的,封闭了就成了小圈子了,你一个小圈子最多伪装成一个社区,请不要侮辱“社区”这个字眼了,你们已经把“研究”和“专家”的字眼给侮辱了。
谢谢合作!

那么,最后,我们想想,自己是什么样的人呢?自己有资格参与社区开发么?自己的灵魂肮脏到不配参与社区么?自己是一个为了满足自己的权力欲望而祸害社区的人么?
gcc社区为什么这么红火?一天光patch就几十个。是因为gcc社区的制度?还是因为gcc社区的人?

一个人的能力和他的品德并没有直接关系的。

最后,我充分相信,我们大家都是高尚的人,纯粹的人,有道德的人,脱离了低级趣味的人,有益于社区的人。

开始加入gnu toolchain的开发(之二)

xmj@hellogcc 向GNU提交代码,必须要签署FSF版权转让协议(copyright assignment),这意味着你是作为贡献者将这些代码的版权归为FSF所有。这里只介绍了以个人的名义来申请签署协议和进行开发的流程,至于以公司的名义的流程,我不清楚,故没有介绍。申请签署该协议的方法为,填写如下表格,并发送给assign@gnu.org 。下边给出样例答案。 Please email the following information to assign@gnu.org , and we will send you the assignment form for your past and future changes. Please use your full legal name (in ASCII characters) as the subject line of the message. ———————————————————————- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name […]

开始加入gnu toolchain的开发

作者: qiyao@hellogcc

很多刚刚加入gnu toolchain开发的工程师,都会被各种各样的规定,缩写还有交流方式搞得晕头转向。本文就是为了让刚刚进入gnu toolchain的开发的工程师简单介绍一下在这个圈子里边工作的一些特别之处。


1 开发流程
checkout change diff submit approve commit

checkout就不用说了,绝大多数人都知道怎样check out代码。

change:
这里以emacs为例,编写代码要注意gnu的编码规范。写代码前,自己好好读两遍。

对于其他编辑器,比如vim和eclipse,用户可以自行设置。只要符合下边的一些要求就可以了

1 敲击一下tab是两个空格,
2 如果前边有了八个空格,用一个tab替代,
3 一般源程序的宽度不要超过76或者78,
4 changelog的宽度不要超过72,

这里有一个比较详细的,http://sourceware.org/gdb/wiki/JoelsCodingStyleCheatSheet

虽然是给gdb开发者看的,但是基本适合其他gnu toolchain项目。

建议安装whitespace.el,来显示空格和tab,还可以去掉一些trail space。还有在使用git生成patch的时候,使用git diff –check,可以帮助你检查patch。

生成patch以后,一般是在patch的头部加入changelog,用mklog.pl
。这个时候不用修改源代码的changlog。

发送patch,一般gnu toolchain都用单独的邮件列表来讨论patch的。所以,把你的patch按照附件的形式,用纯文本的方式,放送到列表。邮件的题目要简单明了,因为邮件列表的流量很大,而且每个maintainer可能只注意自己需要review的patch,所以标题要让他/她知道,这个是他/她需要review的。比如,有一个patch是对arm的修改,可以这样[patch/arm] XXXXX。多看看别人怎样写的。


还有的时候,邮件标题可以用 [rfc], [rfa]之类的。rfc的意思是request for commit,而rfa的意思是request for
approval/accept。我自己并不经常用这两个,我个人感觉他们的差别在于rfc是提交自己的一个代码或者patch,希望被接受;而rfa是提交的自己的想法或者建议。比如我想建议在gdb中做一个新的feature,program slicing,我可以把我的建议和设计这样发出去 [rfa] New feature in GDB : program slicing

[note: 我个人对rfc和rfa用的不多,所以解释不是很准确]

在邮件中简单介绍你的修改的目的和概要,如果需要,保证这个修改没有引入regression。

有的时候,可能为了实现一个功能,修改是分很多部分的,比如第一部分是为了增加这样的功能,对现有代码的重构,第二部分是实现新功能的代码,第三部分是测试用例,第四部分是文档。如果作为一个patch发出去,别人review起来比较难受,也很难理解你的意图,这个时候,就要在一个邮件thread里边,把patch分多个发出去。具体操作如下,在发patch之前,自己先想好,如何把自己的修改合理的拆分到若干个patch里边去,然后第一封信写清楚你这一系列patch的目的,和大体实现,不要attach任何patch,比如
[patch 0] GDB new feature: program slicing,发送。然后依次恢复这封邮件,分别按照不同的题目,把自己的patch按照顺序发出去,比如
[patch 1] refactor existing GDB infrun to prepare for program slicing
[patch 2] support program slicing in target-independent part
[patch 3/x86] support program slicing on x86
[patch 4] test case and doc

这样的好处就是,负责doc和testcase的maintainer就需要看你的第三个patch就好了。负责x86 maintainer就看你的patch 2。而且以后给comments也比较容易。

如果还不明白,看看别人是怎样写patch的。不过还不明白,可以在hellogcc讨论。

commit的时候,加入changelog entry。在emacs里边,比较方便,M-x add-changelog-entry后,选择changlog文件,就会自动加入你的邮件地址和时期,完全符合gnu的规定。如果源代码不是很多,比如gdb,可以用emacs提供的前端pcl-cvs, pcl-git来替代命令行的操作。 M-x cvs-examine: 选择本地的cvs checkout出来的代码,等待一会后,emacs中会有一个cvs summary的buffer,显示本地目录那些改动过的文件。在提交的时候,用m选中那些需要提交的文件,然后按c,就会出现一个新buffer,里边是填写commit log。写完commit log后 C-c C-c,就完成commit了。pcl-cvs和pcl-git还有很多别的用法,可以参考网上的文章。

测试:
不要忽略自动测试的部分。个人感觉,gdb里边写的做好的部分就是testsuite了 🙂
gcc和gdb的wiki上都有一页关于编写测试用例的。建议好好读一读。如果之前对dejagnu和tcl/expect不是很清楚的人,建议去了解一下dejagnu。
regression test:如果你持续在某个toolchain上开发,最好有一个nightly build/test的环境,这里就不介绍持续测试和持续集成了。因为gnu toolchain每天都有来自不同组织处于不同目的对软件进行修改,所以,难免影响到你所希望的功能。如果发现了有regression,可以自己试试修改,这也是做贡献的一种方式。

2 参与开发
gnu toolchain都比较庞大,支持的平台很多,所以刚开始理解代码并且加入到开发是一个十分困难的事情,但是这个也是没有其它什么捷径。造成这些困难的有如下一些因素

历史悠久: 历史悠久对于一个国家或者城市来说,是一个好事情,但是,对于软件来说,这绝对不是什么好事情。

支持很多平台:

缺少文档:

开放的是代码而不是设计: 我们可以看到代码,但是很难看到设计。设计往往存在于代码的注释或者当时邮件列表里边的讨论。

寻找帮助:
由于开源软件都缺乏文档,所以碰到不会的问题,就要在社区中寻求帮助。目前,社区的交流方式有这样几种,邮件和irc。当然还有第三种,就是参加一年一次的gcc summit,但是这个对大多数人是不适用的。

邮件列表:是开发人员的主要交流手段。如何写邮件可能是另外一个话题了,我这里简单介绍一下。其实和考研写英语作文很像,就是开始就要明确地告诉别人,我需要什么样的帮助,要非常具体。这样被人才能帮助你。我们这样想,我们都希望得到大牛的指点,但是,大牛一天要收多少邮件呢?凡是他/她第一感觉能回的邮件,他就马上回了,如果有点模糊,他/她可能就跳过去了,回复的可能性很小。所以开门见山,告诉别人你的问题是什么,你都做了那些尝试,还有那些不明白,需要别人的指点。
irc:irc是一种即时聊天软件。我个人觉得,不要期望你能在irc上得到十分好的帮助,除非你和irc的人都很熟了。因为,gnu toolchain的问题,都不是一句两句能说清楚的事情(除非你问gcc 4.6.0什么发布,irc也是一个不错的地方),所以我个人认为irc在获得帮助上没有太大的用处。有一种情况是irc有用的,就是你和某一位或者几位开发人员在邮件列表上已经有过一些交流,剩下一些细节或者yes/no的问题,在irc上问一下,也还不错。

贡献:
其实在open source 社区中,贡献这个词语出现很多次,但是我们还是没有很多的贡献,至少我是这样。下边这些是为那些想为open source 做些事情的人写的,如果你只是为了用开源软件完成自己的工作或者研究项目,可以跳过这一段。首先澄清一个概念,不是只有global maintainer才可以做贡献,我们这些刚刚开始做的人,也可以。勿以贡献小而不为。我能够想到的,在社区的贡献对你有以下的帮助
1 慢慢被社区所认可和接受,这样对于以后的工作会更有帮助,也有助于下一步的发展
2 短期来讲,有助于别人帮助review你的patch
3 提高在社区的reputation

对于我们刚刚起步的人,可以做那些贡献呢?我们可以到gdb的wiki上看看,上边说了一些需要帮忙的领域,在gdb邮件列表archive里边找找相关的讨论,就能找到一些事情。这样的话,你将来碰到问题,也有人愿意帮助你。所以,尽力去发现开源软件的不足,尽力去改进它,虽然我们很多人在gnu toolchain上开发是我们的工作,但是不要把自己的贡献局限于我们的工作。

总结起来就是,眼光要放远,但是从细节着手。不要把自己的眼光之放在自己的工作的领域,要看得更宽一些,如果有机会在别的部分做一些东西,这样也有助于你有一个大局观。从细节着手,就是说,gnu toolchain的代码都很多,刚开始根本找不到要该的地方。这个时候,就要从一些小的地方开始,比如修一些bug,慢慢的,就会知道更多要改进的地方了。

总结:
罗马不是一天建成的。我们也不可能在很短的时间内熟悉这个community,更不要奢望读了这篇blog就可以熟悉这个community的工作方式。我想,只要我们保持热情去贡献,增加交流,在我们中国诞生global maintainer也不是不可能的事情。

由GFDL和GPL引出的问题

由GFDL和GPL引出的问题

注:本文根据http://gcc.gnu.org/ml/gcc/2010-06/msg00058.html整理翻译,仅供参考。如有错误或不恰当的地方,欢迎指出。

GCC的代码是GPL的,GCC的文档是GFDL的。

现在,GCC开发者希望将target hooks(目标机钩子函数)统一在一个文件(target.def)中定义,然后通过工具(genhooks)自动生成头文件,初始化和文档。这就引出了一个问题,是否可以从GPL的代码来生成GFDL的文档。相反的,对于在tm.texi中已有的文档,是否可以直接拷贝到GCC的代码中?

Mark Mitchell特意跟GCC指导委员会(Steering Committee)和RMS(Richard M. Stallman)讨论了第一个问题。问题如下,

“Can we take comments (not code) from FSF-owned GPL’d code and process
them in some way that results in them being included in a GFDL’d manual?”

RMS的回答如下,

“If Texinfo text is included the .h files specifically to be copied into
a manual, it is ok to for you copy that text into a manual and release
the manual under the GFDL.”

其中,这里的“you“是指”the GCC maintainers”,并且这个许可只被限定为要将所作的改动贡献给FSF。而对于其他人,则不可以。RMS承认这是一个问题,不过他说我们需要一个GPL许可例外(GPL license exception),使其成为一个完全通用的许可,但是这需要很长一段时间。

于是,现在GCC的文档中,又多了一个tm.texi.in。对于GCC维护者,他们可以通过工具(genhooks)根据GPL的target.def和GFDL的tm.texi.in来生成GFDL的tm.texi。对于tm.texi中已有的文档,现在还无法直接拿到target.def中使用,所以只能在tm.texi.in中使用。对于新的target hooks文档,则在target.def中定义,然后自动生成到tm.texi中。

GCC的Makefile也做出了相应的修改,来生成tm.texi,并与现有的tm.texi进行比较。如果发现不一致,并且tm.texi要比tm.texi.in新,则会报如下错,

“You should edit $(srcdir)/doc/tm.texi.in rather than $(srcdir)/doc/tm.texi.”

如果发现不一致,并且tm.texi不比tm.texi.in新,则会报如下错,

“Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to $(srcdir)/doc/tm.texi.”