• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

• Launchpad entry: https://launchpad.net/launchpad/+spec/malone-and-blueprint

• Created: 2006-05-11 by MatthewPaulThomas

• Contributors: MatthewPaulThomas

Merging Bugs and Blueprints into a single application 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.

Rationale

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 examples, in the full rationale.

Design

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.

Research

We are starting to contact the projects that most use Blueprints, to make sure we cover.

Dependencies

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

• Work on X can't begin until Y is finished.
• Work on X can begin, but can't finish until Y is finished.
• X could be finished without Y being finished, but the software wouldn't make sense to users in that state.
• X might still be an issue, but it's difficult to tell because of Y.
• Fixing Y would be one way of fixing X, but not the only way.
• X is divided into two tasks, Y and Z.

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:

• If X was fixed, Y would become invalid.
• Y is similar to X, and testers should be careful not to confuse them.
• Y is a regression of X.
• Y is the unfixed remainder of X.

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.

Delegation

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.

• A specification in the Ready state may be delegated to drivers for approval, before being returned for implementation.
• A smaller bug fix that affects the user interface may be delegated to a UI designer for sign-off, before being returned for implementation.
• A code change may be implemented and then delegated to the review team for review, before being returned for committal.
• Close to a major release, a reviewed code change may be delegated to a drivers team to gauge risk vs. reward, before being returned for committal to the release branch and/or the trunk.

Status

Issues should have six possible statuses.

• Unconfirmed: Not yet investigated by someone qualified to determine its coherence.

• Declined: Not appropriate or relevant for this project.

• Incomplete: May be appropriate, but is missing information about the precise problem — for example, reliable steps to reproduce, a testcase, or hardware details.

• Ready: The issue is described well enough, and is approved if necessary, so that work can begin. (Cf. BugzillaWorkflowImprovements.)

• In Progress: Actively being designed, implemented, or fixed. (Some projects and/or assignees may not bother with this status.)

• Done: Fixed, implemented, or achieved. Any unresolved issues have been recorded separately. For versioned things (such as software), the version/versions in which the issue is resolved should be recorded.

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:

• “New” -> “Unconfirmed” (because “New” is misleading)

• “Invalid” -> “Declined” (because “Invalid” is needlessly harsh)

• "Won't Fix" -> "Declined"

• “Opinion” -> “Declined” (because something being a matter of opinion is orthogonal to whether the maintainer will accept it)

• “Confirmed” -> “Unconfirmed” (superseded by users-affected count)

• "Triaged" -> "Ready" (because the name "Triaged" is both misleading and over-specific)

• "Fix Committed" -> "Done" with "context-target-name-committed" tag (for easing migration of projects that were purposefully distinguishing between Committed and Released)

• "Fix Released" -> "Done" with "context-target-name-released" tag

Importance

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.

Implementation

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

• port missing features from Blueprints to Bugs, rolling them out as ready
• implement the rebranding of "Bugs" to "Issues" and the hiding of "Blueprints"
• implement migration of all current blueprints to issue reports
• simultaneously roll out the rebranding and perform the migration
  • possibly the migration can be done in the hours after the rollout
• once it's all working, implement the removal of the dead code and DB records.

Code changes

Schema changes

Migration

• blueprint "names" become issue nicknames
  • requires uniqueifying nicknames
• bugs with "Wishlist" importance reset to "Undecided" for proper triage

• URL redirects (https://launchpad.net/bugs/nnn should continue to work)

• "Blocked" should be represented by an unresolved dependent issue

Unresolved issues

• What would be the typical process for small, medium-size, large projects?
• What to do with "informational" specifications?

• Bug 136103: Suggestion about bug types

• Bug 176431: Better organization/segregation of wishlist items

• Could "Declined" and "Done" be merged into "Closed"? Is there a functional distinction between the two? For example, if a bug is reported about a feature that is later removed, should the bug be considered invalid or fixed? Google Code Hosting makes no distinction by default. And Ubuntu package changelogs "Close" bugs, rather than fixing some and invalidating others.
• How should "Does not affect software X" (or "Does not affect software X version Y") be represented?

What would happen at UDS?

We should research things like this:

<rickspencer3> jcastro, where can I see some organized lists of the blueprints registred to date for Natty?
...
<jcastro> https://blueprints.edge.launchpad.net/sprints/uds-n
...
<jcastro> the link at the bottom takes you to the "pending" ones people are submitting
...
<jcastro> which is the link you'll want to check regularly
<rickspencer3> jcastro, can I see them listed by track?
<rickspencer3> also, I'd like to be able to list them by team if possible
<rickspencer3> jcastro, does stuff like this work: https://blueprints.edge.launchpad.net/sprints/uds-n?searchtext=*-foundations-*
<rickspencer3> ?
<jcastro> rickspencer3: clicking on the column sorts them by name, which is are the tracks
<jcastro> yes, it does
...
<jcastro> rickspencer3: as long as you stick to the naming convention it should be fine