[hellogcc] Re: [hellogcc] Re: [hellogcc] Re: [hellogcc] [投稿] 开始加入 gnu toolchain的开发
- From: Hui Zhu <teawater@xxxxxxxxx>
- To: hellogcc@xxxxxxxxxxxxx
- Date: Tue, 11 Jan 2011 20:53:02 +0800
提个小建议 我觉得1 2是不是可以调换个位置
先介绍如何参与 如何问问题
然后是如何作PATCH
不过只是建议 :)
渔夫同学写了下了 看来你们这成上下部了...
2011/1/10 Yao Qi <qiyaoltc@xxxxxxxxx>:
> 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/
>
Other related posts:
