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.
• convert/rewrite the iso-download script to make use of jigdo to reduce the time needed to download multiple ISOs as well reduce the bandwidth load on cdimages.ubuntu.com

Feature tracking and feature testing days

The late-in-the-cycle bug about the /home preservation feature made me think about this.

Until today, we have been focusing the testing days in ISO testing and a couple of features (update-manager, i.e.). We have started testing days very late in the cycle, where ISO testing is definitive something worthy.

But now we can use the testing days, at least before Alpha, to test features for Jaunty. This task would require a closer look to when and by who the new features are being developed, to know when it is a good timing to do the testing.

After that a normal testing day would go as described below:

1. Preparation
   • I or someone else organizing a testing day would pick one of the features ready to test and would investigate it and how to test it (talking with the devs in necessary)
   • An email will be send to announce the testing day, indicating which feature to test and how to test it.
2. The testing day
   • Around #ubuntu-testing organizing and answering questions
   • People finding bugs will tag them with a special tag (testing-day)
3. After the testing day
   • A report will be created with the bugs found and will be sent to the distro-team mailing list.

For this to be successful, we need to track Jaunty specifications and create test cases for them. I have created a first draft of the features pages at Testing/Features/Jaunty

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