Defects Dashboard
Rationale:
This is a revival of https:/
We have lots of sources of information about our packages and bugs, and issues potentially unreported (with whoopsie-daisy). We need to consolidate this information and make it available in a palatable way, so we can worry about what to do to fix and avoid bugs, instead of worrying about how to figure out where to look to check for issues.
Goal:
Have a centralized place to do a health check of Ubuntu. We want, in a glance, to be able to know packages that have spikes in bugs, bugs that should be fixed but aren't getting the proper attention, problems that are happening but no bugs were reported yet, and the like.
Blueprint information
- Status:
- Not started
- Approver:
- Kate Stewart
- Priority:
- High
- Drafter:
- Ursula Junque
- Direction:
- Approved
- Assignee:
- Ursula Junque
- Definition:
- Approved
- Series goal:
- Accepted for quantal
- Implementation:
-
Deferred
- Milestone target:
-
ubuntu-12.10
- Started by
- Completed by
Whiteboard
UDS discussion points:
What kinds of information would be useful?
- Packages "trending": that had reported more bugs
* http://
- Packages receiving new bugs including information about the importance
- The 20? hottest bugs across all the packages (bug heat?)
- Finding bug reports that have been reopened (date_left_closed exists on a
bug task)
- Bugs that are awaiting SRU verification (watch for comments ... people
commenting on them and not adding the verification-done tag)
- Bitesize bugs (as an ubuntu-server team member I want to find things I can work on)
- these appear in harvest (out of scope)
- Old bugs In Progress (both those that are assigned to team members and that
are not)
Data gathering should be separate from report creation.
Dashboard should show link to report and quantity in that report?
Look at http://
Collecting information across multiple packages
Report creation tools should be easy to access
- Currently http://
Aggregation of team stats into a overview for the release manager ... a summary at the top level
Search will start from packages / projects to which a team is subscribed
Our reports today (most of them):
- http://
User stories:
Test Plan:
Assumptions:
- not possible to distinguish between a bug confirmed by the janitor and a
bug not confirmed by the janitor (http://
- date_last_updated changes when someone subscribes to a bug (http://
2012/02 - Bug Heat definition felt to need some adjustment, but is generally useful. Current experiments with Bug Gravity - which is based on elements of the heat.
From UDS session: http://
Goal:
Have a place where all relevant information can be found. This information has to be fresh and accurate to avoid the need of checking somewhere else.
What do we want to be in a defect dashboard? How is Ubuntu behaving? What do we need to know how well we are doing? How can we focus on fixing the most important bugs first.
What do we want to see?
- I want to see what packages are currently receiving defects and if there is a spike in activity
http://
- I want to see what bugs have highest gravity and or heat
http://
- I want to see the bugs affecting most people
- I want to see what bugs are currently receiving activity (comments, duplicates, metoos)
- I want to see where there are defects emerging and problems across the entire set of ubuntu products.
- I want to see what errors are being reported the most in the error tracking database - without linked bugs?
- I want to see what bugs are tagged iso-testing (reported when iso-testing)
- I want to see historical trends in bugs. (use for scheduling work based on historical data is an example of why - seeing patterns in incoming behaviour, trends of open bugs over releases, way to judge if we're getting better quality).
- I want to see what bugs were fixed recently so I can search for duplicates of them
- I want to see bugs that are fixed upstream.
- I want to see bugs that exist upstream.
- I want to see bugs that are SRU candidates/are in SRU processing
- I want to see kerneloops reports grouped by driver or instruction pointer(EIP/RIP)
- I want to see a count of bugs assigned to my team
- I want to see regressions
- I want to see abandoned defects (critical or high bugs without activity) and or (critical or high bugs without an assignee [or bug watch])
Want to move spike and hottest to use gravity? Only hottest
Affecting most people is different from having a high heat.
Linking crash to bug: crash signature to bug number -> will be trying to make this same sort of keying behaviour. Where don't have bug report, being able to submit one?
If it doesn't have a bug, look at it being created automatically? if not, need to consider another type of data (link used in errors.ubuntu.com),
Examples to consider:
errors.ubuntu.com ( https:/
Quality Dashboard: https:/
lpqateam.
meego?
Most of the above we can fetch from launchpad, except what's in errors.ubuntu.com and isotracker.
- iso tracker api should be used for finding iso-testing bugs associated with currently tested milestones
- errors.ubuntu.com has an API to access it (public and private part)
Separate per sections: finding bugs to fix, fixing bugs
Split errors.ubuntu.com crashes per pockets (-updates, -proposed, etc)
Need to get mock ups of the screens set up.
This dashboard will have public and private bugs. The private bugs can be masked for users that have no permission to view them (use openid?). Discussion trending towards leaving them in list by number but no additional information unless we can use open-id to figure out teams that people are in. Chris Gregan has this bit built.
Crash database should be storing kernel oops (work item exists in another blueprint). http://
For certificaiton team, need to know the hardware information. Ev is looking at SHA hardware solution from other sesssion.
PES dashboard has code sources for backend to draw from.
Some work already done by arges: https:/
20120611: (KES) Meego dashboard can be found:
http://
some of the interesting example sub pages are at:
http://
http://
Work Items
Work items:
[ursinha] Find a design person and request input about how to display all this data: INPROGRESS
[ursinha] Create mock-ups and request input from people that will use it - kate, brian, cgregan, ev, bjf, mmrazik: INPROGRESS
[mpt] draw mockups and work with Ursinha to refine <https:/
[kate.stewart] get references to meego dashboard as example to look at for mockups: DONE
[ursinha] Check how to use openid to make access to the bugs restricted. Keep private bugs/crashes in the list, but allow/deny access to them: TODO
[ev] make information about errors regarding phased updates and proposed packages available via the API: TODO
[brian-murray] modify searchTasks in Launchpad API to have date_created_since accept a beginning date range so that we can link to the bugs that make up the spike in activity (https:/
Dependency tree
* Blueprints in grey have been implemented.
