Improving Ubuntu: A Beginners Guide to Filing Bug Reports

OK stop! It looks like there is a lot of text here, but I promise you that submitting bug reports is not complicated. This post will attempt to walk you through filing good bug reports in Ubuntu's bug tracker, called Launchpad - specifically at https://bugs.launchpad.net/ubuntu/. Understanding the process will help you get your "bug" solved as quickly as possible.

Due to the large volume of bugs that get reported, it is important that you file bugs correctly and with as much information as possible. As a bug triager, I assure you that this will significantly improve the chances of getting your bug looked at and fixed in a timely manner!

A Brief Background on Bugs:

What a bug is:

A "bug" exists in software when a program does something unexpected, usually causing problems for the user. Some examples include:

a program crashing or closing unexpectedly

a (simple) missing feature

unexpected error messages, often preventing a program from continuing normal operation

other unexpected behavior

What a bug is not:

a support request (use the forums!)

a missing feature that requires more than minimal work to implement

a bad configuration on your machine (ask here on the forums for help tracking it down)

How do I know?

Those who are very new to Ubuntu and/or Linux in general should make posts here on the forums before filing bug reports. Many people run into problems that aren't really bugs, and many common problems that are bugs have already been filed (but please check for yourself!).
The forum community members can often help you work around bugs - please ask if they think you should file a bug report.

-> Before filing a bug report <-

Make sure you have an account on Launchpad - you can't file a report without one. If you don't have one yet, go to "Log in / Register" at the top right of a Launchpad page, then follow the directions.

Search Launchpad's Bugs in Ubuntu for duplicate reports - is there already a bug open for your problem? If so, respond to that bug report, and confirm it if possible (change the Status from New to Confirmed). If you find such a report, please be sure that it is for the exact same problem that you have. If it is a bug related to a specific piece of hardware, then you should also have that hardware (or one extremely similar). If it's not the same, file a new report and mention that other bug as a similar problem - a triager can help you determine if the problem is actually the same.

Apport is a tool that ships with Ubuntu and can assist both end users and developers. It automatically attaches important data to the report, like version information and relevant logs. In some cases, it will automatically appear to help you file reports (like after program or system crashes).

In many programs in Ubuntu you can go to Help -> Report a Problem or Help -> Report a Bug and Apport will collect information automatically for you and take you to the bug filing page on Launchpad where you can elaborate on your problem.

Alternatively, from the terminal you can run the following to have Apport collect information automatically for you:

Code:

ubuntu-bug packagename

It is important that you try to file the report under the right package. This can often be confusing, so try your best. If you really don't know, leave the package name off and you will be prompted about some common problem areas.

Apport will now collect some information and prompt you to to send the report. You may view what is being uploaded by expanding Content of the report. Now click "Send Report". A browser window will open and navigate to Launchpad. If needed, login, then proceed.

After Launchpad is finished processing, describe the bug in one short statement (this is the bug's title - be descriptive!). Click "Next".

A list of bugs that Launchpad thinks might be similar are listed - check them. If you don't find a match, click "No, I need to report a new bug".

Now you can describe your bug in more detail. Include steps to reproduce the bug, and methods you've tried to solve the bug or work around it.

If you need to attach any files (like screenshots) to the bug report, expand Extra options and go to the Include an attachment section at the bottom and browse for the file. You can only upload one file at a time, so if you have multiple files to upload, you will need to add them in Comments after submitting the bug report.

When you believe there is enough information provided, click "Submit Bug Report".

-> After filing a bug report <-

You can add extra comments at the bottom of the bug report. You can also add more attachments by clicking "Add attachment or patch".

You should receive emails about changes and responses to the bug report - follow up! A bug can't be completed until you provide all information that has been requested. Bookmark the bug report and check back regularly for updates.

You may be asked to file a bug report upstream - this means doing something similar to what we did above, but at a website outside of Launchpad. This can get a little complicated, so feel free to ask how to proceed - more information is available here.

You may also be asked to check if the bug exists in the development version of Ubuntu by using a LiveCD.

Generic lifecycle of a bug report:

User experiences a problem and files a bug report

If lucky, somebody else will confirm the bug report (do not confirm your own bugs!)

A triager looks at the bug report. If more information is needed, the triager will request it. The bug reporter will provide the requested information. Repeat as necessary.

When the triager is satisfied that there is enough data, the bug will be marked as Confirmed (or even better, as Triaged). The triager should set an Importance on the bug in most cases, and possibly assign it to a developer or team.

A developer looks at the bug report - they will either ask for more info, fix the bug or reject it (either because it's not worth fixing, or it's not actually a bug).

The bug report is closed with a Status of Fix Released, Won't Fix, or Invalid.

When fixes are released for bugs, the fixed version of the program is usually not made available in stable versions of Ubuntu unless it is a security fix or meets the criteria for a Stable Release Update. The fixed version of the program is usually placed into Ubuntu's development release (unstable).

Re: Improving Ubuntu: A Beginners Guide to Filing Bug Reports

Thanks Rocket2DMn! This is a really complete explanation about reporting bugs on Launchpad. I know you mentioned this in your post, but I would like to stress the importance of following up with your bug reports. If your bug disappears after an upgrade for the package or with a new Ubuntu release, please add a comment to the bug, and close it as 'Invalid'. This will prevent bug triagers and developers from wasting time on that bug report. Also, if someone asks a question in the bug report or requests more information, please try and respond as soon as possible. While the bug report requires additional information, it will have a status of 'Incomplete'. During this time, most developers will not look at the bug. As a result, if you want the bug fixed, it is imperative that you provide all requested material. If you do not provide the requested information for 4 weeks, it will be closed with a status of 'Invalid', and a comment like the following will be added:

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Once a bug is closed (either as 'Fix Released', 'Invalid', or 'Won't Fix'), it no longer shows up in most of the listings on Launchpad. This means that if it was not closed with a status of 'Fix Released', it probably will not get fixed.

Hopefully, you can now see why it is very important to follow up with your bug reports on Launchpad.

Re: Improving Ubuntu: A Beginners Guide to Filing Bug Reports

What you found in the dictionary is the same idea as what a bug triager does. In an emergency situation (ER, battlefield, mass casualty natural disaster, etc), a medical triager is one who works ahead of the medics/nurses/doctors to essentially evaluate the situation and mark the wounded in order of how serious their injuries are (a high priority patient gets seen before a low priority one, and those with injuries too serious to deal with may not get treated at all - the "save as many as you can" mentality). Patients may be grouped together based on the seriousness of their individual situations.

A bug triager looks at bug reports, collects information about the bug, then evaluates how important they are. Developers then use that information to approach solving the problems that they are presented with. A bug triaged with critical or high priority is given more attention than one with medium or low priority. Bug reports that aren't actually bugs are rejected by the triager before developers even get to them (thus saving them time). Esssentially, it would take too much time for developers to go through every bug report, so a triager does it for them so that the developer can spend time fixing bugs instead.

A triager doesn't have to know all the inner workings in order to make a judgment about the situation. So, in medical terms a triager doesn't have to be a doctor (but can rather simply look at a person and with some very basic knowledge, decide how seriously hurt they are). A bug triager doesn't have to know anything about coding, just whether how something reacts is really a bug or just a misconfiguration.

Re: Improving Ubuntu: A Beginners Guide to Filing Bug Reports

Originally Posted by Rocket2DMn

A bug triager looks at bug reports, collects information about the bug, then evaluates how important they are. Developers then use that information to approach solving the problems that they are presented with. A bug triaged with critical or high priority is given more attention than one with medium or low priority. Bug reports that aren't actually bugs are rejected by the triager before developers even get to them (thus saving them time). Esssentially, it would take too much time for developers to go through every bug report, so a triager does it for them so that the developer can spend time fixing bugs instead.

Thanks for explaining. Since my two bugs got triaged for the random freezing with high CPU.

Re: Improving Ubuntu: A Beginners Guide to Filing Bug Reports

Originally Posted by Rocket2DMn

What you found in the dictionary is the same idea as what a bug triager does. In an emergency situation (ER, battlefield, mass casualty natural disaster, etc), a medical triager is one who works ahead of the medics/nurses/doctors to essentially evaluate the situation and mark the wounded in order of how serious their injuries are (a high priority patient gets seen before a low priority one, and those with injuries too serious to deal with may not get treated at all - the "save as many as you can" mentality). Patients may be grouped together based on the seriousness of their individual situations.

A bug triager looks at bug reports, collects information about the bug, then evaluates how important they are. Developers then use that information to approach solving the problems that they are presented with. A bug triaged with critical or high priority is given more attention than one with medium or low priority. Bug reports that aren't actually bugs are rejected by the triager before developers even get to them (thus saving them time). Esssentially, it would take too much time for developers to go through every bug report, so a triager does it for them so that the developer can spend time fixing bugs instead.

A triager doesn't have to know all the inner workings in order to make a judgment about the situation. So, in medical terms a triager doesn't have to be a doctor (but can rather simply look at a person and with some very basic knowledge, decide how seriously hurt they are). A bug triager doesn't have to know anything about coding, just whether how something reacts is really a bug or just a misconfiguration.

Originally Posted by Izek

Thanks for explaining. Since my two bugs got triaged for the random freezing with high CPU.

Re: Improving Ubuntu: A Beginners Guide to Filing Bug Reports

Thanks for the info...

I have already worked on this a few days before and filed 2 bugs...

But what seems the problem is that I want to solve the bugs and I never know how to find a solution. I dont know the entire coding.. i have learnt the basic C, C++ and Java, had OS and Computer Networks as subjects in college,but how can I get into the depth of clearing bugs

and also write system programs that can be benefited by the community.
I have given a query of this in my thread

Re: Improving Ubuntu: A Beginners Guide to Filing Bug Reports

Originally Posted by roshanjose

Thanks for the info...

I have already worked on this a few days before and filed 2 bugs...

But what seems the problem is that I want to solve the bugs and I never know how to find a solution. I dont know the entire coding.. i have learnt the basic C, C++ and Java, had OS and Computer Networks as subjects in college,but how can I get into the depth of clearing bugs

and also write system programs that can be benefited by the community.
I have given a query of this in my thread

Well, this thread isn't about fixing bugs, just reporting/filing them. However... Most software bugs require at least a moderate/good understanding of programming, and some familiarity with the code base with which you are working. Sometimes experienced programmers and other users have the skills (using debuggers and tracing programs) to trace the source of a problem in unfamiliar code and suggest fixes, but we usually just leave it up to the developers of the respective project for which bugs are filed against.

If you do want to fix bugs for a certain project, you should get in contact with the code maintainers (usually by looking at the project's homepage) and ask them directly how you can contribute. Every project is different.

And for your last question, we encourage users to expand their skills and have a little fun by developing their own programs. While most never make it mainstream, there are tons of open source projects out there that find niches, and you are welcome to start your own! Launchpad provides their own revision control system called Bazaar where you can store your code branches.

For more details on these questions, you might consider asking in the Programming Talk forum area. Good luck and have fun!