Ubuntu Wiki

• Launchpad Entry: kernel-launchpad-improvement-requests

• Created:

• Contributors:

• Packages affected:

Summary

This BP is the result of the discussion between the Ubuntu Kernel team and the Launchpad Architect during the UDS-Maverick sessions. It will be an ongoing effort to improve bug triage in the kernel package.

Release Note

The end user impact of this spec to Launchpad users should be minimal, but will also be documented in an effort to explain it as a part of kernel bug triage. Further documentation may be made by the LP team, but the kernel team will present it in the Bug Triage section of the Kernel wiki pages.

Rationale

There are several requirements put forward by the Kernel Team manager that will be implemented as soon as is possible. These are required for the Kernel team to have effective bugs and to be able to effectively manage those bugs.

User stories

There are numerous instances where a bug is fixed, An original reporter reports that they are solved, but a number of duplicates and 'me toos' are still broken. In some cases this occurs on the same of very closely similar hardware configurations. This is an effort to reduce the instance of the failure to file a new bug based on recommendation by either apport of Launchpad itself.

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

This spec and the resulting functionality will be tested as features are released to the edge servers.

Unresolved issues

This spec and resulting Blueprint will require more engineering time than the Maverick cycle alone will allow. It will definitely have a shifting end date. The effort here is to not allow it to drop off the radar

BoF agenda and discussion

Bug duplication ===============

X, the kernel and probably other plumbing level stuff (sound, network etc) very, very commonly get bug reports duplicated that basically have nothing to do with each other since they are either on different hardware, or because the bug is caused by combinations of hardware.

For Maverick, we'll disable the duplicate detection for hardware-specific packages

[ACTION] ??? give jml / Launchpad devs a list of these packages.

(see pgraner)

Lock down =========

Lots of bugs turn into mini-communities where a large amount of discussion takes place that actually hinders the ability of a developer to fix the bug.

We want to prevent comments, status changes -- whatever -- for bugs that have become useless.

We aren't sure whether we want to prevent comments from the original poster.

• jml -- maybe we can have a checkbox to determine this

(from linux & the kernel team -- Ted T'so has a major issue dogpiling on bugs)

https://bugs.edge.launchpad.net/malone/+bug/73122

Fix released ============

When a bug is "fix released", only experts (bug supervisors?) should be able to re-open it.

Maybe we should only do this for hardware-specific packages.

Comment Hiding ==============

Changes to duplicates may address the problem somewhat, but there is going to be a general problem with people putting unhelpful comments. The me-too's can tend to annoy upstreams who we do want looking at our bugs.

(Interim way to help address large numbers of comments, instead of listing the first 80 comments, show first 40 and last 40 or something)

https://bugs.edge.launchpad.net/malone/+bug/522741 https://bugs.edge.launchpad.net/malone/+bug/557386 https://bugs.edge.launchpad.net/malone/+bug/58670

• Delete abusive comments (spam, phishing)
• Collapse (or something) comments that are discussion comments that
  • are not helpful in fixing / analyzing the bug -- need intelligent human moderation in doing this

• Show the first N & last M comments

Priorities ========== #1 - No dupes for HW bugs #2 - Hiding comments or removing comments #3 - Fix Released locking (maybe per-package) #4 - Locking entire bugs from comment #5 - Get greasemonkey scripts higher profile on LP web docs

General Notes =============

Ubuntu's user-base has changed and is changing. Increasingly, our users are less willing or less able to work with us to get bugs resolved.

Perhaps we need to reconsider the way in which we encourage users to file bugs.

[ACTION] jml to put a call out for LP greasemonkey scripts

People ======

• JFo, Ted Tso, pgraner, bryce, chase, bdmurray

CategorySpec