Linux版本介绍

xu_bin

Linux内核开发流程当前包括一些主内核分支，和很多不同的子系统专有的内核分支。它们是：
－ 主 2.6.x 内核树
－ 2.6.x.y -stable 内核树
－ 2.6.x -git 内核补丁
－ 2.6.x -mm 内核补丁
－ 子系统专有内核树和补丁
2.6.x 内核树
2.6.x 内核树是有Linus Torvalds维护的，可以在kernel.org的pub/linux/kernel/v2.6目录里找到。它的开发流程是这样的：
－ 当一个新的内核发布之后，一个为期两个星期的窗口打开，在这段时间里维护者可以提交大的补丁给Linus，通常是已经在-mm内核中存在了一定时间的补丁。推荐的提交补丁的方式是通过git（有关git的更多信息可以在http://git.or.cz/找到），但是普通的补丁也是可以的－两个星期之后一个-rc1内核发布，然后现在只可以再加入不会为内核添加新功能的补丁，因为那样的补丁可能会影响这个内核的稳定性。请注意这个时候一个整的新驱动（或者文件系统）可以被接受。因为只要这个变动是自成一体的并且不影响它之外的代码的话，就不会有产生回归的危险。在-rc1发布之后，git可以用来发送补丁给Linus，但是这些补丁也需要发到一个公开的邮件列表里以备审查。
－ 当Linus确信当前的git（内核代码管理工具）树已经处于一个合理的健全状态，足够测试时，一个新的-rc就会发布了。目标是每周发布一个新的-rc内核。
－ 这个过程将会持续到内核被认为可以发布为止，整个流程会持续大概6个星期。
Andrew Morton在linux-kernel邮件列表里写的有关内核发布的一句话值得提一下： “没有人知道什么时候一个内核会发布，因为它发布的依据已经掌握的bug状态，而不是事先设想好的一个时间线。
2.6.x.y -stable 内核树
有四个数字版本号的内核是-stable内核。他们包含一些相对较小的和重要的修正。这些修正针对的是在一个给定2.6.x内核中发现的安全问题或者重大的回归。
对于想使用最新的稳定内核并且对于帮助测试开发/实验版本不感兴趣的用户，这是推荐使用的版本。
如果没有2.6.x.y版本，那么最高版本号的2.6.x内核是当前稳定内核。
2.6.x.y由“stable”团队维护，每周发布一次。
内核树里的文件Do*****entation/stable_kernel_rules.txt描述了什么样的改动可以被-stable树所接受，以及发布流程是怎样工作的。
2.6.x -git 补丁
这些是在git仓库里管理的Linus内核树的每日快照。这些补丁每天发布一次，代表Linus树的当前状态。它们比-rc内核更具实验性质，因为它们是自动生成的，以至没有人曾经瞟上一眼来检查它们是否处于健全状态。
2.6.x -mm 内核补丁
这些是Andrew Morton发布的实验性质的内核补丁。Andrew取得所有不同子系统的内核树和补丁，连同从linux-kernel邮件列表里拉过来的补丁，把它们融合在一起。这个树是新功能和补丁证明自己的场所。如果一个补丁在-mm里证实了自己的价值，Andrew或者子系统维护者就会把它提交给Linus，以求被收录于主线内核中。
强烈建议所有的新补丁在发送给Linus之前都先发到-mm树里测试一下。
打了此种补丁的内核不适用于追求稳定的系统中，运行它们比运行其他任何分支都更具冒险性。
如果你想帮助内核开发流程，请测试并使用这些内核发布，并在linux-kernel邮件列表里提供回馈，如果你发现任何问题的话，哪怕什么问题也没有。
在所有其他实验性质的补丁之外，这些内核补丁通常还会包含在发布时在主线-git内核中已经包含的改动。
-mm内核没有一个固定的发布计划，但是通常在每两个-rc内核发布间歇期会发布一些-mm内核（1到3个都很常见）。
子系统专有内核树和补丁
一些不同的内核子系统开发者公布他们的开发树，这样其他人可以看到在内核的不同领域里正在发生什么。这些树都会被包含在-mm内核发布中。
下面是一些不同的内核树的列表：
git树：
- Kbuild 开发树, Sam Ravnborg
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI 开发树, Len Brown
kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- 块设备开发树, Jens Axboe
kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM 开发树, Dave Airlie
kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64 开发树, Tony Luck
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394 开发树, Jody McIntyre
kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
- infiniband, Roland Dreier
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata, Jeff Garzik
kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- 网络驱动, Jeff Garzik
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia, Dominik Brodowski
kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI, James Bottomley
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
其他git内核树可以在http://kernel.org/git找到
quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
报告Bug
bugzilla.kernel.org是Linux内核开发者追踪内核bug的地方。我们鼓励用户在这个工具中报告他们发现的所有bug。欲知使用内核bugzilla的具体细节，请看： http://test.kernel.org/bugzilla/faq.html
主内核源码目录中的REPORTING-BUGS文件有一个报告可能有的内核bug的模板，并详细讲述了内核开发者需要什么样的信息，以便他们可追踪到问题所在。
邮件列表
就像上面的一些文档所描述的，大多数核心内核开发者参与Linux内核邮件列表的讨论。如何订阅和取消订阅这个列表的细节可以从这里找到：
http://vger.kernel.org/vger-lists.html#linux-kernel
网上很多地方都有这个邮件列表的存档。使用一个搜索引擎来搜索这些存档。比如：
http://dir.gmane.org/gmane.linux.kernel
强烈建议你在向列表发邮件询问之前，先在存档中搜索一下你想问的话题。很多事情都已经详细的讨论过了，它们只在邮件列表存档中有记录。
很多内核子系统也有它们单独的邮件列表，在那里开发者们做他们的开发工作。请查看MAINTAINER文件来找到这些不同子系统的邮件列表。
很多邮件列表放置于kernel.org之上。有关它们的信息可以在这里找到：
http://vger.kernel.org/vger-lists.html
请记住在使用这些列表时请遵守良好的行为习惯。下面的URL有一些如何在邮件列表上与人交流的简单的准则，虽然有一点俗气：http://www.albion.com/netiquette
如果有许多人回复你的邮件，收件人的抄送列表会变得很长。在没有一个合理的理由时不要把任何人从抄送列表中去掉，或者不要只回复被列出的地址。要对于收到同一封信两次感到习惯，一次从发信者，一次从邮件列表。不要为了好看而加上别致的邮件头部，人们不喜欢这样。
记得保证你的回复的上下文和属性的完整性，在你的回复的最上方保留类似 “John Kernelhacker wrote ...“的字样，把你的回复写在被引用的段落之间，而不要写在邮件的最上方。
如果你在你的邮件里加入了补丁，要确保它们是纯文本，就象Do*****entation/SubmittingPatches里所说的。内核开发者不希望处理附件或者压缩的补丁；他们会希望评价你的补丁的每一行，只有纯文本才符合这个要求。
确保你使用的邮件客户端软件不会破坏空格和制表符。你可以发一个邮件给你自己，然后应用你自己的补丁来先做个测试。如果不行，修复你的邮件程序或者换一个。
最重要的一点，请记得显示出你对其他订阅者的尊重。
和社区一起工作
内核社区的目标是提供可能提供的最好的内核。当你提交了一个补丁等待被收录时，它会被且仅被该领域的技术权威所检查。所以，你应该期待什么呢？
－ 批评
－ 评论
－ 被要求改动
－ 被要求解释
－ 沉默
记
住，这是让你的补丁进入内核的一部分。你必须能够接受对你的补丁的批评和评论，在技术的层面上评估它，然后要么对你的补丁作出修改，要么提供清晰而言简意
赅的理由解释为什么不应该做改动。如果没有对你的补丁的回复，等几天再试一次，有时候在流量很大的时候信件可能丢失，或被人忽略遗忘了。
你不应该做什么：
－ 期待你的补丁没有任何疑问的被接受
－ 不接受批评，不承认缺点
－ 忽略评论
－ 在不做任何修改的情况下再次提交补丁
在一个寻找可能存在的最好的技术解决方案的社区里，关于一个补丁怎样的有用必定会存在不同的意见。你应该采取合作的态度，愿意改变你的意见以适应内核的需要。或者至少愿意证明的你的观点有价值。记住，犯错误是可以接受的，只要你愿意朝着正确的解决方案努力。
如果对于你的第一个补丁的回应只是一些要求你改正的意见，这很正常。这并不意味着你的补丁将不会被接受，这些意见也不是针对你本人的。你要做的只是改正你的补丁然后重新发送。
内核社区和企业架构的区别
------------------------
内核社区和大多数传统的企业开发环境工作形式不一样。这里有一个列表你可以尝试遵照执行以避免出现问题：
关于你提交的补丁的好的说法：
－ “这个可以解决多个问题。”
－ “这个删除了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
所有这些事情有时候很难做到。要想完美做到这些要求可能需要几年的时间。这是一个持续的发展过程，需要很多耐心和决心。但是不要放弃，这是可以实现的。很多人已经做到了这一点，每个人都经历过你现在这个阶段。
-------------
感谢Paolo Ciarrocchi允许我在他所写的文章的基础上写成本文的“开发流程”部分，感谢Randy Dunlap和Gerrit Huizenga为了他们应该说的和不该说的一些事情。也感谢Pat
Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, VojtechPavlik, Jan
Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov,
Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,DavidA. Wheeler, Junio
Hamano, Michael Kerrisk, 和 Alex Shepard为了他们对于本文初稿的评论和意见。
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/50753/showart_401283.html