More Information

This section provides further information and useful links for testers. As with all alphas and betas they are not suitable for a production environment, please take the time to read Common Questions for Testing


At each milestone release, the notes at technical overview are updated.


It is especially important that Bugs found in the development release be upstreamed so that their upstream authors can see them. Often we are using the latest, unmodified alpha code for various projects during the development release, so the odds of it being fixed are much greater if they can be reported to the upstream developers making the changes. During an installation of a new iso, it can fail for various reasons. What to report an install bug against has the details you will need.

Reporting Bugs

Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas. By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you must raise a bug.

My bug is marked Private

Some bug reports (usually those reported about a crash) contain many details of your system. These bug reports are only available to the apport system. The apport system contains a retracer, which will analyze the crash report and provide more details about the crash for developers. Once the retracer has finished retracing the crash, the core dump is deleted from the bug report. This can take a couple of days; in the meantime be patient. After the retracer has done its work, the bug team may still have to remove other personal information before making the bug report public. Your bug is not being ignored, but we do not want to reveal potentially sensitive information to the public.

My Bug became Private

Warning /!\ It is more probable that it was not the bug you opened that became private, but that your bug was marked as a duplicate of another bug report that is private.

There are some bug bots that look for duplicate bugs and they do not worry if the bug being using as the master is private. If this happens please go to #ubuntu-bugs and raise it with the bugs team. Head over to why bugs are private for more information.

Dealing with Bug Reports

Triaging (dealing) with bug reports is a really important area. When new fixes come through it is important to let people know. please try a newer version is one such answer. There is also full list of responses. It is important that the person who raised the bug, no matter if it is incomplete, a duplicate or any other reason is made to feel that their bug is important. Simply put, to them, it is the most important bug in the world and should be treated as such.

The Bug Squad

If you'd like to know more about the treatment of bugs, please head over to The Bug Squad new comers are always welcome.

Installation Bugs

When testing the installer and you find an error that prevents the installation from completing, have a read of Install Bugs to work out what to report the issue against.


Testing is split into distinct, but joined areas. The Daily Builds, the QA-testing of Milestone releases and the Milestone releases themselves.

To not get overly complicated, think of it as that we have a schedule to keep to. A few days before a Milestone is due, the daily is plucked and becomes the QA (Quality Assurance) test version for the Milestone release. Once it is confirmed that the QA version works, it then becomes the Milestone.

All release stages are tracked by ISO Tracker where you can get the latest builds, see and allocate any bugs.

So, in order of how they happen.

Daily Builds

These iso's are automatically generated every 24 hours using the latest updates on the system from the devs. They are available from ISO tracker. Using the zsync (or rsync) option allows you to update your iso to any of the various dailies you choose to follow without having to re-download the entire iso. They are there to check that bugs that are resolved between the Milestone releases do not break the install. They also are used to confirm that any fix for a bug that seriously affects an initial install which is released for testing now works.

QA testing of Milestone releases

Alpha, Beta and Release Candidates (RC) are also tested using ISO tracker. If you want to help out in this important area of testing, please read through Procedures for further details. These appear a couple of days before the actual Milestone release so that we can check they are okay to become Milestone releases.

QA testing is to ensure the actual install iso works, if you can, please get involved in the qa testing

Milestone Releases

Once a Milestone release passes the QA testing, it becomes a Milestone Release and is listed on the Releases as such.

If you would to know more about how this all works, have a read of Stages of testing.

Calls for Testing

Occasionally, we will have unscheduled testing events to test a specific product or feature. Tests for these and instructions will vary, however the qatracker will be utilized if possible to help manage and record the testing.

General Testing

During the release cycle, things will get broken. You can really reduce these occurrences by taking the time to read Partial Upgrades.

Known Issues

All the known issues for a particular release are mentioned in the Announcement email, and are available to see at ISO Tracker.

Manual test of ISO and CD

On the help-pages of Ubuntu there is an extensive guide on how to MD5SUM.

Specific Testing

QA tests

You can do more specific tests, like ones done for the Ubuntu ISO : http://iso.qa.ubuntu.com/qatracker/test/5090

Laptop Testing

Laptops never cease to have their little 'quirks'. You can help on this important area by heading over to Laptop Testing for full details.

Performance tests

You can test some aspects of Ubuntu performance with the following programs :

Unwanted packages

Some packages can be automatically installed, but are not wanted on a default installation. To find the package which automatically installed the package that you don't want :

  • Install apt-rdepends
  • run "apt-rdepends -r --show=Depends the_unwanted_package" => It will show which packages depend on the_unwanted_package.

  • run "apt-rdepends -r --show=Recommends the_unwanted_package" => It will show which packages recommend the_package_unwanted (Recommended packages are installed by default).

  • You may have to run the commands several times to see the complete chain of depends / recommends.

QATeam/Overview (last edited 2013-10-22 21:16:23 by nskaggs)