High Priority

1. Semi-automatic bug forwarding to upstream bug trackers

   • Tracked at: ???

   • Rationale: Ubuntu receives a very high volume of bug reports which should be forwarded upstream. Making this process more efficient would improve both the quality of Ubuntu and its relationships with upstream projects.
   • Status: Some of the steps for this to happen are implemented. Additional work includes:

     • The "no upstream bug tracker exists" use case, which is described in https://blueprints.launchpad.net/malone/+spec/forwarding-to-email-address (Done?)

     • Comment synching to enable inter-bug-tracker replies (Done?)

     • Map remote bugtracker product/component to source package: https://dev.launchpad.net/LEP/BugzillaComponents (Nearly done)

     • Forwarding of selected attachments from LP bug to upstream - https://dev.launchpad.net/LEP/ForwardAttachmentsUpstream

     • Automatic user registration in remote tracker
     • Automatic fill-in of upstream bug report fields (title, description, priority, cc, etc.)
     • 2011-11: Requested to be included in LP 18-month roadmap
2. git support. Native git hosting. Or at least better bzr-git importing.

   • Tracked: 402814 (Req. Benjamin Drung)

   • Rationale: While bzr is awesome, many projects use git instead. Launchpad's utility to the broader community would thus be improved if it was able to host git-based projects. There is a bzr-git importer but it works for only certain projects. It impacts our ability to evangelize other Launchpad features like daily builds, PPAs, and bug tracking to upstream projects we want to work more closely with.
   • Status: Proposed for LP 18-month roadmap
3. Wiki support integrated throughout Launchpad.

   • Tracked: 240067, 254167, 797331, Wiki markup in blueprints

   • Rationale: We need wiki-like markup (including tables), revision tracking, and easy cross-linking to other LP entities so we can display information to users more clearly and orderly, and to keep track of changes made to our pages. E.g. PPA descriptions, project home/about pages, blueprints, whiteboards, etc.
   • Status:
     • Proposed for LP 18-month roadmap, but probably won't make the cut. Estimated 4-6 months for wiki markup, and 4-6 months for revision control.
     • Need to break this general need up into smaller feature chunks
4. QA status/workflow tracking.
   • Tracked: ??
   • Rationale: Testing and quality control are becoming increasingly important to Ubuntu, yet Launchpad provides little in the way of built-in QA tracking supports.
   • Need ways to better flag bugs/branches/patches/etc. as needing testing, passed testing, failed testing, and so on. Ideally should also support hooking into automated testing in some fashion, with the goal of being able to delineate between code ready to be released from that needing additional work.
   • Status:
     • On the LP 18-month roadmap, but the QA team should do some additional requirements definition first, so may be delayed or dropped in favor of more urgent items.
5. Task tracking
   • Rationale: We currently have makeshift task workflows littered throughout launchpad: Workflow tags, blueprint work-items, archive team subscriptions, kernel team abusing bug tasks, merge review requests, sync requests, etc. We need something that is more systematic, unified, coherent, and

   • Tracked at: 393117, 578263, Blueprint decomposition

   • Status:
     • Several other stakeholders mentioned related needs. Was discussed in relation to Dashboards and Activity Lists, but still rather fuzzy.
6. Subscribe/unsubscribe from mails for build failures of recipes and PPA builds.
   • Requested by: Benjamin Drung
   • Status: Similar needs were raised by other stakeholders at the 2011-11 call

Medium Priority

1. Package version tracking for bugs (shortcoming of Launchpad relative to debbugs)
   • Rationale: Some bugs are particular to a specific version of a given package, or are fixes as of a given version. Currently Launchpad doesn't track this so we have to ask for this info every time a bug is filed. If it's filed with apport this generally will attach the info automatically, but many bugs aren't filed with apport.

2. Bug Q&A

   • Tracked at: https://dev.launchpad.net/Bugs/BugQ%26A

   • Rationale: Vast majority of bug reports filed are low quality. The Bug Q&A concept would guide reporters to produce better, more actionable bug reports, thereby reducing the time required by a developer to figure them out; this translates into more bugs fixed per developer hour.

   • Status:

     • Is included on Roadmap - https://dev.launchpad.net/VersionFourDotO/Stories

3. Visual distinction between bug comments from authoritative Ubuntu people and bug comments from random Launchpad users

   • Tracked at: ???

   • Rationale: Users who view and file bugs in Launchpad are not always familiar with the way bug tracking works in a large community project like Ubuntu. When they receive a comment which is inappropriate, erroneous or poorly presented, they assume that it came from someone representing the project, when in fact anyone with an email address can post a response. Users who find these bugs via web searches have difficulty telling the difference between comments from users and authoritative information from developers and QA. We want to avoid this confusion and misrepresentation, while still allowing everyone to participate, by visually showing the user whether the commenter is a member of an official team (such as Ubuntu QA), perhaps by showing the team badge next to their name.
   • Status:

     • original bug at https://bugs.launchpad.net/malone/+bug/81692

     • https://blueprints.launchpad.net/launchpad-registry/+spec/official-project-members covers this for Bugs and Answers

     • Launchpad claims this specification is related to the bug: https://blueprints.launchpad.net/launchpad-foundations/+spec/person-name-presentation

     • Not targeted in Launchpad 4.0
4. Hiding comments or removing comments

   • Tracked at: 1734, 45419

   • Requested by: kernel team
   • Rationale: Bug reports have a tendency to accumulate a lot of inane/irrelevant/insulting comments. When asking an upstream developer to look at a bug report, we'd like to "clean up" the report to display only relevant, useful information.
5. Structured bug json data field(s)
   • Rationale: Currently Apport stores a lot of key:value data into bug descriptions. This is important and useful information but tends to clutter the bug report, can be hard for developers to review, and is error prone for other tools to parse and use. Being able to load this information into some sort of structured storage field (e.g. JSON)
6. PPA improvements. Build status notification. Ability to host multiple versions of a given package (e.g. for bisection study purposes). Expose more of the internal API through the external Launchpad API.
   • Status:
     • Several other stakeholders raised PPA improvements as priorities, so sounds like some PPA improvement ideas will be included in the roadmap already.
     • Need to review what gets included in the roadmap and identify what items we need that fit within that scope
7. Soyuz archive index

   • Tracked at: https://dev.launchpad.net/ArchiveIndex

   • Rationale: Req'd by Software Center
   • Status: Also mentioned by
8. Blueprints improvements:
   • Much work needed: 65922, 115158, 120942, 125377, 126522, 137397, 172532, 177519, 177520, 247672, 307495, 398604, 398605, 489288, 825523
   • Status: Has been proposed to merge blueprints and bugs?
     • If this work is schedule we need to understand how existing use cases will be transitioned. Need guidance and a plan.
     • Merging blueprints and bugs is not included in the next 18 months
     • So, high priority blueprint needs should be escalated normally

Low priority

1. Answers needs either significantly improved, or scrapped in favor of just using AskUbuntu.com. Need guidance and a plan.

2. Opening a new distrorelease before releasing the previous one (shortcoming relative to former dak infrastructure)

   • Tracked at: https://bugs.launchpad.net/soyuz/+bug/87012

   • Rationale: When opening a new distrorelease, uploads must be temporarily blocked until the toolchain and other basic infrastructure are in place. Opening the new release early would allow this work to happen in parallel, so that the new release would be immediately open for development.
   • Status:
     • PPAs make it possible to do some of the preparatory work for a new distro series
     • Fully handling this was not targeted for Launchpad 4.0
     • Need to investigate current status of this need, and raise it through the bug escalation process
3. Notifying the release team of new milestone targets

   • Tracked at: ???

   • Rationale: The release team tracks outstanding targets for milestones and their resolution. However, they currently must poll in order to obtain this information. Asynchronous notification would be more efficient.
   • Status:
     • Structural subscriptions were targeted for Launchpad 2.0 (2009-08-03: update, anyone? Do we push notification now?)
     • Hand this one to the Ubuntu Engineering stakeholder list
4. Search PPAs for version of app you want, for version of ubuntu you're on
5. A way to mark bugs as fixed (no longer in progress), but waiting for a merge (not yet fix committed)
   • Probably should be folded into Kate's Bug Status rework plans
6. Ability to clone or split a bug report, when a user has reported multiple problems that each need tracked separately
7. Search across attachments
   • From previous discussion, sounds like this would be quite hard / resource intense
8. Tarball visibility / navigation
   • Status: Locate the bug report(s) relevant to this; consider raising as regular maintenance bug escalation?

9. Add a "workaround" field to bug (54652). (Already escalated by Corp Services)

10. Launchpad doesn't support multiple attachment (82652). (Already escalated by Corp Services)

Undefined

Other stakeholder issues also relevant to Ubuntu:

See also: Launchpad's RoadMap and list of LEPs.

Historical infrastructure needs