Not logged in - Log In / Register

Merging Bugs and Blueprints into a single tracker will make Launchpad more functional and easier to use, make scheduling easier for developers, simplify the codebase, and make Launchpad development faster. Bug reports, feature requests, and other to-dos can be created, processed, scheduled, and resolved the same way. This should not be implemented as a whole new tracker, but by porting missing features from Blueprints to Bugs, then rebranding and migrating. This specification covers (1) the tracker itself, (2) how representative projects would use it, and (3) how we will orchestrate the implementation and migration.

Our current top-level chronological plan:

  1. bug dependencies
  2. burndown charts
  3. work items
  4. nomination of bugs for sprints
  5. names?
  6. migration (data and socialization)

Some changes probably need to be chunked with visual design changes and data (e.g. bug status) changes.


Tracking bug reports and feature requests in separate systems makes tasks hard to report, hard to track, and hard to schedule, subtly discourages quality in projects that use Launchpad, and impedes development of Launchpad itself. These points are explained, with many examples, in the full rationale.


We have carried out interviews and statistical analysis of the projects that most use blueprints. (Unfortunately, because some of these projects are private, the data is also private. The following user examples capture the publishable details.)

User examples

The tracker

Bugs and Blueprints should be merged into Issues, a unified application for handling bug reports, feature requests, and other to-dos. Projects should be able to choose what kind of issues they want to use the issue tracker for, without having to learn separate applications.


Issues should have six possible statuses.

Issues marked as "Declined" or "Done" should continue appearing in search results for a period afterward (defaulting to six months, but configurable per-project to suit the typical upgrade cycle of the project's users). This would perform almost exactly the same duplicate-reducing function as "Fix Committed" was intended but failed to do, and as "Won't Fix" does, but in a much simpler way.

Data migration:


Issues should have the same set of importance values as Bugs had previously, except without Wishlist. Whether something is a wishlist item is orthogonal to how important it is.


For effective issue tracking, it is important for all issues assigned to someone to represent things they are able to work on right now. When an issue is blocked on someone else, it should appear in that person's task list, and be downplayed in your own. Therefore Launchpad should know about delegation, or temporary reassignment.

Work items

As a workaround for poor tracking in Blueprint, the separate work items tracker has been grafted on top for large projects (Ubuntu, Linaro, Drizzle), with burndown charts. Work items are entered, and edited, as lines of text in blueprint whiteboards. Bug reports are (at least currently) too much work to use as work items. Any combined issue tracker will need to satisfy the same requirements.

No dependencies

Some bug and issue trackers include dependency tracking. Unfortunately dependencies are used to express a variety of different relationships:

When people assume that all dependencies are of the first sort, development is slowed unnecessarily.

FogBugz doesn't record dependencies, because "on software teams, it's almost always the case that the team can keep working even when there's a dependency. Software developers have a great deal of flexibility in the order in which things are done, unlike, say, a construction crew building a house. Because it's so easy to create simple stub functions as placeholders, with software, it's perfectly reasonable to build the roof before the foundation is poured."

There are also other interesting relationships between issues, that cannot reasonably be tracked as dependencies:

With all these relationship types, the benefit of having a specific field for them in Launchpad is outweighed by the cost of the extra complexity. And this applies exactly as much to feature requests as it does to bugs. Therefore issue relationships should be recorded using free-form text in the issue's description, with Launchpad automatically linking issue numbers as it does now for bug numbers.

Data migration: Once blueprints are assigned issue numbers, blueprint dependencies should be converted to sentences at the end of the issue description.


This would not be implemented as a whole new tracker. The overall implementation plan would be:

Code changes

Schema changes


Unresolved issues

Robert(TA)'s issues


Transcription of jml's notes made at the Launchpad Thunderdome 2011-01-19

IssueTracker (last edited 2014-04-24 12:29:08 by mpt)