BugManagement

This wiki page tries to outline the various bug-management related topics regarding Ubuntu Touch. For general guidelines how the Product Team manages milestone bugs, please see the Global Bug Management section. For information about bug handling in the stable phone overlay PPA, check the Stable Phone Overlay section below.

Bug Management for the Stable Phone Overlay

Stable and RC phone development now happens on a vivid-based stable phone overlay PPA. Since all the landings now go to a PPA instead of a standard archive, there is no archive-supported auto-bug-closing functionality. There is also no official series to target your bugs to. Vivid bugs will not be auto closed on landings to the stable-overlay archive.

If a bug-fix is targeted for the rc/stable versions of the phone i.e. the Stable Phone Overlay PPA, please make sure the bug has the Ubuntu RTM task open for the affecting project in it (e.g. "location-service (Ubuntu RTM)").

Global Bug Management for Ubuntu Mobile

Canonical Consumer products consist of 3 major components:

  1. The Ubuntu base OS
  2. Proprietary hardware enablement (HWE), that can’t be shared in the base OS
  3. Customer specific customisations, that can’t be shared in the base OS

In order to reflect a global product status view, we are using Launchpad projects to reflect each of these 3 components (a.k.a. Product Projects). Proprietary HWE and customer specific customization will typically be proprietary Launchpad projects that facilitate the coordination with the commercial partners.

In order to get an aggregate bug status view of a specific product we are using a Launchpad project group canonical-devices-products (LINK). This project group lists all public and proprietary product projects.

Usage

Escalation of bugs to the Product Team

Bugs that are intended to go into a product release should be vetted by the Product Team before they can land in the Product.

Anyone can escalate an existing bug to the Product Team’s attention by adding a bug task (via the “Also affects project” link) for the canonical-devices-system-image project.

The Product Team will assess the bug and document their decision by setting the “Status”, “Importance” and “Milestones” attributes accordingly. See below for a definition of these fields.

Scheduling work

The Product Project Milestone is indicating when a bug is intended to be released. Please use this attribute to coordinate work in your teams. As a general rule, the milestone expresses the latest acceptable date. Please land your code as soon as it’s available.

Should there be a conflict between the requested Milestone and when you can realistically deliver a fix, then please escalate the bug back to the Product Team by setting it to New and leaving a corresponding comment describing the issue.

Where set, “Importance” expresses a relative importance of bugs within a milestone and can be used to manage your team capacity.

Proprietary bugs are not able to make use of this feature. Proprietary bugs for a specific milestone should always be given priority, regardless of their Importance.

Attribute Definitions in the Product Project

Status

The Status attribute is used to express where an escalation to the Product Team is at:

  • New: bug has not been reviewed by the product team

  • Incomplete: need more information

  • Invalid: the Product Team does not deem this bug to be relevant to the product, a next step could be to remove the task from the bug

  • Confirmed: the Product Team accepts this bug as relevant and has set the Status/Importance attributes and also set a target milestone

  • In Progress: the evaluation has started, but hasn't come to a conclusion yet

Status not in use are:

  • Opinion

  • Won't Fix

  • Fix Committed

  • Fix Released

Importance

The Importance attribute of the Product Project is used to express the relative priority of bugs within a Milestone

Milestones

Milestones are used across proprietary and product projects to align a release. The currently chosen format is based on calendar dates, specifically work week numbers and follows following scheme:

wwWW-YYYY, where ww is the prefix, WW the 2 digit work week of the year, and YYYY the 4 digit calendar year representation

All product relevant projects should adhere to this convention for easier alignment (e.g. to make use of upcoming work )

Queries

The Product Project group (canonical-devices-products) allows you to query for bugs of multiple member product projects, their milestones and other relevant parameters.

Touch/BugManagement (last edited 2015-06-01 09:09:04 by sil2100)