Bug的狀態

一個report的status代表的是被回報的bug目前的該發處理狀態，這個狀態可以經由在頁面的最上方，按一下目前的狀態來改變。底下列出了所有的status，還有其含意，還有何時使用：

New:

• Reports剛剛被送出來。
• 通常會缺少資訊。
• 應該全部是『untriaged』。

Incomplete:

• 如果你有需要問reporter任何問題的話，記得將report設定為『Incomplete』。
• 當你有要求reporter在提供任何必須的資訊時，請確定你有訂閱『subscribe』這個report，這樣這個report有任何更新時，你的e-mail才能接到相關的更新。
• 只要任何人有評論的話，通常都會重新設定60天倒數的expiration clock。
• 更多的訊息請參考『https://wiki.ubuntu.com/Bugs/Responses 』。

Opinion:

• 代表的是report和其他人之間不同意見的討論，通常他們可以繼續討論，但是這個report必須被考慮要轉成『closed』，因為這樣project或是package的維護者才能不會浪費太多時間在這邊，可以去做其他的事情，而這個討論可以持續的繼續。
• 這個狀態可以被當成是一個實驗，並且被密切的監測。

Invalid:

• 這個狀態代表這個report已經被『close』了，並不會被更進一步的分類還有工程師也不會去管他了。
• 這個狀態應該被使用在:
  • 這個report並沒有包含適當的資訊來決定它是否是個bug，即使它已經被reporter解決掉了。
  • 這個report根本不是bug，有可能是因為reporter自己缺少相關知識而誤報的。
• 用這個狀態要小心，因為當被設定成這個狀態後，就不會顯示在預設搜尋上。
• 再三確認這個report是否真的是屬於『invalid』。

只有一個『valid』和清楚描述的bug才能讓工程師有效率的處理，所以有需要的話你可以參考一下『Bugs/Improving』來幫助你更加有效率得來分類處理這些bug。

Expired

• 這個狀態相似於『Invalid』，但是更具體的含意是這個bug處於『Incomplete』太久了。
• 這個狀態只能被使用launchpadlib或是email介面來設定。
• 就像是『Invalid』一樣，只要被設定成這個狀態後，就搜尋不到。

Confirmed:

這個狀態分成兩個部份：

• 除了Ubuntu以外的套件：
  • 其他的reporter也有經歷過相同的issue，所以這個bug進來的時候的形式有可能是複製(duplicate)的report或是一則評論。
  • 想要confirm這個report需要其他不是這個reporter的第三方確認過，這樣可以確保並不是硬體的問題還是缺少一些相關知識的誤判。
  • 正常來說，請不要confirm你自己所屬的bus，除非這個套件的研發團隊有特別聲明說你可以這樣做。
• Ubuntu only：
  • 『Confirmed』代表原始的reporter已經有附上充足的資訊可以分類。
  • 或是上次有缺少資訊，但是經過你要求後，reporter已經附上充足的資訊了。

Triaged:

• 代表至少一個『Ubuntu Bug Control』團隊的成員相信這個report已經有充足的資訊，而工程師已經可以開始修復這個bug了。
• 轉這個狀態之前請在三確保這個report已經有充足的資訊可以讓工程師開始動工了。
• 如果不是一個需求的話，一個report的Ubuntu task status必須在任何upstream 轉發之前將其分類。
  • 如果有任何的report是關於『Linux』的，也就是不是只屬於Ubuntu的，這個狀態意思是原始的reporter已經在最新的upstream mainline kernel上測試過了。
• 對於 process reports(eg. FFes 和 syncs)，『Triaged』這個狀態代表的是這個action已經被相關的開發者所允許了。

In Progress:

• 你必須將report指派(assinged)給你自己，而且要馬上發送一個patch來定位這個report。這個狀態不適用於『simply debugging』的case(像是bisecting，測試一個由其他人所提供的patch，一個work around等等)。
• 千萬不要將一個report給assign給其他人。
• 如果有個『assignee』已經超過6個月而且沒有修復也沒有反應的話，則必須要『unassign』它並且回朔其狀態。

Fix Committed:

分成兩個狀況：

• Ubuntu task:這個changes已經被『pending』，並且即將被上傳。
  • 當一個更新的套件已經在『proposed repository』上時，也會使用這個『Fix Committed』。
  • 當一個patch被attached到report上時。沒使用『Fix Committed』。
• Upstream task:已經在bzr/CVS/git/SVN上修復，或者是已經被commit 到其他地方了。

Fix Released:

分為兩種狀況：

• Ubuntu task:已經在最新的Ubuntu release修復了，而且是一個standard upgrade。
  • 如果這個bug依然影響一個舊的Ubuntu release，則請在相關的地方『nominate』這個bug(我不確定是什麼意思，是在開一條report嗎？還是需要支會誰？)，這樣其他人才會知道在那個版本沒有被修復。
  • 這個狀態指示個偏好，並不是必須的，代表的只是這個套件的哪個版本在何時被release。
• Upstream task:在一個tarbell裡面有相關修復。

Won't Fix:

• 這個狀態就是有時候當修復(fix)太有爭議的話。
• 最常的狀況是就是這個report在特定的版本不會被修復，但是在晚一點的版本才會被修復。
• 有可能現在工程師不想要實做，所以會放到『feature requests』上。

底下這幾種狀況的改變被限制只有『Bug Control』團隊的成員或者是套件的維護者才能改變：

• 改變成『Triaged』或是『Won't Fix』。
• 從『Won't Fix』改變成其他狀態。
• 將target改成其他特殊的Ubuntu release。

底下整理一下處理每個task所需要的資格：