報告迴歸問題¶
“我們不造成迴歸問題”是 Linux 核心開發的第一條規則；Linux 創始人兼首席開發人員 Linus Torvalds 自己制定了這條規則，並確保它得到遵守。
本文件描述了該規則對使用者的意義，以及 Linux 核心的開發模式如何確保解決所有報告的迴歸問題；與核心開發人員相關的方面留給 處理迴歸問題。
重點內容（又名“TL;DR”）¶
如果某個 Linux 核心執行良好，但較新版本執行較差或根本無法執行，則這是一個迴歸問題。請注意，較新的核心必須使用類似的配置進行編譯；下面的詳細解釋更詳細地描述了這一點和其他細則。
按照 報告問題 中概述的方式報告您的問題，它已經涵蓋了迴歸問題的所有重要方面，並在下面重複以方便起見。其中兩點很重要：在您報告的主題中以“[REGRESSION]”開頭，並抄送或轉發到 迴歸問題郵件列表 (regressions@lists.linux.dev)。
可選但建議：在傳送或轉發您的報告時，透過指定迴歸何時開始，讓 Linux 核心迴歸跟蹤機器人“regzbot”跟蹤該問題，如下所示
#regzbot introduced: v5.13..v5.14-rc1
與使用者相關的 Linux 核心迴歸問題的全部細節¶
重要的基礎知識¶
什麼是“迴歸問題”，什麼是“無迴歸問題”規則？¶
如果某個應用程式或實際用例在某個 Linux 核心上執行良好，但在使用類似配置編譯的較新版本上執行較差或根本無法執行，則這是一個迴歸問題。“無迴歸問題”規則禁止這種情況發生；如果意外發生這種情況，導致問題的開發人員應迅速修復該問題。
因此，當 Linux 5.13 中的 WiFi 驅動程式執行良好時，但 5.14 根本無法執行，執行速度明顯較慢或出現異常行為時，這是一個迴歸問題。如果一個完美執行的應用程式突然在新核心版本中出現不穩定的行為，這也是一個迴歸問題；此類問題可能是由 procfs、sysfs 或 Linux 提供給使用者空間軟體的許多其他介面中的更改引起的。但請記住，如前所述：在本例中，5.14 需要使用與 5.13 類似的配置構建。這可以使用 make olddefconfig 來實現，如下面更詳細的解釋。
請注意本節第一句話中的“實際用例”：儘管有“無迴歸問題”規則，開發人員可以自由更改核心的任何方面，甚至可以更改 API 或 ABI 到使用者空間，只要沒有現有的應用程式或用例中斷。
另請注意，“無迴歸問題”規則僅涵蓋核心提供給使用者空間的介面。因此，它不適用於核心內部介面，如模組 API，某些外部開發的驅動程式使用該介面來掛接到核心。
我如何報告迴歸問題？¶
只需按照 報告問題 中概述的方式報告問題，它已經描述了要點。以下方面在那裡概述，對於迴歸問題尤其相關
在檢查是否存在要加入的現有報告時，還要搜尋 Linux 迴歸問題郵件列表的存檔 和 regzbot 的 Web 介面。
在您報告的主題中以“[REGRESSION]”開頭。
在您的報告中，清楚地提及上次執行良好的核心版本和第一個損壞的版本。理想情況下，嘗試使用二分法找到導致迴歸問題的確切更改，如下面更詳細的解釋。
請記住讓 Linux 迴歸問題郵件列表 (regressions@lists.linux.dev) 知道您的報告
如果您透過郵件報告迴歸問題，請抄送回歸問題列表。
如果您將回歸問題報告給某個錯誤跟蹤器，請透過郵件將提交的報告轉發到迴歸問題列表，同時抄送維護人員和相關子系統的郵件列表。
如果是穩定或長期系列中的迴歸問題（例如 v5.15.3..v5.15.5），請記住抄送 Linux 穩定郵件列表 (stable@vger.kernel.org)。
如果您成功執行了二分法，請將所有人在 CC 中新增到罪魁禍首的提交訊息中，這些提交訊息以“Signed-off-by:”開頭的行提及。
在抄送以將您的報告轉發到列表時，請考慮直接告訴上述 Linux 核心迴歸問題跟蹤機器人您的報告。為此，請在您的郵件中包含如下段落
#regzbot introduced: v5.13..v5.14-rc1
Regzbot 然後會將您的郵件視為在指定的版本範圍內引入的迴歸問題的報告。在上述情況下，Linux v5.13 仍然執行良好，Linux v5.14-rc1 是您遇到問題的第一個版本。如果您執行了二分法以查詢導致迴歸問題的提交，請指定罪魁禍首的提交 ID，而不是
#regzbot introduced: 1f2e3d4c5d
放置這樣的“regzbot 命令”符合您的利益，因為它將確保報告不會被忽略。如果您省略此操作，Linux 核心的迴歸問題跟蹤器將負責告訴 regzbot 您的迴歸問題，只要您將副本傳送到迴歸問題郵件列表。但迴歸問題跟蹤器只是一個人，有時需要休息，或者偶爾甚至可能享受遠離電腦的時間（聽起來可能很瘋狂）。因此，依靠此人會導致在迴歸問題在 跟蹤和未解決的 Linux 核心迴歸問題列表 和 regzbot 傳送的每週迴歸問題報告中被提及之前出現不必要的延遲。這些延遲可能導致 Linus Torvalds 在決定“繼續開發還是完成併發布最終版本？”時無法意識到重要的迴歸問題。
是否真的修復了所有迴歸問題？¶
幾乎所有迴歸問題都已修復，只要能夠可靠地識別導致迴歸問題的更改（“罪魁禍首提交”）。有些迴歸問題可以在沒有此更改的情況下修復，但通常需要此更改。
誰需要找到迴歸問題的根本原因？¶
受影響程式碼區域的開發人員應嘗試自行查詢罪魁禍首。但對於他們來說，這通常不可能以合理的努力來實現，因為很多問題只發生在開發人員無法觸及的特定環境中 - 例如，特定的硬體平臺、韌體、Linux 發行版、系統配置或應用程式。這就是為什麼最終通常由報告者來查詢罪魁禍首提交；有時使用者甚至可能需要在之後執行額外的測試，以查明確切的根本原因。開發人員應提供建議並在力所能及的範圍內合理地提供幫助，以使典型使用者相對容易且可以實現此過程。
我如何找到罪魁禍首？¶
執行二分法，如 報告問題 中粗略概述的那樣，以及 二分迴歸問題 中更詳細的描述。這聽起來可能需要大量工作，但在很多情況下，它可以相對快速地找到罪魁禍首。如果難以或耗時地可靠地重現問題，請考慮與其他受影響的使用者合作以共同縮小搜尋範圍。
在迴歸問題方面，我可以向誰尋求建議？¶
傳送郵件到迴歸問題郵件列表 (regressions@lists.linux.dev)，同時抄送 Linux 核心的迴歸問題跟蹤器 (regressions@leemhuis.info)；如果這個問題最好私下處理，請隨意省略列表。
關於迴歸問題的更多細節¶
“無迴歸問題”規則的目標是什麼？¶
使用者在更新核心版本時應感到安全，而不必擔心某些東西可能會中斷。這符合核心開發人員的利益，可以使更新具有吸引力：他們不希望使用者停留在已放棄或已超過一年半的穩定或長期 Linux 系列上。這符合每個人的利益，因為 這些系列可能存在已知的錯誤、安全問題或其他問題方面，這些問題已在更高版本中修復。此外，核心開發人員希望使使用者能夠簡單而有吸引力地測試最新的預釋出或常規版本。這也符合每個人的利益，因為如果在問題引入後不久就報告問題，則更容易跟蹤和修復問題。
“無迴歸問題”規則在實踐中是否真的被遵守？¶
它被非常認真地對待，從 Linux 建立者兼首席開發人員 Linus Torvalds 的許多郵件列表帖子中可以看出，其中一些帖子在 處理迴歸問題 中引用。
該規則的例外情況非常罕見；在過去，當開發人員認為某種情況需要例外情況時，他們幾乎總是被證明是錯誤的。
誰確保“無迴歸問題”規則實際得到遵循？¶
子系統維護人員應負責處理，樹維護人員會對其進行監視和支援 - 例如，Linus Torvalds 用於主線，Greg Kroah-Hartman 等人用於各種穩定/長期系列。
所有人都得到了一些人的幫助，他們試圖確保沒有迴歸問題報告被忽略。其中一人是 Thorsten Leemhuis，他目前擔任 Linux 核心的“迴歸問題跟蹤器”；為了方便這項工作，他依賴於 regzbot，即 Linux 核心迴歸問題跟蹤機器人。這就是為什麼您要透過抄送或將每個報告轉發到迴歸問題郵件列表，最好在您的郵件中使用“regzbot 命令”以立即對其進行跟蹤，從而將您的報告引起這些人的注意。
迴歸問題通常多久修復一次？¶
開發人員應儘快修復任何報告的迴歸問題，以便及時為受影響的使用者提供解決方案，並防止更多使用者遇到該問題；但是，開發人員需要花費足夠的時間和精力來確保迴歸問題修復不會造成額外的損害。
因此，答案取決於各種因素，例如迴歸問題的影響、年齡或發生迴歸問題的 Linux 系列。但最終，大多數迴歸問題應在兩週內修復。
如果可以透過更新某些軟體來避免該問題，這是一個迴歸問題嗎？¶
幾乎總是：是的。如果開發人員告訴您其他情況，請按照上述方式向迴歸問題跟蹤器尋求建議。
如果較新的核心執行速度較慢或消耗更多能量，這是一個迴歸問題嗎？¶
是的，但差異必須是顯著的。因此，微基準測試中 5% 的速度下降不太可能被視為迴歸問題，除非它也使廣泛基準測試的結果受到超過 1% 的影響。如果有疑問，請尋求建議。
如果在更新 Linux 時外部核心模組中斷，這是一個迴歸問題嗎？¶
不是，因為“無迴歸問題”規則是關於 Linux 核心提供給使用者空間的介面和服務。因此，它不涵蓋構建或執行外部開發的核心模組，因為它們在核心空間中執行並使用偶爾更改的內部介面掛接到核心。
由安全修復引起的迴歸問題如何處理？¶
在極少數情況下，如果不造成迴歸問題，則無法修復安全問題；這些修復會採取措施，因為它們最終是兩害相權取其輕。幸運的是，幾乎總是可以避免這種中間情況，因為受影響區域的關鍵開發人員，通常甚至是 Linus Torvalds 本人，都會盡力修復安全問題，而不會造成迴歸問題。
如果您仍然遇到這種情況，請檢查郵件列表存檔，看看人們是否盡力避免迴歸問題。如果不是，請報告；如果有疑問，請按照上述方式尋求建議。
如果修復迴歸問題不可能而不造成另一個迴歸問題，會發生什麼？¶
遺憾的是，這些事情會發生，但幸運的是，發生的頻率不高；如果發生這些事情，受影響程式碼區域的專家開發人員應調查該問題，以找到避免迴歸問題或至少避免其影響的修復方法。如果您遇到這種情況，請執行已為安全修復引起的迴歸問題概述的操作：檢查早期討論，看看人們是否已經盡力而為，如果有疑問，請尋求建議。
在此快速說明：如果人們定期對每個開發週期的主線預釋出版本（例如 v5.15-rc1 或 -rc3）進行測試執行，則可以避免這些情況。最好透過想象 Linux v5.14 和 v5.15-rc1 之間整合的更改來解釋這一點，該更改導致迴歸問題，但同時是應用於 5.15-rc1 的某些其他改進的硬性要求。如果在 5.15 釋出之前有人發現並報告了所有這些更改，則通常可以簡單地恢復這些更改，從而解決了迴歸問題。幾天或幾周後，此解決方案可能變得不可能，因為某些軟體可能已經開始依賴於後續更改之一引入的方面：恢復所有更改將導致所述軟體的使用者出現迴歸問題，因此不可能這樣做。
如果我所依賴的某些功能在幾個月前被刪除，這是一個迴歸問題嗎？¶
是的，但由於上一節中概述的方面，通常很難修復此類迴歸問題。因此，需要根據具體情況進行處理。這是為什麼每個人都應定期測試主線預釋出版本的另一個原因。
如果我似乎是唯一受影響的人，“無迴歸問題”規則是否適用？¶
是的，但僅適用於實際用途：Linux 開發人員希望可以自由刪除僅在閣樓和博物館中找到的硬體支援。
請注意，有時無法避免迴歸問題以取得進展 - 並且需要後者以防止 Linux 停滯不前。因此，如果只有極少數使用者似乎受到迴歸問題的影響，為了更大的利益，讓他們透過並符合他們和其他每個人的利益。特別是如果有一種簡單的方法可以以某種方式規避迴歸問題，例如透過更新某些軟體或使用專門為此目的建立的核心引數。
迴歸問題規則是否也適用於暫存樹中的程式碼？¶
根據 涵蓋所有暫存程式碼的配置選項的幫助文字，自早期以來就宣告
Please note that these drivers are under heavy development, may or
may not work, and may contain userspace interfaces that most likely
will be changed in the near future.
暫存開發人員仍然經常遵守“無迴歸問題”規則，但有時會彎曲該規則以取得進展。例如，這就是為什麼當暫存樹中的 WiFi 驅動程式被從頭開始編寫的完全不同的驅動程式替換時，某些使用者不得不處理（通常可以忽略不計）迴歸問題。
為什麼稍後版本必須“使用類似的配置編譯”？¶
因為 Linux 核心開發人員有時會整合已知會導致迴歸問題的更改，但使它們成為可選的，並在核心的預設配置中停用它們。這種技巧允許取得進展，因為“無迴歸問題”規則否則會導致停滯。
例如，考慮一種新的安全功能，該功能阻止訪問某些經常被惡意軟體濫用的核心介面，但同時需要這些接口才能執行一些很少使用的應用程式。概述的方法使雙方都滿意：使用這些應用程式的人可以關閉新的安全功能，而其他所有人都可以啟用它而不會遇到麻煩。
如何建立與舊核心類似的配置？¶
使用已知的良好核心啟動您的機器，並使用 make olddefconfig 配置較新的 Linux 版本。這使核心的構建指令碼從正在執行的核心中選取配置檔案（“.config”檔案）作為您將要編譯的新核心的基礎；之後，它們將所有新配置選項設定為其預設值，這應停用可能導致迴歸問題的新功能。
我可以報告使用預編譯的 vanilla 核心發現的迴歸問題嗎？¶
您需要確保較新的核心是使用與舊核心類似的配置檔案編譯的（請參閱上文），因為構建這些核心的人可能為較新的核心啟用了某些已知不相容的功能。如果有疑問，請將此事報告給核心提供商並尋求建議。
有關使用“regzbot”進行迴歸問題跟蹤的更多資訊¶
什麼是迴歸問題跟蹤，為什麼我應該關心它？¶
像“無迴歸問題”這樣的規則需要有人確保它們得到遵循，否則它們會被意外或故意破壞。歷史表明，對於 Linux 核心開發也是如此。這就是為什麼 Linux 核心的迴歸問題跟蹤器 Thorsten Leemhuis 和一些人試圖確保所有迴歸問題都得到修復，方法是密切關注這些問題，直到它們得到解決。他們都沒有為此付費，因此這項工作是在盡最大努力的基礎上完成的。
為什麼以及如何使用機器人跟蹤 Linux 核心迴歸問題？¶
由於 Linux 核心開發過程的分散式和鬆散結構性質，完全手動地跟蹤迴歸問題已被證明非常困難。這就是為什麼 Linux 核心的迴歸問題跟蹤器開發了 regzbot 以方便工作，其長期目標是儘可能地為所有相關人員自動化迴歸問題跟蹤。
Regzbot 透過監視對跟蹤的迴歸問題報告的回覆來工作。此外，它還在查詢釋出的或提交的補丁，這些補丁透過“Link:”標記引用此類報告；也會跟蹤對此類補丁釋出的回覆。結合起來，這些資料可以很好地瞭解修復過程的當前狀態。
如何檢視 regzbot 當前跟蹤哪些迴歸問題？¶
檢視 regzbot 的 Web 介面。
哪些型別的問題應該由 regzbot 跟蹤？¶
該機器人旨在跟蹤迴歸問題，因此請不要讓 regzbot 參與常規問題。但是，如果您讓 regzbot 跟蹤嚴重問題，例如關於掛起、資料損壞或內部錯誤（Panic、Oops、BUG()、警告等）的報告，則對於 Linux 核心的迴歸問題跟蹤器來說是可以的。
如何更改跟蹤的迴歸問題的方面？¶
透過在直接或間接回復包含報告的郵件時使用“regzbot 命令”。最簡單的方法：在您的“已傳送”資料夾或郵件列表存檔中找到報告，然後使用您的郵件程式的“全部回覆”功能回覆它。在該郵件中，在獨立的段落中使用以下命令之一（IOW：使用空行將這些命令中的一個或多個與郵件文字的其餘部分分開）。
更新迴歸問題何時開始發生，例如在執行二分法之後
#regzbot introduced: 1f2e3d4c5d設定或更新標題
#regzbot title: foo監視討論或 bugzilla.kernel.org 工單，其中討論了該問題或修復的其他方面：
#regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789指向包含感興趣的更多細節的地方，例如郵件列表帖子或錯誤跟蹤器中的工單，它們與該問題略有相關，但關於不同的主題
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789將回歸問題標記為無效
#regzbot invalid: wasn't a regression, problem has always existed
Regzbot 支援一些主要由開發人員或跟蹤迴歸問題的人員使用的其他命令。可以在 入門指南 和 regzbot 的參考文件 中找到它們以及有關上述 regzbot 命令的更多詳細資訊。