Inside SW,FW and HW R&D

内核社区和企业架构的区别
————————
内核社区和大多数传统的企业开发环境工作形式不一样。这里有一个列表你可以尝试遵照执行以避免出现问题：
关于你提交的补丁的好的说法：

－ “这个可以解决多个问题。”－ “这个删除了2000行代码。”－ “这个补丁解释了我尝试想描述的东西。”－ “我在5个不同的架构上测试了它……”－ “这里是一系列的小补丁，它们可以……”－ “这个在典型的机器上可以提高表现……”

你应该避免的坏的说法：

－ “我们在AIX/ptx/Solaris上都是这样做的，所以它一定是好的……”－ “我已经这样做20年了，所以……”－ “我的公司需要这样做来挣钱”－ “这是我的一千页的设计文档，它解释了我的想法”－ “我已经在它上面花了6个月的心血……”－ “这里是一个5000行的补丁，它……”－ “我重新写了所有现有的垃圾，在这里……”－ “我有完成期限，这个补丁必须现在被应用。”

内核社区和大多数传统软件工程工作环境的另一个不同是没有面对面的交流。使用email和irc作为主要交流形式的好处之一是不会存在基于性别或者种族的歧视。Linux内核工作环境接受女士和少数民族，因为你的存在只是一个email地址。国际化也帮助我们实现了平等的工作环境，因为你无法根据一个人的名字来判断一个人的性别。一个男人可以叫Andrea，一个女人可以叫Pat。大多数为Linux内核做过工作或者发表过观点的女性对此都深有体会。
对于不习惯英语的人来说语言障碍可能会导致一些问题。对于语言的良好的掌握可以令思想在邮件列表上交流的更畅通，所以建议你在发送邮件之前检查一下你的邮件内容在英语里是否有意义。
打散你的补丁
Linux 内核社区不乐意接受大段的代码，一般会在收到时立刻丢弃。你的补丁需要适当的被介绍，讨论，并打散为细小的，独立的片段。这几乎和公司里经常做的完全背道而驰。你的提议必须在开发流程的早期提出，这样你才可以收到足够的关于你的工作的回馈。这也会令社区感觉到你是在和他们一起工作，而不是利用他们作为倾倒你的补丁的场所。但是，请不要一次向邮件列表发送超过50封email，你的一系列补丁的个数应该永远小于这个数字。
把补丁打散的理由如下：
1) 小的补丁增加了你的补丁被应用的机会，因为它不需要花太多的时间和精力来检查它的正确性。一个5行的补丁，一个维护者只要花一秒钟瞟一眼然后就可以应用了。不过，一个500行的补丁需要一个小时来检查是否有错误（所需的时间跟补丁的大小差不多成指数级别增长）。小补丁也使得在出错的时候很容易 debug。如果出了问题，小补丁可以一个一个的取消，大补丁就比较麻烦了。
2) 除了要把补丁打散之外，在提交之前还要重写和简化（或者只是简单的重排序）你的补丁。这一点也是很重要的。
这里有一个内核开发者Al Viro所做的类比： “想一下一个老师为一个数学系学生批改作业的情景。老师不希望看到学生在回答出正确答案之前的尝试和失败。他们想看到最清楚的，最优美的答案。一个好学生了解这一点，并不会在得到最终答案之前把他们的中间结果提交上去。对于内核开发来说同样是这样。维护者和评论者不希望看到问题的解决方案背后的思考过程。他们想看到一个简单和优美的解决方案。”
提供一个优美的解决方案和同社区一起工作讨论你未完成的作品，要维持此二者之间的平衡可能是一个很有挑战性的事情。所以应及早的参与一个开发流程以获得回馈来改进你的作品，但仍要保证你的补丁的小块头，这样它们可能提早被接受，哪怕是在你的整个作品还为完成时。
也请注意，如果你的补丁尚未完成而且还需要修改，请不要提交。
证明你的改动
除了打散你的补丁之外，让Linux社区理解为什么他们要加入这项改动也是很重要的。新的功能必须要被证实它们需要而且有用。
为你的改动写文档
在你提交补丁时，要格外留心你在email里说的话。这些信息将会成为这个补丁的ChangeLog信息，将会被保留从而使每个人任何时候都可以看到。它必须完整的描述这个补丁，包括：

－ 为什么这个改动是需要的－ 这个补丁的整体设计方案－ 实现细节－ 测试结果

欲知这个过程到底看起来是什么样子的，请看这个文档的ChangeLog部分： “The Perfect Patch”
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
所有这些事情有时候很难做到。要想完美做到这些要求可能需要几年的时间。这是一个持续的发展过程，需要很多耐心和决心。但是不要放弃，这是可以实现的。很多人已经做到了这一点，每个人都经历过你现在这个阶段。