QA
Differences between revisions 5 and 7 (spanning 2 versions)
|
Size: 1266
Comment:
|
Size: 2644
Comment: Updated bug response times with notes
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| See KernelBugMigration | See [:QATeam/KernelBugMigration]. |
| Line 30: | Line 30: |
| * Notes | * How can we measure it? * some date transitions are recorded in Launcpad * available on a per task basis ** date-left-new * this is the first time the bug's state changed * date-confirmed * date-triaged * date-incomplete ** date-triaged * date-fixcommited ** date-fix-released * date-closed * date-inprogress * date-assigned * date-created * the date-created for a bug watch would show when the upstream task was created * the activity log, bug-watch-updater first comment, shows when the watch was created * available for the bug in general * date reported * date updated * missing? * date importance set - in activity log but potentially hard to parse * look at the average or median response times over a 1,3,6 month period * a new tool in the bughelper suite could be used to show time in state statistic infromation * How can we improve it? * making information publicly available * Display on per-package status page * also combine some packages for example linux-source, linux-restricted-modules, linux-ubuntu-modules, linux-backports-modules * Display on a per repository basis * Display on a per team basis using something like https://bugs.launchpad.net/~ubuntu-printing/+packagebugs * these are packages that a team is subscribed to |
UDS Intrepid QA Report
[:UDS-Intrepid/Report:back to the reports index page]
Plans for 8.10
Place in this section bullet points of specific intended outcomes for the 8.10 development cycle.
- Outcome
- Outcome
Sessions
Kernel Bug Migration
See [:QATeam/KernelBugMigration].
Bug response times
Spec: foo
Agenda
- How can we measure it?
- How can we improve it?
- Display on per-package status page?
- Larger picture: global bug volume
Notes
- How can we measure it?
- some date transitions are recorded in Launcpad
- available on a per task basis
- * date-left-new
- this is the first time the bug's state changed
- date-confirmed
- date-triaged
- date-incomplete
- * date-triaged
- date-fixcommited
- * date-fix-released
- date-closed
- date-inprogress
- date-assigned
- date-created
- the date-created for a bug watch would show when the upstream task was created
- the activity log, bug-watch-updater first comment, shows when the watch was created
- * date-left-new
- available for the bug in general
- date reported
- date updated
- missing?
- date importance set - in activity log but potentially hard to parse
- look at the average or median response times over a 1,3,6 month period
- a new tool in the bughelper suite could be used to show time in state statistic infromation
- available on a per task basis
- some date transitions are recorded in Launcpad
- How can we improve it?
- making information publicly available
- Display on per-package status page
- also combine some packages for example linux-source, linux-restricted-modules, linux-ubuntu-modules, linux-backports-modules
- Display on a per repository basis
Display on a per team basis using something like https://bugs.launchpad.net/~ubuntu-printing/+packagebugs
- these are packages that a team is subscribed to
Bug escalation procedures
Spec: foo
Agenda
- Case 1: World breaking regressions in stable or late devel version
- Using the critical importance with an escalation bot
- Case 2: Important bugs that need be made more prominent before release
- Formal and informal escalation paths within the QA team
Notes
- Notes
Upstream Bug Workflow
Agenda
Notes
Extending the test tracker
Agenda
- SRU Fix validation facility
- More granular test case recording
Notes
Extending qa.ubuntu.com
Agenda
- Landing page
- Per-package weather reports
Notes
UDS-Intrepid/Report/QA (last edited 2008-08-06 16:15:30 by localhost)