From 9f0fc191371843c4fc000a226b0a26b6c059aacd Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 18 May 2024 19:40:19 +0200 Subject: Merging upstream version 6.7.7. Signed-off-by: Daniel Baumann --- .../translations/zh_TW/process/6.Followthrough.rst | 46 +++++++++++----------- 1 file changed, 23 insertions(+), 23 deletions(-) (limited to 'Documentation/translations/zh_TW/process/6.Followthrough.rst') diff --git a/Documentation/translations/zh_TW/process/6.Followthrough.rst b/Documentation/translations/zh_TW/process/6.Followthrough.rst index 5073b6e77..bcc885ae1 100644 --- a/Documentation/translations/zh_TW/process/6.Followthrough.rst +++ b/Documentation/translations/zh_TW/process/6.Followthrough.rst @@ -18,13 +18,13 @@ 跟進 ==== -此時，您已經遵循了到目前爲止給出的指導方針，並且，隨著您自己的工程技能的增加， +此時，您已經遵循了到目前爲止給出的指導方針，並且，隨着您自己的工程技能的增加， 已經發布了一系列完美的補丁。即使是經驗豐富的內核開發人員也能犯的最大錯誤之一 -是，認爲他們的工作現在已經完成了。事實上，發布補丁意味著進入流程的下一個階段， +是，認爲他們的工作現在已經完成了。事實上，發佈補丁意味着進入流程的下一個階段， 可能還需要做很多工作。 -一個補丁在首次發布時就非常出色、沒有改進的餘地，這是很罕見的。內核開發流程已 -認識到這一事實，因此它非常注重對已發布代碼的改進。作爲代碼的作者，您應該與 +一個補丁在首次發佈時就非常出色、沒有改進的餘地，這是很罕見的。內核開發流程已 +認識到這一事實，因此它非常注重對已發佈代碼的改進。作爲代碼的作者，您應該與 內核社區合作，以確保您的代碼符合內核的質量標準。如果不參與這個過程，很可能會 無法將補丁合併到主線中。 @@ -41,7 +41,7 @@ 調整到大量的重寫——都來自於對Linux的理解，即從現在起十年後，Linux仍將 在開發中。 - - 代碼審查是一項艱苦的工作，這是一項相對吃力不討好的工作；人們記得誰編寫了 + - 代碼審查是一項艱苦的工作，這是一項相對喫力不討好的工作；人們記得誰編寫了 內核代碼，但對於那些審查它的人來說，幾乎沒有什麼長久的名聲。因此，審閱 人員可能會變得暴躁，尤其是當他們看到同樣的錯誤被一遍又一遍地犯下時。如果 你得到了一個看起來憤怒、侮辱或完全冒犯你的評論，請抑制以同樣方式回應的衝動。 @@ -54,7 +54,7 @@ 所有這些歸根結底就是，當審閱者向您發送評論時，您需要注意他們正在進行的技術 評論。不要讓他們的表達方式或你自己的驕傲阻止此事。當你在一個補丁上得到評論 -時，花點時間去理解評論人想說什麼。如果可能的話，請修覆審閱者要求您修復的內 +時，花點時間去理解評論人想說什麼。如果可能的話，請修復審閱者要求您修復的內 容。然後回覆審閱者：謝謝他們，並描述你將如何回答他們的問題。 請注意，您不必同意審閱者建議的每個更改。如果您認爲審閱者誤解了您的代碼，請 @@ -65,19 +65,19 @@ 是錯誤的，或者你甚至沒有解決正確的問題。 Andrew Morton建議，每一個不會導致代碼更改的審閱評論都應該產生一個額外的代碼 -注釋；這可以幫助未來的審閱人員避免第一次出現的問題。 +註釋；這可以幫助未來的審閱人員避免第一次出現的問題。 一個致命的錯誤是忽視評論，希望它們會消失。它們不會走的。如果您在沒有對之前 收到的評論做出響應的情況下重新發布代碼，那麼很可能會發現補丁毫無用處。 -說到重新發布代碼：請記住，審閱者不會記住您上次發布的代碼的所有細節。因此， +說到重新發布代碼：請記住，審閱者不會記住您上次發佈的代碼的所有細節。因此， 提醒審閱人員以前提出的問題以及您如何處理這些問題總是一個好主意；補丁變更 日誌是提供此類信息的好地方。審閱者不必搜索列表檔案來熟悉上次所說的內容； 如果您幫助他們直接開始，當他們重新查看您的代碼時，心情會更好。 -如果你已經試著做正確的事情，但事情仍然沒有進展呢？大多數技術上的分歧都可以 +如果你已經試着做正確的事情，但事情仍然沒有進展呢？大多數技術上的分歧都可以 通過討論來解決，但有時人們仍需要做出決定。如果你真的認爲這個決定對你不利， -你可以試著向有更高權力的人上訴。對於本文，更高權力的人是 Andrew Morton 。 +你可以試着向有更高權力的人上訴。對於本文，更高權力的人是 Andrew Morton 。 Andrew 在內核開發社區中非常受尊敬；他經常爲似乎被絕望阻塞的事情清障。儘管 如此，不應輕易就直接找 Andrew ，也不應在所有其他替代方案都被嘗試之前找他。 當然，記住，他也可能不同意你的意見。 @@ -95,7 +95,7 @@ Andrew 在內核開發社區中非常受尊敬；他經常爲似乎被絕望阻 包含在子系統樹中可以提高補丁的可見性。現在，使用該樹的其他開發人員將默認獲 得補丁。子系統樹通常也爲Linux提供支持，使其內容對整個開發社區可見。在這一點 -上，您很可能會從一組新的審閱者那裡得到更多的評論；這些評論需要像上一輪那樣 +上，您很可能會從一組新的審閱者那裏得到更多的評論；這些評論需要像上一輪那樣 得到回應。 在這時也會發生點什麼，這取決於你的補丁的性質，是否與其他人正在做的工作發生 @@ -114,23 +114,23 @@ Andrew 在內核開發社區中非常受尊敬；他經常爲似乎被絕望阻 這種誘惑，您仍然需要對有問題或建議的開發人員作出響應。 不過，更重要的是：將代碼包含在主線中會將代碼交給更多的一些測試人員。即使您 -爲尚未可用的硬體提供了驅動程序，您也會驚訝於有多少人會將您的代碼構建到內核 +爲尚未可用的硬件提供了驅動程序，您也會驚訝於有多少人會將您的代碼構建到內核 中。當然，如果有測試人員，也可能會有錯誤報告。 -最糟糕的錯誤報告是回歸。如果你的補丁導致回歸，你會發現多到讓你不舒服的眼睛盯 -著你；回歸需要儘快修復。如果您不願意或無法修復回歸（其他人都不會爲您修復）， +最糟糕的錯誤報告是迴歸。如果你的補丁導致迴歸，你會發現多到讓你不舒服的眼睛盯 +着你；迴歸需要儘快修復。如果您不願意或無法修復迴歸（其他人都不會爲您修復）， 那麼在穩定期內，您的補丁幾乎肯定會被移除。除了否定您爲使補丁進入主線所做的 -所有工作之外，如果由於未能修復回歸而取消補丁，很可能會使將來的工作更難被合併。 +所有工作之外，如果由於未能修復迴歸而取消補丁，很可能會使將來的工作更難被合併。 -在處理完任何回歸之後，可能還有其他普通缺陷需要處理。穩定期是修復這些錯誤並 -確保代碼在主線內核版本中的首次發布儘可能可靠的最好機會。所以，請回應錯誤 +在處理完任何迴歸之後，可能還有其他普通缺陷需要處理。穩定期是修復這些錯誤並 +確保代碼在主線內核版本中的首次發佈儘可能可靠的最好機會。所以，請回應錯誤 報告，並儘可能解決問題。這就是穩定期的目的；一旦解決了舊補丁的任何問題，就 可以開始盡情創建新補丁。 別忘了，還有其他節點也可能會創建缺陷報告：下一個主線穩定版本，當著名的發行 商選擇包含您補丁的內核版本時等等。繼續響應這些報告是您工作的基本素養。但是 如果這不能提供足夠的動機，那麼也需要考慮：開發社區會記住那些在合併後對代碼 -失去興趣的開發人員。下一次你發布補丁時，他們會以你以後不會持續維護它爲前提 +失去興趣的開發人員。下一次你發佈補丁時，他們會以你以後不會持續維護它爲前提 來評估它。 其他可能發生的事情 @@ -141,15 +141,15 @@ Andrew 在內核開發社區中非常受尊敬；他經常爲似乎被絕望阻 維護人員（確保包含一個正確的From:行，這樣屬性是正確的，並添加一個您自己的 signoff ），或者回復一個 Acked-by: 讓原始發送者向上發送它。 -如果您不同意補丁，請禮貌地回復，解釋原因。如果可能的話，告訴作者需要做哪些 -更改才能讓您接受補丁。合併代碼的編寫者和維護者所反對的補丁的確存在著一定的 +如果您不同意補丁，請禮貌地回覆，解釋原因。如果可能的話，告訴作者需要做哪些 +更改才能讓您接受補丁。合併代碼的編寫者和維護者所反對的補丁的確存在着一定的 阻力，但僅此而已。如果你被認爲不必要的阻礙了好的工作，那麼這些補丁最終會 繞過你並進入主線。在Linux內核中，沒有人對任何代碼擁有絕對的否決權。可能除 了Linus。 -在非常罕見的情況下，您可能會看到完全不同的東西：另一個開發人員發布了針對您 -的問題的不同解決方案。在這時，兩個補丁之一可能不會被合併，「我的補丁首先 -發布」不被認爲是一個令人信服的技術論據。如果有別人的補丁取代了你的補丁而進 +在非常罕見的情況下，您可能會看到完全不同的東西：另一個開發人員發佈了針對您 +的問題的不同解決方案。在這時，兩個補丁之一可能不會被合併，“我的補丁首先 +發佈”不被認爲是一個令人信服的技術論據。如果有別人的補丁取代了你的補丁而進 入了主線，那麼只有一種方法可以回應你：很高興你的問題解決了，請繼續工作吧。 以這種方式把某人的工作推到一邊可能導致傷心和氣餒，但是社區會記住你的反應， 即使很久以後他們已經忘記了誰的補丁真正被合併。 -- cgit v1.2.3