[hellogcc] Re: [hellogcc] [投稿] 开始加入 gnu toolchain的开发
- From: Hui Zhu <teawater@xxxxxxxxx>
- To: hellogcc@xxxxxxxxxxxxx
- Date: Mon, 10 Jan 2011 15:48:32 +0800
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
>
> 建议安装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最好分成几个 每个文件一个
>
> 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，慢慢的，就会知道更多要改进的地方了。
是不是写一下签协议这个事情 我现在还是很模糊 貌似你们在IRC讨论了很久这事...
>
> 总结:
>
> 罗马不是一天建成的。我们也不可能在很短的时间内熟悉这个community，更不要奢望读了这篇blog就可以熟悉这个community的工作方式。我想，只要我们保持热情去贡献，增加交流，在我们中国诞生global
> maintainer也不是不可能的事情。
>
> 齐尧
>
> --
> Yao Qi <qiyaoltc AT gmail DOT com>
> http://sites.google.com/site/duewayqi/
>
Other related posts:
