QA

Differences between revisions 1 and 8 (spanning 7 versions)
⇤ ← Revision 1 as of 2008-05-16 14:04:00 →
Size: 341
Editor: 161
Comment:
← Revision 8 as of 2008-05-20 07:10:05 → ⇥
Size: 2707
Editor: 161
Comment:
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
=== Session === === Kernel Bug Migration ===
Line 16: Line 16:
 * Notes See [:QATeam/KernelBugMigration].

=== Bug response times ===

Spec: UbuntuSpec: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 - particularly useful
     * this is the first time the bug's state changed
    * date-confirmed
    * date-triaged
    * date-incomplete
    * date-triaged - particularly useful
    * date-fixcommited
    * date-fix-released - particularly useful
    * 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

=== Bug escalation procedures ===

Spec: UbuntuSpec: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 ====
Line 19: Line 77:
Spec: https://blueprints.launchpad.net/foo === 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 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 - particularly useful
          • this is the first time the bug's state changed
        • date-confirmed
        • date-triaged
        • date-incomplete
        • date-triaged - particularly useful
        • date-fixcommited
        • date-fix-released - particularly useful
        • 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

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)