(Difference between revisions)
|
|
| Line 31: |
Line 31: |
| | | | |
| | == Sys-Debug Query List == | | == Sys-Debug Query List == |
| - | * [https://bugzilla.otcshare.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Triage_pool&sharer_id=36 Query] on https://bugzilla.otcshare.org
| |
| | * [https://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Triage_pool&sharer_id=36 Query] on https://bugs.meego.com | | * [https://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Triage_pool&sharer_id=36 Query] on https://bugs.meego.com |
Revision as of 14:39, 6 May 2011
Bug triage could decide the bug owner if it is obviously a component specific bug. However, if the issue is a system level one, probably cross components, then it is difficult for triage team to assign a proper owner. Thus there are many bugs in MeeGo bugzilla that are aging without much care. To avoid the growing lonely bugs and improve the whole quality of MeeGo, we now start system debug.
Sys-Debug Definition
Sys-debug is a supplement to the bug triage, to make the bugs queued in the right assignee’s list. Sys-debug is to check which component or which part of the component causes the issue and thus assign to the right owner. It would be nice if the exact root cause (e.g. API, code line) is also found and a solution/patch be suggested.
- Difference between bug triage and sys-debug
- Bug triage focus on the completeness of new bugs and roughly put it to the bug component owner while sys-debug focuses on bug isolation/initial debug and then fasten bug fixing. Sys-debug combines bug report and bug fixing more tightly.
- Bug triage cares about new bugs reported recently, while sys-debug covers open bugs that need to be further analyzed, especially aging system level bugs.
- There are also domain bug scrub for key/complex components(e.g. Connection Management, Ofono). It is similar to triage but have two major differences:
- Domain bug scrub aims at aging bugs
- Domain bug scrub is more technical driven and requires for cross-team sync up (UX QA, Core QA, distro, sometimes developers), sometimes make decision on the solution.
Sys-Debug Process
- Propose bug candidates for sys-debug with criterion “fail to assign to a specific component/owner even bug report is completed”
- Propose candidates by adding keyword “need-sysdebug” for bugs that needs further analysis to decide the owner.
- Often bug triage team proposes this when doing initial triaging.
- The keyword could also be added to any bug by anyone, once he/she thinks the bug needs it.
- All bugs with keyword “need-sysdebug” are reviewed and then sys-debug starts.
- By adding comment on the very bug about the analysis result, sys-debug status and discussion are shared on bugzilla.
- In addition to dedicated engineers, anyone in MeeGo community is welcomed to help on bug analysis. Any findings may be helpful for final bug fixing.
- Sys-debug exists with criterion “can assign to a specific component/owner with sufficient supporting data”
- By changing keyword from “need-sysdebug” to “finish-sysdebug”, it indicates someone has finished the debug with sufficient information to indicate the actual component/owner.
- The bug can be re-assigned to a specific bug component/owner. The one who debugs it can take credits by typing his/her account on “Triaged by” field.
- Anyone who spent hours/days to collect more debug info and have helped to narrow down the root-cause should take the credit, even though the bug may be eventually fixed by someone else.
- Though it looks a new process, it actually does NOT introduce any changes from developers’ point of view. The keywords and new field are transparent to component developers. With more debug info, the bug ownership ping-pong thing is expected to happen less.
System Debug Process Flow as follows:
Sys-Debug Query List