Quality Assurance

Like any piece of software, Xubuntu needs people to track bugs and do continuous tests on the development versions. Working with the Xubuntu quality assurance has three main aspects:

In addition to the links mentioned below, the Ubuntu wiki has some good pages on bugs, including Helping with bugs, Standard responses, How to debug bugs and Common tasks.

Please note that all of the tasks mentioned below require you to have registered a Launchpad account.

Testing

Testing the development versions of Xubuntu and packages in it helps keep up the every day quality. If you have spare hardware resources or possibility to run a virtualized testing environment, you can help.

Testing is most useful right before the release milestones. To see how these milestones are scheduled, refer to the Ubuntu release schedule.

The Xubuntu testing infrastructure is made up of three key parts:

  • Testing trackers (for ISOs and packages), with information on tests to run along with instructions how to run them
  • Xubuntu Testers team at Launchpad, which you should join once you’ve started helping with testing
  • The xubuntu-devel mailing list, where further information on new packages, known bugs and much more can be gathered and where discussion about critical bugs take place.

Using the trackers

While the QA trackers have all the necessary information on how to do testing, for a quick overview, here’s what you need to do after adding yourself to the Xubuntu Testers page and team:

  • If you are doing ISO testing, download an ISO; download links can be found in the QA tracker, along with zsync commands and check the ISO integrity against the MD5 checksum found in the tracker
  • File bugs when you notice them while testing
  • Report the tests to the tracker along with the list of bugs you have found

Remember that testing doesn’t help the developers unless the tests are reported!

Exploratory testing

In addition to testing the ISOs and software with predefined testing actions, community members can do exporatory testing as well.

Practically, exploratory testing means running the development release and doing your daily tasks with the system and finally, filing bugs when you find them (as usually). This allows us to get a much larger scope for testing than we ever can with predefined tests.

Filing bugs

Anybody using Xubuntu can file (or in other words, report) bugs, even with no experience at all. Filing bugs is important because in some cases, bugs can go unnoticed unless an end user files them.

Before submitting a bug, you should look at the existing bug reports and release notes to verify the bug hasn’t been reported already. If the bug has not already been reported, you should file a new bug report. It is sensible to read through the bug reporting guidelines before filing your first bug.

In the most situations, it is easiest to file a bug by opening a new Terminal and type ubuntu-bug package-name, where package-name is the package you want to file bug against. If you don’t know which package you should file the bug against, refer to the instructions on finding the right package. When filing the bug, it is better to have too much than too little information.

After you’ve filed a bug report, be ready to cooperate with developers and triagers to give them more information if needed to help them debug and fix the issue.

Please note that feature request and development ideas do not count as bugs, and thus shouldn’t be filed as bugs.

Triaging bugs

Triaging bugs means to get bug reports in a state where they are useful for developers by making sure bug reports have useful titles, descriptions, appropriate logs and more. To get started, read the page on How to triage bugs in the Ubuntu wiki.

After you have made yourself familiar with the aspects of triaging bugs, you can start triaging Xubuntu bugs. Please note that the bug status and importance can be only be changed by members of the Ubuntu Bug Control team – in the beginning, you will need to report triaged bugs for the team in #ubuntu-bugs on Freenode. After you have demonstrated your ability to triage bugs, you will gain more responsibilities by the Bug Control team.

Also, as you gain experience on triaging Xubuntu bugs, you may want to take a look at new bugs that mention Xubuntu. Triaging new bugs is recommended for those who are more familiar with both triaging and Xubuntu generally, since not all of the new bugs mentioning Xubuntu are actually Xubuntu bugs.

Forwarding bugs upstream

When bugs are forwarded upstream, all users of the relevant software will benefit from the debugging, triaging and patching work carried out by bug triagers and developers.

Once it has been determined that a bug is not caused by a change in Xubuntu, bugs can be forwarded to their respective upstream projects to be reviewed. For example, all appropriate Xfce bugs should be filed in the Xfce bug tracker. In addition, to track the status of the bug in Ubuntu, the bug in Launchpad should be linked with the upstream bug.

The Ubuntu wiki has an extensive page on forwarding bugs upstream along with instructions on how to report bugs in the upstream bug trackers.