So that we can easily find bugs for Xubuntu during a development cycle, there a few tags you can add to your bug reports. We assume that a tag for the cycle codename is included, if it is not please add one.
ppa: add this tag when you've reported a bug against a package from one of the 3 develeopment PPAs
usability: add this tag if the issue you are reporting is not a standard bug, but one which might be deemed wishlist, such as multiple selection of results in the Catfish results window
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 information than too little.
![[Note]](../../libs-common/images/note.png)
|
|
|
If you are unsure of the package name to report against, you can use your mouse to click on the application window; in a terminal run |
When you encounter a bug with a package from a PPA, you’ll need to file the bug report manually. Once you’ve got the offending package name, go to https://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug.
Crash logs related to the package can be found in /var/crash/. This directory sometimes requires superuser (sudo) permissions to view and extract the contents. These logs can be particularly valuable to include in your bug report, but be sure to review them as they may contain sensitive or personally identifiable material.
Be sure to follow the above general guidelines, and also add the ppa tag so it is clear to developers that this is an unsupported package.
Triaging bugs is getting 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 triaging 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 only be changed by members of the Ubuntu Bug Control team #8211 in the beginning, you will need to report triaged bugs for the team in #ubuntu-bugs on Libera. After you have demonstrated your ability to triage bugs, you will gain more responsibilities from the Bug Control team.
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.
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. Detailed information on the way to add an upstream bug to Launchpad can be found on the Bugs/Watches page on the Ubuntu wiki.
 |
|
 |
| Package and ISO Testing |
|
Working with trackers |