軟件有 bug。任何復雜系統都無法保證每個部分都能按計劃工作。Fedora Linux 是一個 非常 復雜的系統，包含幾千個包，這些包由全球無數個獨立的上游項目創建。每周還有數百個更新。因此，問題是不可避免的。本文介紹了 bug 修復過程以及如何確定 bug 優先級。

發布開發過程

作為一個 Linux 發行項目，我們希望為用戶提供完善的、一切正常的體驗。我們的發布起始于 “Rawhide”。我們在 Rawhide 中集成了所有更新的自由及開源軟件的新版本。我們一直在不斷改進正在進行的測試和持續集成Continuous Integration過程，為了讓即使是 Rawhide 也能被冒險者安全使用。可是，從本質來講，Rawhide 始終有點粗糙。

每年兩次，我們把這個粗糙的操作系統先后分支到測試版本、最終版本。當我們這么做時，我們齊心協力地尋找問題。我們在測試日Test Days檢查特定的區域和功能。制作“候選版本Candidate builds”，并根據我們的 發布驗證測試計劃 進行檢測。然后我們進入凍結狀態freeze state，只有批準的更改可以并入候選版本。這就把候選版本從持續的開發隔離開來，持續的開發不斷并入 Rawhide 中。所以，不會引入新的問題。

在發布過程中許多 bug 被粉碎去除，這些 bug 有大有小。當一切按計劃進行時，我們為所有用戶提供了按計劃發布的嶄新的 Fedora Linux 版本。（在過去幾年里，我們已經可靠地重復這一動作——感謝每一個為之努力工作的人！）如果確實有問題，我們可以將其標記為發布阻礙release blocker。這就意味著我們要等到修復后才能發布。發布阻礙通常代表重大問題，該表達一定會引發對 bug 的關注。

有時，我們遇到的一些問題是持續存在的。可能一些問題已經持續了一兩個版本，或者我們還沒有達成共識的解決方案。有些問題確實困擾著許多用戶，但個別問題并沒有達到阻礙發布的程度。我們可以將這些東西標記為阻礙blocker。但這會像錘子一樣砸下來。阻礙可能導致最終粉碎該 bug，但也可能導致破壞了周圍。如果進度落后，所有其它的 bug 修復、改進以及人們一直在努力的功能，都不能到達用戶手中。

按優先順序排列 bug 流程

所以，我們有另一種方法來解決煩人的 bug。按優先順序排列 bug 流程，與其他方式不同，可以標出導致大量用戶不滿意的問題。這里沒有錘子，更像是聚光燈。與發布阻礙不同，按優先順序排列 bug 流程沒有一套嚴格定義的標準。每個 bug 都是根據影響范圍和嚴重性來評估的。

一個由感興趣的貢獻者組成的團隊幫助策劃一個簡短列表，上面羅列著需要注意的問題。然后，我們的工作是將問題匹配到能夠解決它們的人。這有助于減輕發布過程中的壓力，因為它沒有給問題指定任何特定的截止時間。理想情況下，我們能在進入測試階段之前就發現并解決問題。我們盡量保持列表簡短，不會超過幾個，這樣才會真正有重點。這種做法有助于團隊和個人解決問題，因為他們知道我們尊重他們捉襟見肘的時間與精力。

通過這個過程，Fedora 解決了幾十個嚴重而惱人的問題，包括從鍵盤輸入故障到 SELinux 錯誤，再到數千兆字節大小的舊包更新會逐漸填滿你的磁盤。但是我們可以做得更多——我們實際上收到的提案沒有達到我們的處理能力上限。因此，如果你知道有什么事情導致了長期挫折或影響了很多人，至今沒有達成解決方案，請遵循 按優先順序排列 bug 流程，提交給我們。

你可以幫助我們

邀請所有 Fedora 貢獻者參與按優化順序排列 bug 的流程。評估會議每兩周在 IRC 上舉辦一次。歡迎任何人加入并幫助我們評估提名的 bug。會議時間和地點參見 日歷。Fedora 項目經理在會議開始的前一天將議程發送到 triage 和 devel 郵件列表。

歡迎報告 bug

當你發現 bug 時，無論大小，我們很感激你能報告 bug。在很多情況下，解決 bug 最好的方式是交給創建該軟件的項目。例如，假設渲染數據相機照片的 Darktable 攝影軟件出了問題，最好把它帶給 Darktable 攝影軟件的開發人員。再舉個例子，假設 GNOME 或 KDE 桌面環境或組成部分軟件出了問題，將這些問題交給這些項目中通常會得到最好的結果。

然而， 如果這是一個特定的 Fedora 問題，比如我們的軟件構建或配置或者它的集成方式的問題，請毫不猶豫地 向我們提交 bug。當你知道有一個問題是我們還沒有解決的，也要提交給我們。

我知道這很復雜……最好有一個一站式的地方來處理所有 bug。但是請記住，Fedora 打包者大部分是志愿者，他們負責獲取上游軟件并將其配置到我們系統中。他們并不總是對他們正在使用的軟件的代碼有深入研究的專家。有疑問的時候，你可以隨時提交一個 Fedora bug。Fedora 中負責相應軟件包的人可以通過他們與上游軟件項目的聯系提供幫助。

請記住，當你發現一個已通過診斷但尚未得到良好修復的 bug 時，當你看到影響很多人的問題時，或者當有一個長期存在的問題沒有得到關注時，請將其提名為高優先級 bug。我們會看以看能做些什么。

附言：標題中的著名圖片當然是來自哈佛大學馬克 2 號計算機的日志，這里曾是格蕾絲·赫柏少將工作的地方。但是與這個故事的普遍看法相背，這并不是 “bug” 一詞第一次用于表示系統問題——它在工程中已經很常見了，這就是為什么發現一個字面上的 “bug” 作為問題的原因是很有趣的。