Bug的類型
Bug Squad上的bug類型主要分為底下幾個：
詳細的解釋如下。
Apport reports
Apport report是使用軟體Apport自動回報bug的機制，通常用這種方式會比較好，因為它會自動的收集工程師需要的所有相關資訊。通常使用Apport的話，額外的資訊不會太多，所以整個流程會比較順暢，並且有需要的話可以透過加入系統資訊在套件的『description』欄位，這樣你就可以很清楚的辨識這些bugs。而有些程式會在Apport裡面有相關的『hooks』，這樣當回報bug時，這些『hooks』就會被呼叫然後增加一些額外的資訊。
Apport crash reports
由Apport所回報的多數相關 crash bug，會經過在Canonical的資料中心的半自動的機器人預先處理。這些機器人會試著產生一份堆疊追蹤符號(symbolic stack trace)，並且檢查是否已經有存在其他相關的bug (duplicates)。
在早期的Ubuntu版本-『Feisty』和『Gusty』早期，crash bug 都是屬於『public』的，所以每個人都可以看到。其中『core dump』和『stack trace』有可能會產生一些敏感資訊(sensitive data)會涉及一些隱私的問題，而且也會產生一堆很煩人的mail，並且隨著自動重複bug的檢查，也會產生許多的不相關的資訊。
但是自從『Gusty』後，這類的問題就慢慢的被減輕了，因為後來bug被發起時都會隨著一個『private』的flag，只有發起者(reporters)和訂閱者(subscribers)可以看到。
處理『crash bugs』會跟其他的bug不一樣，主要有兩個部份：1.必須檢查『sensitive data』，2.除非這個bug變成public，不然將不會發信(initial bug mail)。並且在分類bug時須注意一下底下的幾項：
如果這份『crash report』有包含『CoreDump.gz』的話，則就無法自動的取得堆疊追蹤符號(symbolic stack trace)也無法檢查是否有重複的bug(duplicates)。在這種狀況之下，這個bug將會被分類(tag)成『apport-failed-retrace』。如果堆疊追蹤符號看起來沒什麼問題的話，則附件的CoreDump.gz連結就必須要被移除。如果『retrace』完全的失敗了，則將這個bug標記成『Invalid』，然後請reporter重新複製並且重新發起這個bug report。最重要的一點是，千萬不要將一個包含『Coredump.gz』的bug標記成『public』。
如果附件沒有『retraced』的文件 - 『Stacktrace.txt』，則大部分都是因為附件『CoreDump.gz』已經損壞了。這部份請聯繫Martin Pitt(pitti in IRC, [email protected])，他會檢查log看為什麼損壞。
檢查在stacktrace附件是否有敏感資訊，像是最初的stacktraces, Stacktrace.txt (retraced) 和 ThreadStacktrace.txt (retraced)等等，舉例來說，密碼，像是銀行帳號，CSS Keys，使用者名稱，server名稱之類的都不能有，如果完全找不到類似的資訊的話，則可以將這個bug標記成『public』，但是如果你要將這個bug保持『private』也是可以，並沒有限制。
除了上面這幾項隱私權相關的問題的話，crash report應該要被當成正常的bug一樣處理，一樣的重複bug搜尋與標記，轉給upstream等等。
Confirmed bugs
當一個bug被標記成『Confirmed』，不代表它已經被分類結束，但是已經快了，你必須確保它已經準備好被工程師修復。通常滿足底下幾個條件才能被考慮成分類結束：
- 這個but report是否真的有描述一個bug?
- 這個report是否真的包含了足夠的訊息。
- 如果這個bug根本就不重要可以不用修復，是否要被標注為『hundredpapercuts』?
- 如果這個bug是其他地方在管理的，是否要回報給『upstream』?
- 這個bug的資訊是否真的可以讓工程師開始debug了?
只有在上面的條件都滿足，你才可以將這個bug的狀態改為『Triaged』，由底下的步驟來轉狀態：
- 將欄位『Status』轉為『Triaged』。
- 如果還沒結束，可以設定其優先權。
- 按『Save changes』。
為了將bug的狀態設定成『Triaged』，你必須成為『Ubuntu Bug Control』的成員。如果你不是成員，但是你又發現了一個bug你相信已經可以被標記成『Triaged』了，那下一步就是加入在irc.freenode.net上的『#ubuntu-bugs channel』，並且在上面提供這個report的連結，然後上面的成員就會幫你檢查，如果可以的話它就會幫你轉狀態了。
Feature requests
如果你的bug report是一個『feature request』，則有兩種可能:
一種是request的強度沒那麼強且已經清楚的定義規格了，第二種是這個建議牽涉到upstream的project，則這個bug的重要性應該要被設定成『Wishlist』。
跟其他的狀態一樣，當處理好這個report以後要記得將其設定成『Triaged』，而就像剛才說的，只有『Ubuntu Bug Control』的成員才能轉狀態，所以如果你不是成員的話你必須請其他成員幫忙，將『bug number』給貼在『#ubuntu-bugs』上，並且說你覺的這個bug應該被設定成『Wishlist』。
如果這個『feature request』牽涉到upstream的話，就必須轉發到『upstream』，這部份會在晚一點的『Actions』章節講解。
然而，如果這個bug太抽象了又或者是這個建議要改動的地方太大或太多了，這個bug就應該以『Invalid』來關掉，而且也要發布給這個reporter，請它將這個bug給轉發給upstream或是相關的論壇(forum)上。
如果有需要的話可以使用底下的罐頭訊息：
| Thank you for taking the time to make Ubuntu better. Since what you submitted is not really a bug, or a problem, but rather an idea to improve Ubuntu, you are invited discuss the idea with other Ubuntu community members in the many public forums. Public discussion of ideas improves the likelihood of adoption. Thanks for taking the time to share your opinion! | |
Regressions
| regression-release | 『regression』有可能發生在一個新的stable release或者是開發版的release，這有可能在一個套件裡面的bug或是修改預設的軟體時所造成的功能失常。 |
| regression-update | 在stable release時更新套件所造成的『regression』。 |
| regression-proposed | 在套件『proposed』時所造成的『regression』。 |
| regression-retracer | 在『retracer』時發現有個bug是跟之前關掉的某個bug很相似。 |
一旦被標記成『Regression』，則這些bugs就會出現在『regression tracking page』上面，並且會被通知給研發團隊，有需要的話可以參考一下『QATeam/RegressionTracking』。
Untriaged bugs
『Untriaged』是沒有被任何『triager』動過的bugs。有好幾種方式來找到這些『Untriaged』的bugs。最主要的方式通常是使用『Launchpad』上面的搜尋功能，你也可以使用『Advanced search』來尋找某個套件的新bug如下：
所有『untriaged』的bug都可以經由這個連結找到-『untriaged bugs』，但是當一個bug的狀態已經不是『New』時，就不會出現在這個頁面上了。
如果你想要在有新的bug出現時接受到通知的話，你可以經由：
- 將Launchpad Atom feed for new Ubuntu bugs加到你的『feed aggregator』上。
- 加入在『irc.freenode.net』上的#ubuntu-bugs-announce InternetRelayChat channel。
- 訂閱mail list - 『https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs』。
上面使用mail list的方式要小心，不然有可能很快就把你的信箱給灌爆，我之前訂閱kernel channel就一天收到幾百封的郵件，真得很恐怖。
這部份一開始，請先直接選取一個最近的bug，並且開在你最常用的瀏覽器上，盡量挑一個跟你最有相關的bug，這樣會讓你比較有興趣，還有讓你比較知道要如何去複製這個bug，如果沒有人在這條bug上評論的話，那這條bug就屬於你的了。
特殊類型的bugs
大部分的bugs通常都是程式碼或是打包套件時的錯誤，但是Ubuntu裡面的有些團隊會故意用一些bugs 來作為其他的用途，像是收集數據之類的，所以要小心不要打斷其他團隊的處理工作。
這種類型的bugs有特別的規則和不同的狀態含意，甚至有可能在Ubuntu上不同的release cycle上也有不同的含意。除非你真的很清楚，也很熟悉這類型bug的流程，不然這類型的bugs就不要動，不然會很麻煩。
Developer Process Bugs
通常不應該去動到這個bug的類型，除非你正與相關工程師或是packager一起合作，他們知道這件事。這類型的bugs的標題通常會像是如下：
- Please merge < package> from Debian unstable (main)
- Please sync < package> from Debian unstable (main)
- Please remove < package> from the Ubuntu archives
- Please promote < package> to < component>
- Please demote < package> to < component>
- Main inclusion report (MIR)
而這類型的bugs通常會有底下的幾個團隊訂閱：
- Ubuntu Sponsors
- Ubuntu Package Archive Administrators
- MOTU Release Team
- Ubuntu Release Team
- MIR approval team
對於在Universe/Multiverse上的套件，這部份請參考『Sponsors Queue』。
needs-packaging bugs
一個『needs-packaging』bug是一個上面描述過的『Developer Process bugs』bug的子集合，通常這種類型的bugs都不是真的bug，是一個要求Ubuntu新增這個套件的請求。這類型的bug標題通常都會有[needs-packaging] < package>，又或者是會有一個新的套件需要被創建的描述，對於這類型的bug，請讀取并遵守在『SponsorQueue』上的指示：概要如下：
- 檢查是否已經在Ubuntu裡面了(查一下http://packages.ubuntu.com ，又或者是執行rmadison來檢查)，如果已經存在了，那就將其標記『Invalid』，並且記得留下評論解釋一下為什麼。
- 如果沒有在Ubuntu裡面的話，請檢查Debian的系統(http://packages.debian.org 或是執行rmadison -u 檢查)，如果已經存在了，那就將其標記『Invalid』，並且可以參考一下底下的訊息來留下評論：
| Packages for this software appear to exist in Debian already. Ubuntu has semi-automatic tools to sync new packages from Debian so it will most likely appear in the next Ubuntu release. | |
- 檢查『the Debian bug tracker』或是『Work-Needing and Prospective Packages』來檢查這個套件的ITP (Intent To Package) 或是 RFP (Request For Package)。如果你有找到這樣子的request的話，請為其加入一個『upstream bug watch』，然後繼續下一步。
- 檢查upstream的licenses。如果已經包含了license的資訊和upstream的URL，則在評論的地方加入『license types』和這個upstream的URL。如果沒有找到相關的資訊的話，就要請reporter加入相關的連結。
- 最後，將這個bug標記成『Triaged』，並且加入tag - 『needs-packaging』。
除了上面的步驟以外，也要注意一下底下的四點：
- 並不是所有的套件名稱都會很直觀，所以必要的話可以使用套件的描述來幫助你。
- 永遠不要將bug的狀態設定成『Confirmed』，除非你是和套件的維護者一起合作，而且是他告訴你這麼做的。
- 這條bug狀態必須保持在『New』或是『Incomplete』，直到所有的先決條件都完成了。
- 如果你不確定你正在處理的bug是否屬於這個分類的話，這時候請問在irc.freenode.net上的『#ubuntu-bugs』，『#ubuntu-motu』。
Security bugs
Ubuntu的『SecurityTeam』團隊使用類似但是又不全然相同的方式來分類bugs，所以如果你覺的這個bug是屬於security的issue或是要將這個bug的flag設定成security issue的話，請記得處理前先讀『SecurityTeam/BugTriage』一下。
Translation bugs and Launchpad integration
Ubuntu的『Translations』團隊使用的Launchpad是專門用來追蹤翻譯bug的，跟主要的Launchpad是分開的。所有在主要的Launchpad上的翻譯問題和『ubuntu-translations』之間都需要有一個task來整合，如果一個翻譯的bug沒有這個task的話，請由底下三個步驟加入：
- 點選連結『Also affects project』。
- 如果project name不是『Ubuntu Translations』，點選在project name後面括弧內的連結『Choose another project』。
- 在project name那邊輸入『ubuntu-translations』，並且按『Continue』。
如果這條bug是一個翻譯的error，則『ubuntu-translations』task將會將這個bug給分派給translation team。
如果想要更加的了解『Translations』團隊的話，這個頁面『Translations/KnowledgeBase/HandlingBugs』裡面有更多的bug規範資訊。
藉由開啟『ubuntu-translations』task來讓翻譯團隊的成員知道他們有bug要處理，而且當你將主要的『ubuntu Launchpad』歸類為『Triaged』時，他們就會知道已經可以開工了。