的，而不是根據一個(gè)事先制定好的時(shí)間表?！?/div>
2.6.x.y -stable（穩定版）內核源碼樹(shù)
-----------------------------------
由4個(gè)數字組成的內核版本號說(shuō)明此內核是-stable版本。它們包含基于2.6.x版本
內核的相對較小且至關(guān)重要的修補，這些修補針對安全性問(wèn)題或者嚴重的內核退步。
這種版本的內核適用于那些期望獲得最新的穩定版內核并且不想參與測試開(kāi)發(fā)版或
者實(shí)驗版的用戶(hù)。
如果沒(méi)有2.6.x.y版本內核存在，那么最新的2.6.x版本內核就相當于是當前的穩定
版內核。
2.6.x.y版本由“穩定版”小組（郵件地址<stable@kernel.org>）維護，一般隔周發(fā)
布新版本。
內核源碼中的Documentation/stable_kernel_rules.txt文件具體描述了可被穩定
版內核接受的修改類(lèi)型以及發(fā)布的流程。
2.6.x -git補丁集
----------------
Linus的內核源碼樹(shù)的每日快照，這個(gè)源碼樹(shù)是由git工具管理的（由此得名）。這
些補丁通常每天更新以反映Linus的源碼樹(shù)的最新?tīng)顟B(tài)。它們比-rc版本的內核源碼
樹(shù)更具試驗性質(zhì)，因為這個(gè)補丁集是全自動(dòng)生成的，沒(méi)有任何人來(lái)確認其是否真正
健全。
2.6.x -mm補丁集
---------------
這是由Andrew Morton維護的試驗性?xún)群搜a丁集。Andrew將所有子系統的內核源碼
和補丁拼湊到一起，并且加入了大量從linux-kernel郵件列表中采集的補丁。這個(gè)
源碼樹(shù)是新功能和補丁的試煉場(chǎng)。當補丁在-mm補丁集里證明了其價(jià)值以后Andrew
或者相應子系統的維護者會(huì )將補丁發(fā)給Linus以便集成進(jìn)主內核源碼樹(shù)。
在將所有新補丁發(fā)給Linus以集成到主內核源碼樹(shù)之前，我們非常鼓勵先把這些補
丁放在-mm版內核源碼樹(shù)中進(jìn)行測試。
這些內核版本不適合在需要穩定運行的系統上運行，因為運行它們比運行任何其他
內核分支都更具有風(fēng)險。
如果你想為內核開(kāi)發(fā)進(jìn)程提供幫助，請嘗試并使用這些內核版本，并在
linux-kernel郵件列表中提供反饋，告訴大家你遇到了問(wèn)題還是一切正常。
通常-mm版補丁集不光包括這些額外的試驗性補丁，還包括發(fā)布時(shí)-git版主源碼樹(shù)
中的改動(dòng)。
-mm版內核沒(méi)有固定的發(fā)布周期，但是通常在每?jì)蓚€(gè)-rc版內核發(fā)布之間都會(huì )有若干
個(gè)-mm版內核發(fā)布（一般是1至3個(gè)）。
子系統相關(guān)內核源碼樹(shù)和補丁集
----------------------------
相當一部分內核子系統開(kāi)發(fā)者會(huì )公開(kāi)他們自己的開(kāi)發(fā)源碼樹(shù)，以便其他人能了解內
核的不同領(lǐng)域正在發(fā)生的事情。如上所述，這些源碼樹(shù)會(huì )被集成到-mm版本內核中。
下面是目前可用的一些內核源碼樹(shù)的列表：
通過(guò)git管理的源碼樹(shù)：
- Kbuild開(kāi)發(fā)源碼樹(shù)， Sam Ravnborg <sam@ravnborg.org>
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI開(kāi)發(fā)源碼樹(shù), Len Brown <len.brown@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- 塊設備開(kāi)發(fā)源碼樹(shù), Jens Axboe <axboe@suse.de>
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM開(kāi)發(fā)源碼樹(shù), Dave Airlie <airlied@linux.ie>
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64開(kāi)發(fā)源碼樹(shù), Tony Luck <tony.luck@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394開(kāi)發(fā)源碼樹(shù), Jody McIntyre <scjody@modernduck.com>
git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
- infiniband開(kāi)發(fā)源碼樹(shù), Roland Dreier <rolandd@cisco.com>
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata開(kāi)發(fā)源碼樹(shù), Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- 網(wǎng)絡(luò )驅動(dòng)程序開(kāi)發(fā)源碼樹(shù), Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia開(kāi)發(fā)源碼樹(shù), Dominik Brodowski <linux@dominikbrodowski.net>
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI開(kāi)發(fā)源碼樹(shù), James Bottomley <James.Bottomley@SteelEye.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
使用quilt管理的補丁集：
- USB, PCI, 驅動(dòng)程序核心和I2C, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64, 部分i386, Andi Kleen <ak@suse.de>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
其他內核源碼樹(shù)可以在http://git.kernel.org的列表中和MAINTAINERS文件里
找到。
報告bug
-------
bugzilla.kernel.org是Linux內核開(kāi)發(fā)者們用來(lái)跟蹤內核Bug的網(wǎng)站。我們鼓勵用
戶(hù)在這個(gè)工具中報告找到的所有bug。如何使用內核bugzilla的細節請訪(fǎng)問(wèn)：
http://test.kernel.org/bugzilla/faq.html
內核源碼主目錄中的REPORTING-BUGS文件里有一個(gè)很好的模板。它指導用戶(hù)如何報
告可能的內核bug以及需要提供哪些信息來(lái)幫助內核開(kāi)發(fā)者們找到問(wèn)題的根源。
利用bug報告
-----------
練習內核開(kāi)發(fā)技能的最好辦法就是修改其他人報告的bug。你不光可以幫助內核變
得更加穩定，還可以學(xué)會(huì )如何解決實(shí)際問(wèn)題從而提高自己的技能，并且讓其他開(kāi)發(fā)
者感受到你的存在。修改bug是贏(yíng)得其他開(kāi)發(fā)者贊譽(yù)的最好辦法，因為并不是很多
人都喜歡浪費時(shí)間去修改別人報告的bug。
要嘗試修改已知的bug，請訪(fǎng)問(wèn)http://bugzilla.kernel.org網(wǎng)址。如果你想獲得
最新bug的通知，可以訂閱bugme-new郵件列表（只有新的bug報告會(huì )被寄到這里）
或者訂閱bugme-janitor郵件列表（所有bugzilla的變動(dòng)都會(huì )被寄到這里）。
https://lists.linux-foundation.org/mailman/listinfo/bugme-new
https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
郵件列表
--------
正如上面的文檔所描述，大多數的骨干內核開(kāi)發(fā)者都加入了Linux Kernel郵件列
表。如何訂閱和退訂列表的細節可以在這里找到：
http://vger.kernel.org/vger-lists.html#linux-kernel
網(wǎng)上很多地方都有這個(gè)郵件列表的存檔(archive)?？梢允褂盟阉饕鎭?lái)找到這些
存檔。比如：
http://dir.gmane.org/gmane.linux.kernel
在發(fā)信之前，我們強烈建議你先在存檔中搜索你想要討論的問(wèn)題。很多已經(jīng)被詳細
討論過(guò)的問(wèn)題只在郵件列表的存檔中可以找到。
大多數內核子系統也有自己獨立的郵件列表來(lái)協(xié)調各自的開(kāi)發(fā)工作。從
MAINTAINERS文件中可以找到不同話(huà)題對應的郵件列表。
很多郵件列表架設在kernel.org服務(wù)器上。這些列表的信息可以在這里找到：
http://vger.kernel.org/vger-lists.html
在使用這些郵件列表時(shí)，請記住保持良好的行為習慣。下面的鏈接提供了與這些列
表（或任何其它郵件列表）交流的一些簡(jiǎn)單規則，雖然內容有點(diǎn)濫竽充數。
http://www.albion.com/netiquette/
當有很多人回復你的郵件時(shí)，郵件的抄送列表會(huì )變得很長(cháng)。請不要將任何人從抄送
列表中刪除，除非你有足夠的理由這么做。也不要只回復到郵件列表。請習慣于同
一封郵件接收兩次（一封來(lái)自發(fā)送者一封來(lái)自郵件列表），而不要試圖通過(guò)添加一
些奇特的郵件頭來(lái)解決這個(gè)問(wèn)題，人們不會(huì )喜歡的。
記住保留你所回復內容的上下文和源頭。在你回復郵件的頂部保留“某某某說(shuō)到……”
這幾行。將你的評論加在被引用的段落之間而不要放在郵件的頂部。
如果你在郵件中附帶補丁，請確認它們是可以直接閱讀的純文本（如
Documentation/SubmittingPatches文檔中所述）。內核開(kāi)發(fā)者們不希望遇到附件
或者被壓縮了的補丁。只有這樣才能保證他們可以直接評論你的每行代碼。請確保
你使用的郵件發(fā)送程序不會(huì )修改空格和制表符。一個(gè)防范性的測試方法是先將郵件
發(fā)送給自己，然后自己嘗試是否可以順利地打上收到的補丁。如果測試不成功，請
調整或者更換你的郵件發(fā)送程序直到它正確工作為止。
總而言之，請尊重其他的郵件列表訂閱者。
同內核社區合作
----------------
內核社區的目標就是提供盡善盡美的內核。所以當你提交補丁期望被接受進(jìn)內核的
時(shí)候，它的技術(shù)價(jià)值以及其他方面都將被評審。那么你可能會(huì )得到什么呢？
- 批評
- 評論
- 要求修改
- 要求證明修改的必要性
- 沉默
要記住，這些是把補丁放進(jìn)內核的正常情況。你必須學(xué)會(huì )聽(tīng)取對補丁的批評和評論，
從技術(shù)層面評估它們，然后要么重寫(xiě)你的補丁要么簡(jiǎn)明扼要地論證修改是不必要
的。如果你發(fā)的郵件沒(méi)有得到任何回應，請過(guò)幾天后再試一次，因為有時(shí)信件會(huì )湮
沒(méi)在茫茫信海中。
你不應該做的事情：
- 期望自己的補丁不受任何質(zhì)疑就直接被接受
- 翻臉
- 忽略別人的評論
- 沒(méi)有按照別人的要求做任何修改就重新提交
在一個(gè)努力追尋最好技術(shù)方案的社區里，對于一個(gè)補丁有多少好處總會(huì )有不同的見(jiàn)
解。你必須要抱著(zhù)合作的態(tài)度，愿意改變自己的觀(guān)點(diǎn)來(lái)適應內核的風(fēng)格?；蛘咧辽?/div>
愿意去證明你的想法是有價(jià)值的。記住，犯錯誤是允許的，只要你愿意朝著(zhù)正確的
方案去努力。
如果你的第一個(gè)補丁換來(lái)的是一堆修改建議，這是很正常的。這并不代表你的補丁
不會(huì )被接受，也不意味著(zhù)有人和你作對。你只需要改正所有提出的問(wèn)題然后重新發(fā)
送你的補丁。
內核社區和公司文化的差異
------------------------
內核社區的工作模式同大多數傳統公司開(kāi)發(fā)隊伍的工作模式并不相同。下面這些例
子，可以幫助你避免某些可能發(fā)生問(wèn)題：
用這些話(huà)介紹你的修改提案會(huì )有好處：
- 它同時(shí)解決了多個(gè)問(wèn)題
- 它刪除了2000行代碼
- 這是補丁，它已經(jīng)解釋了我想要說(shuō)明的
- 我在5種不同的體系結構上測試過(guò)它……
- 這是一系列小補丁用來(lái)……
- 這個(gè)修改提高了普通機器的性能……
應該避免如下的說(shuō)法：
- 我們在A(yíng)IX/ptx/Solaris就是這么做的，所以這么做肯定是好的……
- 我做這行已經(jīng)20年了，所以……
- 為了我們公司賺錢(qián)考慮必須這么做
- 這是我們的企業(yè)產(chǎn)品線(xiàn)所需要的
- 這里是描述我觀(guān)點(diǎn)的1000頁(yè)設計文檔
- 這是一個(gè)5000行的補丁用來(lái)……
- 我重寫(xiě)了現在亂七八糟的代碼，這就是……
- 我被規定了最后期限，所以這個(gè)補丁需要立刻被接受
另外一個(gè)內核社區與大部分傳統公司的軟件開(kāi)發(fā)隊伍不同的地方是無(wú)法面對面地交
流。使用電子郵件和IRC聊天工具做為主要溝通工具的一個(gè)好處是性別和種族歧視
將會(huì )更少。Linux內核的工作環(huán)境更能接受婦女和少數族群，因為每個(gè)人在別人眼
里只是一個(gè)郵件地址。國際化也幫助了公平的實(shí)現，因為你無(wú)法通過(guò)姓名來(lái)判斷人
的性別。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux內核上工作過(guò)
并表達過(guò)看法的女性對在linux上工作的經(jīng)歷都給出了正面的評價(jià)。
對于一些不習慣使用英語(yǔ)的人來(lái)說(shuō)，語(yǔ)言可能是一個(gè)引起問(wèn)題的障礙。在郵件列表
中要正確地表達想法必需良好地掌握語(yǔ)言，所以建議你在發(fā)送郵件之前最好檢查一
下英文寫(xiě)得是否正確。
拆分修改
--------
Linux內核社區并不喜歡一下接收大段的代碼。修改需要被恰當地介紹、討論并且
拆分成獨立的小段。這幾乎完全和公司中的習慣背道而馳。你的想法應該在開(kāi)發(fā)最
開(kāi)始的階段就讓大家知道，這樣你就可以及時(shí)獲得對你正在進(jìn)行的開(kāi)發(fā)的反饋。這
樣也會(huì )讓社區覺(jué)得你是在和他們協(xié)作，而不是僅僅把他們當作傾銷(xiāo)新功能的對象。
無(wú)論如何，你不要一次性地向郵件列表發(fā)送50封信，你的補丁序列應該永遠用不到
這么多。
將補丁拆開(kāi)的原因如下：
1) 小的補丁更有可能被接受，因為它們不需要太多的時(shí)間和精力去驗證其正確性。
一個(gè)5行的補丁，可能在維護者看了一眼以后就會(huì )被接受。而500行的補丁則
需要數個(gè)小時(shí)來(lái)審查其正確性（所需時(shí)間隨補丁大小增加大約呈指數級增長(cháng)）。
當出了問(wèn)題的時(shí)候，小的補丁也會(huì )讓調試變得非常容易。一個(gè)一個(gè)補丁地回溯
將會(huì )比仔細剖析一個(gè)被打上的大補?。ㄟ@個(gè)補丁破壞了其他東西）容易得多。
2）不光發(fā)送小的補丁很重要，在提交之前重新編排、化簡(jiǎn)（或者僅僅重新排列）
補丁也是很重要的。
這里有內核開(kāi)發(fā)者Al Viro打的一個(gè)比方：
“想象一個(gè)老師正在給學(xué)生批改數學(xué)作業(yè)。老師并不希望看到學(xué)生為了得
到正確解法所進(jìn)行的嘗試和產(chǎn)生的錯誤。他希望看到的是最干凈最優(yōu)雅的
解答。好學(xué)生了解這點(diǎn)，絕不會(huì )把最終解決之前的中間方案提交上去?！?/div>
內核開(kāi)發(fā)也是這樣。維護者和評審者不希望看到一個(gè)人在解決問(wèn)題時(shí)的思
考過(guò)程。他們只希望看到簡(jiǎn)單和優(yōu)雅的解決方案。
直接給出一流的解決方案，和社區一起協(xié)作討論尚未完成的工作，這兩者之間似乎
很難找到一個(gè)平衡點(diǎn)。所以最好盡早開(kāi)始收集有利于你進(jìn)行改進(jìn)的反饋；同時(shí)也要
保證修改分成很多小塊，這樣在整個(gè)項目都準備好被包含進(jìn)內核之前，其中的一部
分可能會(huì )先被接收。
必須了解這樣做是不可接受的：試圖將未完成的工作提交進(jìn)內核，然后再找時(shí)間修
復。
證明修改的必要性
----------------
除了將補丁拆成小塊，很重要的一點(diǎn)是讓Linux社區了解他們?yōu)槭裁葱枰@樣修改。
你必須證明新功能是有人需要的并且是有用的。
記錄修改
--------
當你發(fā)送補丁的時(shí)候，需要特別留意郵件正文的內容。因為這里的信息將會(huì )做為補
丁的修改記錄(ChangeLog)，會(huì )被一直保留以備大家查閱。它需要完全地描述補丁，
包括：
- 為什么需要這個(gè)修改
- 補丁的總體設計
- 實(shí)現細節
- 測試結果
想了解它具體應該看起來(lái)像什么，請查閱以下文檔中的“ChangeLog”章節：
“The Perfect Patch”
http://userweb.kernel.org/~akpm/stuff/tpp.txt
這些事情有時(shí)候做起來(lái)很難。要在任何方面都做到完美可能需要好幾年時(shí)間。這是
一個(gè)持續提高的過(guò)程，它需要大量的耐心和決心。只要不放棄，你一定可以做到。
很多人已經(jīng)做到了，而他們都曾經(jīng)和現在的你站在同樣的起點(diǎn)上。
---------------
感謝Paolo Ciarrocchi允許“開(kāi)發(fā)流程”部分基于他所寫(xiě)的文章
(http://www.kerneltravel.net/newbie/2.6-development_process)，感謝Randy
Dunlap和Gerrit Huizenga完善了應該說(shuō)和不該說(shuō)的列表。感謝Pat Mochel, Hanna
Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer,
Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian
Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael
Kerrisk和Alex Shepard的評審、建議和貢獻。沒(méi)有他們的幫助，這篇文檔是不可
能完成的。
英文版維護者： Greg Kroah-Hartman <greg@kroah.com>
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
