|
Size: 2783
Comment:
|
← Revision 9 as of 2017-12-30 07:19:29 ⇥
Size: 2432
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| What are the benefits of merging code upstream? | '''合併至上游程式碼有什麼好處?''' |
| Line 5: | Line 5: |
| Merging your source code upstream takes effort, dedication and time. The process is not easy, because the moment Linus accepts code into his tree, he runs the risk of having to maintain that code for the rest of his life. If bad quality code got accepted, maintaining the Linux kernel would become much more difficult. These reasons and more mean that the threshold for getting source code accepted into the Linux kernel is relatively high. | 合併你的原始碼至上游要花費精力,貢獻和時間. 過程並不容易, 因為Linus接受程式碼進入他的版本時, 他冒著這一輩子得維護該程式碼的風險. 如果品質差的程式碼被接受, 維護Linux核心會變得非常睏難. 這些理由還有更多意指讓程式碼收入Linux核心門坎相對的提高. |
| Line 7: | Line 7: |
| However, there are also a number of benefits to having your source code accepted into the kernel. | 然而, 讓你的程式碼收入核心也有許多的好處. |
| Line 9: | Line 9: |
| Maintainability | '''可維護性''' |
| Line 11: | Line 11: |
| Keeping up with the changes in the upstream kernel can be a challenge, wasting days or weeks of developer time every time the upstream kernel changes. Code that lives in the upstream kernel does not have this issue, since kernel developers tend to simply grep the sources and fix up any driver that is impacted by a proposed API change. This frees up your developers for more important work. | 追上上游核心變更是艱巨任務, 每次上游核心一變更要花費開發者數天或是好幾個禮拜的時間. 存在上游的程式碼沒有這樣的議題存在, 因為核心開發人員頃向簡化查找原始碼和修補受到預定發佈API變更影響的驅動程式. 這樣一來讓空出你的開發人員作更重要的工作. |
| Line 13: | Line 13: |
| Ubiquity | '''普遍存在''' |
| Line 15: | Line 15: |
| Your source code will be present in every Linux distribution. This matters if you would like to sell your hardware to every Linux user. No more need to lobby distributions to include your patches (hard), you can just ask them to switch on a config option (easy). | 你的原始碼將被出現在每一個Linux發行版本裡. 這關係著如果你想販賣你的硬體給每個Linux使用者. 不再需要遊說讓你的修補程式成為發行版本的一部份(困難), 你可以只要求他們切換設定選項(容易). |
| Line 17: | Line 17: |
| Quality control | '''品質控制''' |
| Line 19: | Line 19: |
| Some of the world's best developers will be going over your source code with a fine comb. This may be embarrassing for a few days or weeks, but in the end the code tends to work better and be more easily maintained. In some cases the upstream developers have made network and storage drivers 30% faster, making the hardware more attractive to customers. | 世界上某些最好的開發者將隨著你的原始碼作良好整理, 這可能會有幾天或數個禮拜的尷尬時期, 但是最後程式碼往往運作更好且更容易維護. 在某些案例上遊開發者讓網路和儲存驅動程式增加30%速度, 使得應體更吸引顧客. |
| Line 21: | Line 21: |
| How to merge code upstream | '''如何讓程式碼和上游合併''' |
| Line 23: | Line 23: |
| Merging code into the upstream kernel can be a daunting process to the uninitiated. However, with the right strategy in mind, you won't get lost on your way to upstream acceptance. | 合並程式碼到上游核心對沒有經驗的人可能是讓人怯步的過程. 然而, 靠著正確的方式, 你將不會失去讓上游接受的方向. |
| Line 25: | Line 25: |
| * | |
| Line 27: | Line 26: |
| /MergingStrategy strategies for merging code upstream. * |
* /MergingStrategy 合併程式碼到上游的策略. * /WhatNotToDo 如果你想要和上游合併什麼是你不應該作. * /GettingFlamed 歐 不! 核心開發者批評我, 我的程式碼還有我的貓! 現在我該怎麼辦? |
| Line 30: | Line 30: |
| /WhatNotToDo what you should never do if you want to merge upstream. * |
核心樹有用的文件: |
| Line 33: | Line 32: |
| /GettingFlamed Oh no! The kernel developers said bad things about me, my code and my cat! What do I do now? | * /SubmittingDrivers 如何提交設備驅動程式給linux核心. * /SubmittingPatches 如何提交修補程式給linux核心. * /SubmitChecklist 提交程式碼給上游的清單. |
| Line 35: | Line 36: |
| Helpful documents from the kernel tree: | 讓修補程式至上游的其他文件: |
| Line 37: | Line 38: |
| * /SubmittingDrivers how to submit device drivers to the linux kernel. * /SubmittingPatches how to submit patches to the linux kernel. * /SubmitChecklist a checklist for submitting code upstream. Other documents on getting patches upstream: * The Perfect Patch * http://linux.yyz.us/patch-format.html * The Linux Driver Project |
* The Perfect Patch * http://linux.yyz.us/patch-format.html * The Linux Driver Project |
Kernelnewbies網站的這個部份本意是如何讓程式碼併入上層核心的手冊, 由Linus Torvalds維護和可以從kernel.org取得的的核心樹.
合併至上游程式碼有什麼好處?
合併你的原始碼至上游要花費精力,貢獻和時間. 過程並不容易, 因為Linus接受程式碼進入他的版本時, 他冒著這一輩子得維護該程式碼的風險. 如果品質差的程式碼被接受, 維護Linux核心會變得非常睏難. 這些理由還有更多意指讓程式碼收入Linux核心門坎相對的提高.
然而, 讓你的程式碼收入核心也有許多的好處.
可維護性
追上上游核心變更是艱巨任務, 每次上游核心一變更要花費開發者數天或是好幾個禮拜的時間. 存在上游的程式碼沒有這樣的議題存在, 因為核心開發人員頃向簡化查找原始碼和修補受到預定發佈API變更影響的驅動程式. 這樣一來讓空出你的開發人員作更重要的工作.
普遍存在
你的原始碼將被出現在每一個Linux發行版本裡. 這關係著如果你想販賣你的硬體給每個Linux使用者. 不再需要遊說讓你的修補程式成為發行版本的一部份(困難), 你可以只要求他們切換設定選項(容易).
品質控制
世界上某些最好的開發者將隨著你的原始碼作良好整理, 這可能會有幾天或數個禮拜的尷尬時期, 但是最後程式碼往往運作更好且更容易維護. 在某些案例上遊開發者讓網路和儲存驅動程式增加30%速度, 使得應體更吸引顧客.
如何讓程式碼和上游合併
合並程式碼到上游核心對沒有經驗的人可能是讓人怯步的過程. 然而, 靠著正確的方式, 你將不會失去讓上游接受的方向.
/MergingStrategy 合併程式碼到上游的策略.
/WhatNotToDo 如果你想要和上游合併什麼是你不應該作.
/GettingFlamed 歐 不! 核心開發者批評我, 我的程式碼還有我的貓! 現在我該怎麼辦?
核心樹有用的文件:
/SubmittingDrivers 如何提交設備驅動程式給linux核心.
/SubmittingPatches 如何提交修補程式給linux核心.
/SubmitChecklist 提交程式碼給上游的清單.
讓修補程式至上游的其他文件:
- The Perfect Patch
- The Linux Driver Project