157 lines
10 KiB
ReStructuredText
157 lines
10 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
||
|
||
.. include:: ../disclaimer-zh_TW.rst
|
||
|
||
:Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`
|
||
|
||
:Translator:
|
||
|
||
時奎亮 Alex Shi <alex.shi@linux.alibaba.com>
|
||
|
||
:校譯:
|
||
|
||
吳想成 Wu XiangCheng <bobwxc@email.cn>
|
||
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
|
||
|
||
.. _tw_development_followthrough:
|
||
|
||
跟進
|
||
====
|
||
|
||
此時，您已經遵循了到目前爲止給出的指導方針，並且，隨着您自己的工程技能的增加，
|
||
已經發布了一系列完美的補丁。即使是經驗豐富的內核開發人員也能犯的最大錯誤之一
|
||
是，認爲他們的工作現在已經完成了。事實上，發佈補丁意味着進入流程的下一個階段，
|
||
可能還需要做很多工作。
|
||
|
||
一個補丁在首次發佈時就非常出色、沒有改進的餘地，這是很罕見的。內核開發流程已
|
||
認識到這一事實，因此它非常注重對已發佈代碼的改進。作爲代碼的作者，您應該與
|
||
內核社區合作，以確保您的代碼符合內核的質量標準。如果不參與這個過程，很可能會
|
||
無法將補丁合併到主線中。
|
||
|
||
與審閱者合作
|
||
------------
|
||
|
||
任何意義上的補丁都會導致其他開發人員在審查代碼時發表大量評論。對於許多開發
|
||
人員來說，與審閱人員合作可能是內核開發過程中最令人生畏的部分。但是如果你
|
||
記住一些事情，生活會變得容易得多：
|
||
|
||
- 如果你已經很好地解釋了你的補丁，審閱人員會理解它的價值，以及爲什麼你會
|
||
費盡心思去寫它。但是這個並不能阻止他們提出一個基本的問題：在五年或十年後
|
||
維護含有此代碼的內核會怎麼樣？你可能被要求做出的許多改變——從編碼風格的
|
||
調整到大量的重寫——都來自於對Linux的理解，即從現在起十年後，Linux仍將
|
||
在開發中。
|
||
|
||
- 代碼審查是一項艱苦的工作，這是一項相對喫力不討好的工作；人們記得誰編寫了
|
||
內核代碼，但對於那些審查它的人來說，幾乎沒有什麼長久的名聲。因此，審閱
|
||
人員可能會變得暴躁，尤其是當他們看到同樣的錯誤被一遍又一遍地犯下時。如果
|
||
你得到了一個看起來憤怒、侮辱或完全冒犯你的評論，請抑制以同樣方式回應的衝動。
|
||
代碼審查是關於代碼的，而不是關於人的，代碼審閱人員不會親自攻擊您。
|
||
|
||
- 同樣，代碼審閱人員也不想以犧牲你僱主的利益爲代價來宣傳他們僱主的議程。
|
||
內核開發人員通常希望今後幾年能在內核上工作，但他們明白他們的僱主可能會改
|
||
變。他們真的，幾乎毫無例外地，致力於創造他們所能做到的最好的內核；他們並
|
||
沒有試圖給僱主的競爭對手造成不適。
|
||
|
||
所有這些歸根結底就是，當審閱者向您發送評論時，您需要注意他們正在進行的技術
|
||
評論。不要讓他們的表達方式或你自己的驕傲阻止此事。當你在一個補丁上得到評論
|
||
時，花點時間去理解評論人想說什麼。如果可能的話，請修復審閱者要求您修復的內
|
||
容。然後回覆審閱者：謝謝他們，並描述你將如何回答他們的問題。
|
||
|
||
請注意，您不必同意審閱者建議的每個更改。如果您認爲審閱者誤解了您的代碼，請
|
||
解釋到底發生了什麼。如果您對建議的更改有技術上的異議，請描述它並證明您對該
|
||
問題的解決方案是正確的。如果你的解釋有道理，審閱者會接受的。不過，如果你的
|
||
解釋證明缺乏說服力，尤其是當其他人開始同意審稿人的觀點時，請花些時間重新考慮
|
||
一下。你很容易對自己解決問題的方法視而不見，以至於你沒有意識到某些東西完全
|
||
是錯誤的，或者你甚至沒有解決正確的問題。
|
||
|
||
Andrew Morton建議，每一個不會導致代碼更改的審閱評論都應該產生一個額外的代碼
|
||
註釋；這可以幫助未來的審閱人員避免第一次出現的問題。
|
||
|
||
一個致命的錯誤是忽視評論，希望它們會消失。它們不會走的。如果您在沒有對之前
|
||
收到的評論做出響應的情況下重新發布代碼，那麼很可能會發現補丁毫無用處。
|
||
|
||
說到重新發布代碼：請記住，審閱者不會記住您上次發佈的代碼的所有細節。因此，
|
||
提醒審閱人員以前提出的問題以及您如何處理這些問題總是一個好主意；補丁變更
|
||
日誌是提供此類信息的好地方。審閱者不必搜索列表檔案來熟悉上次所說的內容；
|
||
如果您幫助他們直接開始，當他們重新查看您的代碼時，心情會更好。
|
||
|
||
如果你已經試着做正確的事情，但事情仍然沒有進展呢？大多數技術上的分歧都可以
|
||
通過討論來解決，但有時人們仍需要做出決定。如果你真的認爲這個決定對你不利，
|
||
你可以試着向有更高權力的人上訴。對於本文，更高權力的人是 Andrew Morton 。
|
||
Andrew 在內核開發社區中非常受尊敬；他經常爲似乎被絕望阻塞的事情清障。儘管
|
||
如此，不應輕易就直接找 Andrew ，也不應在所有其他替代方案都被嘗試之前找他。
|
||
當然，記住，他也可能不同意你的意見。
|
||
|
||
接下來會發生什麼
|
||
----------------
|
||
|
||
如果一個補丁被認爲適合添加到內核中，並且大多數審查問題得到解決，下一步通常
|
||
是進入子系統維護人員的樹中。工作方式因子系統而異；每個維護人員都有自己的
|
||
工作方式。特別是可能有不止一棵樹——也許一棵樹專門用於計劃下一個合併窗口的
|
||
補丁，另一棵樹用於長期工作。
|
||
|
||
對於應用到不屬於明顯子系統樹（例如內存管理修補程序）的區域的修補程序，默認樹
|
||
通常上溯到-mm。影響多個子系統的補丁也可以最終進入-mm樹。
|
||
|
||
包含在子系統樹中可以提高補丁的可見性。現在，使用該樹的其他開發人員將默認獲
|
||
得補丁。子系統樹通常也爲Linux提供支持，使其內容對整個開發社區可見。在這一點
|
||
上，您很可能會從一組新的審閱者那裏得到更多的評論；這些評論需要像上一輪那樣
|
||
得到回應。
|
||
|
||
在這時也會發生點什麼，這取決於你的補丁的性質，是否與其他人正在做的工作發生
|
||
衝突。在最壞的情況下，嚴重的補丁衝突可能會導致一些工作被擱置，以便剩餘的補丁
|
||
可以成形併合並。另一些時候，衝突解決將涉及到與其他開發人員合作，可能還會
|
||
在樹之間移動一些補丁，以確保所有的應用都是乾淨的。這項工作可能是一件痛苦的
|
||
事情，但也需慶幸現在的幸福：在linux-next樹出現之前，這些衝突通常只在合併窗口
|
||
中出現，必須迅速解決。現在可以在合併窗口打開之前的空閒時間解決這些問題。
|
||
|
||
有朝一日，如果一切順利，您將登錄並看到您的補丁已經合併到主線內核中。祝賀你！
|
||
然而，一旦慶祝完了（並且您已經將自己添加到維護人員文件中），就一定要記住
|
||
一個重要的小事實：工作仍然沒有完成。併入主線也帶來了它的挑戰。
|
||
|
||
首先，補丁的可見性再次提高。可能會有以前不知道這個補丁的開發者的新一輪評論。
|
||
忽略它們可能很有誘惑力，因爲您的代碼不再存在任何被合併的問題。但是，要抵制
|
||
這種誘惑，您仍然需要對有問題或建議的開發人員作出響應。
|
||
|
||
不過，更重要的是：將代碼包含在主線中會將代碼交給更多的一些測試人員。即使您
|
||
爲尚未可用的硬件提供了驅動程序，您也會驚訝於有多少人會將您的代碼構建到內核
|
||
中。當然，如果有測試人員，也可能會有錯誤報告。
|
||
|
||
最糟糕的錯誤報告是迴歸。如果你的補丁導致迴歸，你會發現多到讓你不舒服的眼睛盯
|
||
着你；迴歸需要儘快修復。如果您不願意或無法修復迴歸（其他人都不會爲您修復），
|
||
那麼在穩定期內，您的補丁幾乎肯定會被移除。除了否定您爲使補丁進入主線所做的
|
||
所有工作之外，如果由於未能修復迴歸而取消補丁，很可能會使將來的工作更難被合併。
|
||
|
||
在處理完任何迴歸之後，可能還有其他普通缺陷需要處理。穩定期是修復這些錯誤並
|
||
確保代碼在主線內核版本中的首次發佈儘可能可靠的最好機會。所以，請回應錯誤
|
||
報告，並儘可能解決問題。這就是穩定期的目的；一旦解決了舊補丁的任何問題，就
|
||
可以開始盡情創建新補丁。
|
||
|
||
別忘了，還有其他節點也可能會創建缺陷報告：下一個主線穩定版本，當著名的發行
|
||
商選擇包含您補丁的內核版本時等等。繼續響應這些報告是您工作的基本素養。但是
|
||
如果這不能提供足夠的動機，那麼也需要考慮：開發社區會記住那些在合併後對代碼
|
||
失去興趣的開發人員。下一次你發佈補丁時，他們會以你以後不會持續維護它爲前提
|
||
來評估它。
|
||
|
||
其他可能發生的事情
|
||
------------------
|
||
|
||
某天，當你打開你的郵件客戶端時，看到有人給你寄了一個代碼補丁。畢竟，這是
|
||
讓您的代碼公開存在的好處之一。如果您同意這個補丁，您可以將它轉發給子系統
|
||
維護人員（確保包含一個正確的From:行，這樣屬性是正確的，並添加一個您自己的
|
||
signoff ），或者回復一個 Acked-by: 讓原始發送者向上發送它。
|
||
|
||
如果您不同意補丁，請禮貌地回覆，解釋原因。如果可能的話，告訴作者需要做哪些
|
||
更改才能讓您接受補丁。合併代碼的編寫者和維護者所反對的補丁的確存在着一定的
|
||
阻力，但僅此而已。如果你被認爲不必要的阻礙了好的工作，那麼這些補丁最終會
|
||
繞過你並進入主線。在Linux內核中，沒有人對任何代碼擁有絕對的否決權。可能除
|
||
了Linus。
|
||
|
||
在非常罕見的情況下，您可能會看到完全不同的東西：另一個開發人員發佈了針對您
|
||
的問題的不同解決方案。在這時，兩個補丁之一可能不會被合併，“我的補丁首先
|
||
發佈”不被認爲是一個令人信服的技術論據。如果有別人的補丁取代了你的補丁而進
|
||
入了主線，那麼只有一種方法可以回應你：很高興你的問題解決了，請繼續工作吧。
|
||
以這種方式把某人的工作推到一邊可能導致傷心和氣餒，但是社區會記住你的反應，
|
||
即使很久以後他們已經忘記了誰的補丁真正被合併。
|
||
|