开始加入gnu toolchain的开发

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

这里有一个比较详细的，http://sourceware.org/gdb/wiki/JoelsCodingStyleCheatSheet
虽然是给gdb开发者看的，但是基本适合其他gnu toolchain项目。

还有的时候，邮件标题可以用 [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讨论。