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

Announcements

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

Bugs

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. You can find information on how to report bugs at Reporting Bugs

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.

Testing

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.

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 :

• gtkperf : Test the performance of the gtk theme.

• phoronix-test-suite: General benchmarks and test suite.

• bootchart : Test boot process.

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.

PPA Testing

Sometimes during the test cycle one of the developers may ask you to test something specific for them. Most often this is from a staging area. To temporarily add a staging area (below is an example using the lubuntu-staging ppa and the application lxinput), install what they want you to test and then remove the staging area following the below example.

sudo apt-add-repository ppa:lubuntu-dev/staging
sudo apt-get update
sudo apt-get install lxinput
sudo apt-add-repository -r ppa:lubuntu-dev/staging
sudo apt-get update

This will 'grab' the lxinput from the staging area and then remove staging. If the new lxinput broke your system, then you need to get rid of it and re-install the current version

sudo apt-get remove lxinput
sudo apt-get install lxinput

This will remove the new lxinput we got from the ppa, and now that ppa is no longer in use, the install will 'grab' the one from the normal area. If you are working on a bug, it is important to test with these packages to verify it has been fixed.