Ubuntu – Are Launchpad bugs in a way moderated

So, in the example you've supplied, the bug is filed against the kernel package for the Ubuntu operating system. You can tell this by looking at the package listed under the 'Affects' block. In this case, it is linux(ubuntu) so it is distro specific.

Depending on how it is filed, a bug may not get the attention it needs. If it was filed against the 'Linux' project, then it is important to note that this is used as an upstream bug tracker for bugs against related distributions.

If this bug was something that you wanted to be addressed by upstream Linux maintainers, then really the only thing you can do is file it on bugzilla.kernel.org. The site being the bugtracker that Linus and the maintainers use to address kernel issues.

In this case, the Kernel Defect Analyst(me :-) ) would triage your bug and bring it to the attention of the Kernel Release Manager. S/He would then determine whether it needed an Engineer's involvement (this is somewhat ambiguous as the KRM is an Engineer in his/her own right so it may be worked by them as well). At that time it will be acted upon.

It is important to note that not all bugs get actively worked. In the vast majority of cases bugs are left alone if there is work ongoing upstream. If you are aware of the bug upstream, then filing a bug against Ubuntu in launchpad is an important way for us to track the issues as they progress in the upstream kernel. This would be accomplished by adding that upstream watch I mentioned earlier.

Hope that helps you a bit. Let me know if you'd like some clarification of any of the above.

(Source: Bugs/Importance (Bug Squad Documentation))

The Ubuntu Bug Squad is one of the driving forces for Ubuntu Bugs, and maintains a documentation of this for the reference of every person.

For the sake of people who hate reading other sites, and for the few people who might be too lazy to click on the link at the beginning of this answer, I'll basically copy verbatim the Bug Squad Knowledge base information that is relevant to here:

QUICK NOTE: When "Core" or "Non-Core" is referenced here, the bug squad is consdering "core" as part of the ubuntu-desktop package, or what gets installed by default on the LiveCD images. This may change in future, depending on further discussion within the Bug Squad on this matter.

(Note the below information may be out of date with the documentation on the wiki, you should refer to the wiki for the most up-to-date information.)

Ubuntu uses the following guidelines for assigning importance. The importance of the bug signifies the priority that it should be given by people fixing bugs.

Here are the meanings of the different importance values):

• Undecided: The default for new bugs. Also means that there is insufficient information to determine importance
• Wishlist: Missing functionality
  • These aren't always bugs, but can be ideas for new features which do not yet exist.
  • These can also be requests to have software packaged for Ubuntu.
  • If it is non-trivial to implement, it should rather be written as a feature specification, see FeatureSpecifications.
  • These can be bugs that affect an experimental extension or non-essential feature of a given package/project.
  • Bugs that would only be fixed on a best-effort or outside-contribution basis might also be considered wishlist.
• Low: Bugs which affect functionality, but to a lesser extent than most bugs, examples are:
  • Bugs that have easy work-arounds
  • Bugs that affect unusual end-user configurations or uncommon hardware
  • Bugs that affect a non-essential aspect and limited scope of the application
  • Bugs that have a moderate impact on a non-core application
  • Cosmetic/usability issues that does not limit the functionality of a non-core application
  • Non-ideal default configurations
• Medium: Most bugs are of medium importance, examples are:
  • A bug that has a moderate impact on a core application
  • A bug that has a severe impact on a non-core application
  • A bug which impacts accessibility of a non-core application
  • A usability issue that does not limit the functionality of a core application
  • A problem with a non-essential hardware component (removable network card, camera, webcam, music player, sound card, power management feature, printer, etc.)
• High: A bug which fulfills one of the following criteria:
  • Has a severe impact on a small portion of Ubuntu users (estimated)
  • Makes a default Ubuntu installation generally unusable for some users. (For example, if the system fails to boot, or X fails to start, on a certain make and model of computer)
  • A problem with an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse)
  • Has a moderate impact on a large portion of Ubuntu users (estimated)
  • Prevents the application or any dependencies from functioning correctly at all
  • Renders essential features or functionality of the application or dependencies broken or ineffective
  • Impacts accessibility of a core application
• Critical: A bug which has a severe impact on a large portion of Ubuntu users
  • Causes data corruption
  • Crashes the entire operating system
  • Renders the system temporarily or permanently unusable
  • Severely affects applications beyond the package responsible for the root cause

The Ubuntu Bug Control members have the access to set these importance statuses on bugs under the purview of Ubuntu (including packages, which ubuntu-bug will do), and can either set them themselves, or at the request of a member of the Bug Squad who is not a Bug Control member.

Generally, when I handle bugs and decide an importance and whether its ready for triaging (unless its blatantly obvious), I follow the Triage Guide for deciding how to triage the bug (which sets the Status of a bug to "Triaged") and the guidelines I've posted (and linked to) above for deciding Importance. (I'm on the Bug Squad, and I am a member of Bug Control, if you're curious)