6. 後續工作¶
至此，您已經遵循了到目前為止給出的指導方針，並憑藉您自身的工程技能，釋出了一系列完美的補丁。即使是經驗豐富的核心開發者也可能犯的最大錯誤之一是認為他們的工作已經完成。事實上，釋出補丁標誌著進入流程的下一個階段，可能還有相當多的工作要做。
很少有補丁在首次釋出時就已盡善盡美，沒有改進空間。核心開發流程認識到這一事實，因此，它高度重視對已釋出程式碼的改進。作為程式碼的作者，您將被期望與核心社群合作，以確保您的程式碼符合核心的質量標準。未能參與此過程很可能會阻礙您的補丁被納入主線。
6.1. 與審閱者合作¶
任何有重要性的補丁都會在其他開發者審閱程式碼時引出許多評論。對於許多開發者來說，與審閱者合作可能是核心開發流程中最令人生畏的部分。然而，如果您記住一些事情，事情就會變得容易得多。
如果您很好地解釋了您的補丁，審閱者將理解其價值以及您為什麼費心編寫它。但這種價值不會阻止他們提出一個根本性問題：五年或十年後，維護一個包含此程式碼的核心會是怎樣的？您可能被要求進行的許多更改——從編碼風格調整到實質性重寫——都源於這樣一種理解，即十年後 Linux 仍將存在並處於開發中。
程式碼審閱是一項艱苦的工作，而且是一項相對吃力不討好的職業；人們會記住誰編寫了核心程式碼，但對那些審閱程式碼的人來說，卻鮮有持久的聲譽。因此，審閱者可能會變得暴躁，尤其是當他們看到同樣的錯誤一再出現時。如果您收到的審閱看起來憤怒、侮辱性或完全冒犯，請抵制以牙還牙的衝動。程式碼審閱是關於程式碼，而不是關於人，程式碼審閱者並非在人身攻擊您。
同樣，程式碼審閱者並非試圖以犧牲您的利益為代價來推行其僱主的議程。核心開發者通常期望在未來幾年內繼續致力於核心開發，但他們明白他們的僱主可能會改變。他們幾乎無一例外地真正致力於建立他們所能做到的最佳核心；他們不是為了給其僱主的競爭對手製造麻煩。
請為看似愚蠢的編碼風格更改請求以及將您部分程式碼提取到核心共享部分的請求做好準備。維護者的一項工作是保持事物的一致性。有時這意味著您驅動程式中解決問題的巧妙技巧實際上需要成為一個通用的核心功能，為下次使用做好準備。
所有這一切歸結為，當審閱者給您傳送評論時，您需要注意他們提出的技術觀察結果。不要讓他們的表達方式或您自己的自尊心阻礙這一點。當您收到補丁的審閱評論時，請花時間理解審閱者試圖表達的內容。如果可能，請修復審閱者要求您修復的問題。並回複審閱者：感謝他們，並說明您將如何回答他們的問題。
請注意，您不必同意審閱者建議的每一項更改。如果您認為審閱者誤解了您的程式碼，請解釋實際情況。如果您對建議的更改有技術異議，請說明並論證您解決問題的方案。如果您的解釋合理，審閱者會接受。然而，如果您的解釋未能說服他人，特別是當其他人開始同意審閱者時，請花些時間重新考慮。您可能很容易被自己的解決方案矇蔽，以至於沒有意識到某些地方根本性地錯了，或者，您甚至沒有解決正確的問題。
Andrew Morton 建議，每一條未導致程式碼更改的審閱評論都應改為新增一條額外的程式碼評論；這可以幫助未來的審閱者避免首次出現的問題。
一個致命的錯誤是忽視審閱評論，希望能讓它們自行消失。它們不會消失。如果您在沒有回應上次收到的評論的情況下重新發布程式碼，您很可能會發現您的補丁無法被接受。
說到重新發布程式碼：請記住，審閱者不會記住您上次釋出程式碼的所有細節。因此，提醒審閱者之前提出的問題以及您如何處理它們，總是一個好主意；補丁更改日誌是放置此類資訊的好地方。審閱者不應該透過搜尋郵件列表存檔來了解上次說了什麼；如果您幫助他們快速開始，他們在重新審閱您的程式碼時心情會更好。
如果您已經盡力做到了一切，但事情仍然毫無進展怎麼辦？大多數技術分歧可以透過討論解決，但有時就是有人必須做出決定。如果您真誠地認為這個決定對您不利是錯誤的，您總可以嘗試向更高的權力求助。截至本文撰寫之時，這種更高的權力通常是 Andrew Morton。Andrew 在核心開發社群中備受尊敬；他經常能解決看似無望的僵局。然而，向 Andrew 申訴不應輕率行事，並且必須在探索所有其他替代方案之後。當然，請記住，他也可能不同意您的觀點。
6.2. 接下來會發生什麼¶
如果一個補丁被認為是應該新增到核心的好東西，並且大多數審閱問題都已解決，那麼下一步通常是進入子系統維護者的樹中。其運作方式因子系統而異；每個維護者都有自己的行事方式。特別是，可能會有不止一個樹——一個可能專用於計劃在下一個合併視窗提交的補丁，另一個用於長期工作。
對於適用於沒有明顯子系統樹的區域（例如記憶體管理補丁）的補丁，預設樹通常最終是 -mm。影響多個子系統的補丁也可能最終透過 -mm 樹。
被納入子系統樹可以提高補丁的可見性。現在，使用該樹的其他開發者將預設獲得此補丁。子系統樹通常也會向 linux-next 提供內容，使其內容對整個開發社群可見。此時，您很有可能會收到來自一組新審閱者的更多評論；這些評論需要像上一輪一樣得到回覆。
此時，根據您的補丁性質，還可能出現與他人正在進行的工作發生衝突的情況。在最壞的情況下，嚴重的補丁衝突可能導致部分工作被擱置，以便剩餘補丁能夠被整理併合並。其他時候，衝突解決將涉及與其他開發者合作，並可能在不同樹之間移動一些補丁，以確保所有內容都能幹淨地應用。這項工作可能很痛苦，但請心存感激：在 linux-next 樹出現之前，這些衝突通常只在合併視窗期間出現，並且必須倉促解決。現在，它們可以在合併視窗開啟之前，從容地得到解決。
有一天，如果一切順利，您登入時會看到您的補丁已被合併到主線核心中。恭喜！然而，慶祝結束後（並且您已將自己新增到 MAINTAINERS 檔案中），值得記住一個重要的小事實：工作仍然沒有完成。合併到主線帶來了它自己的挑戰。
首先，您的補丁的可見性再次提高。可能會有來自之前不瞭解該補丁的開發者的新一輪評論。您可能會想忽略它們，因為您的程式碼是否會被合併已不再是問題。然而，請抵制這種誘惑；您仍然需要回應那些有問題或建議的開發者。
然而，更重要的是：納入主線會將您的程式碼交到更大一群測試人員手中。即使您貢獻了一個尚未可用硬體的驅動程式，您也會驚訝於有多少人會將您的程式碼構建到他們的核心中。當然，有測試人員的地方，就會有錯誤報告。
最糟糕的錯誤報告是迴歸錯誤（regressions）。如果您的補丁導致迴歸，您會發現有大量目光不適地落在您身上；迴歸錯誤需要儘快修復。如果您不願意或無法修復迴歸（且沒有人為您修復），您的補丁幾乎肯定會在穩定期被移除。除了否定您為將補丁納入主線所做的一切工作之外，因未能修復迴歸而導致補丁被撤回很可能會使您未來更難將工作合併。
處理完所有迴歸錯誤後，可能還有其他普通錯誤需要處理。穩定期是您修復這些錯誤並確保您的程式碼在主線核心釋出中儘可能穩固的最佳機會。因此，請回應錯誤報告，並儘可能修復問題。這就是穩定期的目的；一旦舊補丁的任何問題都已處理完畢，您就可以開始建立很棒的新補丁了。
並且不要忘記還有其他可能產生錯誤報告的里程碑：下一個主線穩定版釋出、知名發行商採用包含您的補丁的核心版本等。繼續回應這些報告是您工作中的基本自豪感問題。然而，如果這不足以成為動力，那麼也值得考慮的是，開發社群會記住那些在程式碼合併後對程式碼失去興趣的開發者。下次您釋出補丁時，他們會假設您之後不會繼續維護它來評估您的補丁。
6.3. 其他可能發生的情況¶
有一天，您可能會開啟您的郵件客戶端，看到有人給您的程式碼傳送了一個補丁。畢竟，這也是您的程式碼開源的一個優勢。如果您同意該補丁，您可以將其轉發給子系統維護者（請務必包含正確的 From: 行以確保歸屬正確，並新增您自己的簽署），或者傳送一個 Acked-by: 回覆並讓原始提交者向上傳送。
如果您不同意該補丁，請傳送禮貌的回覆說明原因。如果可能，請告訴作者需要進行哪些更改才能讓您接受該補丁。對於作者和程式碼維護者反對合並的補丁，存在一定的阻力，但這阻力並非絕對。如果您被認為是無故阻礙好的工作，那些補丁最終會繞過您並進入主線。在 Linux 核心中，沒有人對任何程式碼擁有絕對的否決權。也許除了 Linus。
在極少數情況下，您可能會看到完全不同的情況：另一位開發者釋出了您問題的不同解決方案。此時，很可能這兩個補丁中只有一個會被合併，而“我的補丁先在這裡”並不被認為是令人信服的技術論點。如果別人的補丁取代了您的並進入了主線，實際上只有一種回應方式：為您的問題得到解決而高興，然後繼續您的工作。以這種方式被擱置工作可能會令人受傷和沮喪，但社群會記住您的反應，遠比他們記住哪個補丁最終被合併更長久。