• 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 would 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

Bug reports and feature requests are a continuum with no definite boundary. Trying to impose a boundary has little benefit, and significant costs.

The most obvious cost is that people often waste time reporting an issue in the wrong application, shuffling issues between one application and the other (examples 1, 2, 3), or wondering which to use in the first place. For example, often a seemingly simple bug is reported, but the developers realize that fixing it will be complicated enough to need a specification. To humor Launchpad's data model, you then need to (1) write the specification on a separate wiki, (2) include a link to the bug report in the specification, (3) register the specification under Blueprints, (4) put the tracked blueprint's URL in the specification itself, (5) update the bug report to mention the blueprint, so that the reporter doesn't think nothing's happening, (6) implement the specification, and record it as being implemented, and (7) remember to mark the bug as fixed. It would be simpler and quicker if the specification could be written, edited, and tracked right there in the original report.

(The flip side of this problem is that the existence of "Blueprints" as a separate category encourages people to report ill-thought or incomplete ideas, consuming the time of developers.)

Second, scheduling is slower and more error-prone, because bugs and features are prioritized separately, such that it's not obvious which thing a developer should work on next. FogBugz addresses this directly: "The best way to use priorities is to have a single, global priority scheme across all your projects, bugs, and features, so that every team member can always work down their list of cases in order of priority." Similarly, in Google Code Hosting: "The issue tracker can be used for feature requests, support requests, or any other type of development task that a project needs to track". And in Trac: "tickets are used for project tasks, feature requests, bug reports and software support issues".

Launchpad could address this issue with separate to-do lists or task lists, but that would be adding even more complexity. With a combined issue tracker, the list of open issues would be the task list. This would not require projects with well-established separate specification processes (such as Python or Plone) to start using Launchpad for both bugs and feature requests simultaneously; they could adopt a "bugs only, please" policy if they wished. But for those projects using Launchpad for both, it would become much easier for developers to track all the things they are assigned to do.

Third, there is slower development of Launchpad itself. Having one fewer application would not only simplify Launchpad's codebase, it would also make Launchpad's bug-tracking and feature-tracking abilities both more feature-complete. Bug reports have comments, tags, multiple contexts, privacy, attachments, duplicates, easy linking to/from other bug reports, branch registration, product/package subscriptions, batched notifications, e-mail filtering by header, list sorting, and advanced search; blueprints should have all these things too, but currently don't (bug #3522, bug #3552, bug #58408, bug #49698, bug #68206, bug #72669, bug #113752, bug #126721, bug #137397, bug #147394, bug #147404, bug #218272, etc). Conversely, blueprints have feedback requests, and registration for sprints or hackfests; bug reports should have both these things too, but currently don't. And there are other features missing from both applications that will, if Bugs and Blueprints are kept separate, have to be implemented twice. We should be spending more time implementing awesome stuff, and less time implementing basic stuff multiple times.

Now that the Malone identity has been retired, there is not even any branding benefit in keeping the applications distinct.

Use cases

• Liu Qishuai implemented Internet sharing in Gnome's network-admin, and wanted to tell Ubuntu developers about the new code. Reasoning that this wasn't a bug, it was a feature, Liu registered a specification in Launchpad, but then found no way to attach the patch. Tragedy ensued.

• In theory, the Landscape developers use Launchpad's bug tracking features, while tracking specifications solely using a wiki. In practice, they end up entering mini-specifications into bug reports, because it's so easy to do.

• Dan Lipsitt had an idea for different behavior in Launchpad, but he didn't know whether to request this as a bug report or a specification. Nobody else knew, either.

• Jeff Bailey found a confusing page in Launchpad, but said: “I don't know where to file this, since it's not a bug (the page works), [and] not a support request (I know how to make it work).” So he e-mailed me (mpt) about it instead.

• Andrew Frank wanted to report problems with Ubuntu’s documentation. He mistakenly concluded that Launchpad did not have an appropriate place for this: “finding a problem in documentation is neither a bug report nor a new feature, so i suggest to add a new heading for such issues”.

• Alan Pope expressed a similar sentiment on the first episode of the Ubuntu UK Podcast, when discussing Brainstorm: “Some things you wouldn’t consider a bug, wouldn’t consider a feature request/blueprint … I mean one I’m just looking at now, whilst I’m talking, is ‘Do not install support for Palm devices by default’. Now to me, that’s a valid point. I don’t own a Palm OS device, why would I want support for it? But I wouldn’t be able to consider that a bug, and I wouldn’t be able to consider that really a feature request.”

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.

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?
  • For example, What would happen before and during UDS?
• 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?