Ubuntu Wiki

This page is used by the QATeam to track ideas about what should be done for JauntyJackalope. Anyone is free to add their own suggestions, but please try to keep them short. Exposing and discussing the technical implementation of an idea should not be done here, but in a separate wiki page created for this feature and tracked in launchpad. You can more information about this process on the FeatureSpecifications wiki page.

Keep ideas to a short sentence, somehow categorized, and - if possible - attributed so they can be followed up with the proposer. Discussion of ideas should take place on the mailing list or in the irc channel (#ubuntu-quality on Freenode).

So what do you think should be done by the QATeam for JauntyJackalope ?

Ideas

Please add your suggestions here.

• Add a procedure in ISO testing for "Install (free space)" option on qatracker. Bugs related to this option in installation cannot be subscribed to other options (for example, Bug #289663).

• Add a "In progress" state in the ISO testing tracker. We usually do this at #ubuntu-testing as /me takes desktop i386, and alike. But it would be great to see in the tracker who is working on what and remark what test you are going to start.

To Be Reviewed

These ideas should be reviewed to see whether they are still applicable for JauntyJackalope. If not, they should be removed.

LaunchPad Tags Improvements

Currently, Launchpad only has an alphabetical list of all tags in use which is more than slightly cumbersome. There is, however, a nice wiki page which lists semi-official tags by area and package (see here).

Possible ways of improving Launchpad's use of tags:

• For large bug count packages have a maintainer defined portlet with common tags.

  • Example: OpenOffice.org or Network Manager (as seen on the Tags page).

• For projects hosted by Launchpad (including Ubuntu) have a Driver defined portlet with "official" tags.
  • This would most likely help other hosted projects more than Ubuntu, especially considering a goal of the tag system was to be free-form.
• Extend tags to carry a "vote" and threshold rather than a simple binary presence.
  • This could allow for tag clouds, if enough people followed a bug.

Better Bugfixing Documentation

The current bug process has a hole in the documentation:

1. Find / Report Bug
2. Reproduce and triage the bug
3. ?????
4. Upload patch!

We need to find, aggregate, write or otherwise document common strategies for fixing bugs. Things like VCS bisection, using GDB to find the cause of a segfault, installing debugging symbols and so on. Language specific stuff could also help, but at least getting a few strategies documented somewhere we can point people to would help them help themselves, and the larger open source community. Crimsun suggested OpenSolaris has documents on the subject; we might want to Liberate them for the Greater Good.

Dev / Triager Training Days

The purpose of one of these days (which could be rolled with an UbuntuBugDay) is to provide a space and time for developers to ask bug triagers questions on best practices.

The rationale for this is that many developers started doing their work before many new changes in the way triage happens in Ubuntu and Launchpad came about. What makes this different from a general "learn how to triage" event is that it is focused on helping developers, not triagers (specifically, but triagers are welcome to attend).

Some things to cover include:

• Providing a list of "need-to-have" information for debugging a particular package (logs, traces, etc).
• Communicating the severity of a bug via the Importance field in LP.
• ...