2011/1/10 Hui Zhu <teawater@xxxxxxxxx>: > 2011/1/10 Yao Qi <qiyaoltc@xxxxxxxxx>: >> 之前答应过,说写一个这样的东西。写完了,觉得有点散。大家多给意见吧。 >> >> >> >> 很多刚刚加入gnu toolchain开发的工程师,都会被各种各样的规定,缩写还有交流方式搞得晕头转向。本文就是为了让刚刚进入gnu >> toolchain的开发的工程师简单介绍一下在这个圈子里边工作的一些特别之处。 >> >> 1 开发流程 >> checkout change diff submit approve commit >> >> checkout就不用说了,绝大多数人都知道怎样check out代码。 >> >> change: >> 这里以emacs为例,编写代码要注意gnu的编码规范。写代码前,自己好好读两遍。 > > 是不是也写一些非emacs的人怎么办 或者给一个提示 比如 写changelog你可以参照 相应目录的ChangeLog 大部分要求每行最好不要超过72 这里加上这样的 "对于其他编辑器,比如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按照附件的形式,用纯文本的方式,放送到列表。在邮件中简单介绍你的修改的目的和概要,如果需要,保证这个修改没有引入regression。如果还不明白,看看别人是怎样写patch的。不过还不明白,可以在hellogcc讨论。 > > 是否简单介绍下标题[RFA] [RFC] [PATCH] > > 还有比如作大规模的PATCH最好分成几个 每个文件一个 > 好的。这一段改成这样 发送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讨论。 > > 是不是写一下签协议这个事情 我现在还是很模糊 貌似你们在IRC讨论了很久这事... > 具体细节不是很清楚;Eric Fisher帮忙看看, "当patch被apprve之后,第一次提交patch的人,需要得到FSF assignment 才能够最后由别人或者自己把这个patch commit到FSF的代码仓库。对于每一个项目,比如gcc,gdb等,需要给FSF发信,说明自己的意图。他们会给你一个表格,填完表格,签字后,发给他们。FSF那边同意以后,会回复你一个hard copy的form。这个比较慢。从严格的法律角度来讲,你必须得到了这个hard copy的form,你的代码才能被FSF使用,但是一般都是只要FSF确认那个hard copy已经寄出,你的代码就可以被使用了。上边所述都是给在以个人身份给gnu toolchain做贡献的开发者,如果你是以公司的名义去做,就不是上边这样的流程了。" 我感觉,貌似单独写一篇关于fsf copyright assignment的,比较好。 -- Yao Qi <qiyaoltc AT gmail DOT com> http://sites.google.com/site/duewayqi/