HelpingWithBugs

Differences between revisions 37 and 58 (spanning 21 versions)
Revision 37 as of 2007-02-21 20:22:36
Size: 5606
Editor: pD9E046EC
Comment: Style
Revision 58 as of 2016-05-05 05:07:48
Size: 5629
Editor: es20490446e
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">'''Contents'''[[BR]][[TableOfContents]]|| ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 10: Line 10:
We regularly hold ["UbuntuBugDay"]s, where people from all over chip in and focus on a particular area. But don't feel like you have to wait. Just jump right in! We regularly hold [[https://wiki.ubuntu.com/UbuntuBugDay|Ubuntu Bug Days]], where people from all over chip in and focus on a particular area. But don't feel like you have to wait. Just jump right in!
Line 12: Line 12:
= Bugs = = What is a bug? =
Line 14: Line 14:
When we talk about ["Bugs"], we're discussing faults or errors in the software. They're errors because the software ''claims'' to do certain things but then fails to. When we talk about [[Bugs]], we're discussing faults or errors in the software. They're errors because the software ''claims'' to do certain things but then doesn't.
Line 18: Line 18:
Some things aren't bugs, but are missing features that should be reasonably included. There isn't a bright line that you can draw between bugs and missing features, but here's a guideline: if it's a problem that would have many details to address, it's likely to be a feature. For example, the inability to write files safely to a modern Windows partition is a missing feature. The inability to write files safely to a ReiserFS parition would be a bug. Some things aren't bugs, but are missing features that should be reasonably included. There isn't a bright line that you can draw between bugs and missing features, but here's a guideline: if it's a problem that would have many details to address, it's likely to be a feature. For example, the inability to write files safely to a modern Windows partition is a missing feature. The inability to write files safely to a ReiserFS partition would be a bug.
Line 20: Line 20:
Another way of distinguishing a bug is if it's a regression. That means that something used to work, and now doesn't any more. We try fairly hard to get these identified early, because regressions are bad news. Another way of distinguishing a bug is if it's a regression. That means that something used to work, and now doesn't any more. We try fairly hard to get these identified early, because regressions represent a reduction in functionality.

= Bug triage =

Bug triage is an essential part of Ubuntu's development.

Triaging bugs consists of several things:
 * Responding to new bugs as they are filed.
 * Ensuring that new bugs have all the necessary information.
 * Assigning bugs to the proper package.
 * Confirming bug reports by trying to reproduce them.
 * Setting the priority of bugs reports.
 * Searching for and marking duplicates in the bug tracking system.
 * Sending bugs to their upstream authors, when applicable.
 * Cross-referencing bugs from other distributions.
 * Expiring old bugs.

However, you don't need to do all of those things to help! Recreating a bug and setting the status to Confirmed is enough.

Bug triage is an excellent way to start helping out. You get to learn a lot about Ubuntu, its available packages, its infrastructure, and you get a feel for the development pulse.

You can learn how to triage bugs and chip in, just see the [[Bugs/Triage]] page.
Line 24: Line 45:
The people who work on bugs in Ubuntu are called the Ubuntu BugSquad. Check out the BugSquad page to learn how to join. The people who work on triaging bugs in Ubuntu are called the Ubuntu BugSquad. Check out the BugSquad/GettingInvolved page to learn how to join.
Line 26: Line 47:
= Bug triage =

Bug triage is an essential part of Ubuntu's development. Jokingly, we like to call it DrinkingFromTheFirehose. This is due to the vast number of bugs filed every day. We get a new bug filed about once every five to ten minutes (circa September 2006).

Triaging bugs consists of a few things:
 * Responding to new bugs as they are filed.
 * Searching for duplicates in the bug tracking system.
 * Sending bugs to their upstream authors, when applicable.
 * Cross-referencing bugs from other distributions.
 * Classifying bugs by package.
 * Prioritizing bugs.
 * Expiring old bugs.

It's an excellent way to start helping out. You get to learn a lot about Ubuntu and its infrastructure. And you get a feel for the pulse of Ubuntu development.

You can learn how to triage bugs and chip in, just see the ["Bugs/HowToTriage"] page.
You can almost always find members of the Bug Squad in #ubuntu-bugs on the freenode [[IRC]] server who will be happy to answer any questions you have.
Line 45: Line 51:
If you've got an interest in a devoting more time, we'd love to have you help fix bugs. Each package you install in Ubuntu gets built from a SourcePackage. Each SourcePackage has a page devoted to its bugs. If you have an interest in delving deep into bugs, we'd love to have you help fix bugs. Each package you install in Ubuntu gets built from a source package. Each source package has a page devoted to its bugs.
Line 47: Line 53:
For instance, the bug page for the {{{hello}}} package is at: [https://launchpad.net/ubuntu/+source/hello/+bugs]. For instance, the bug page for the {{{hello}}} package is at: [[https://launchpad.net/ubuntu/+source/hello/+bugs]].
Line 51: Line 57:
You can learn more about fixing bugs by reading the ["Bugs/HowToFix"] page. You can learn more about fixing bugs by reading the [[Bugs/HowToFix]] page. You can also practise in a safe environment with trivial bugs by joining the [[https://launchpad.net/hundredpapercuts|One Hundred Papercuts]] project.
Line 55: Line 62:
If you've got a keen interest in a particular SourcePackage, you can help out by adopting it. This means that you want to act as a liaison between Ubuntu and the people who wrote the package that we include. If you've got a keen interest in a particular source package, you can help out by adopting it. This means that you want to act as a liaison between Ubuntu and the people who wrote the package that we include in the distribution.
Line 59: Line 66:
You can learn more about doing this by consulting the ["BugSquad/AdoptPackage"] page. You can learn more about doing this by consulting the [[BugSquad/AdoptPackage]] page.
Line 63: Line 70:
 * ["UbuntuBugDay"] - start here! :-)
 * ["Bugs/HowToTriage"] will show you how to begin and which steps are to be followed as a bug triager
 * ["Bugs/CommonTasks"] explains different tasks, which are done in the world of bugs every day
 * ["Bugs/ToolsAndLinks"] lists tools and links, which make your life easier
 * ["Bugs/Responses"] has a list of stock responses for the most common cases
 * ["Bugs/Examples"] show examples of bugs and how they were resolved
 * ["Bugs/Teams"] introduces to different workflows of different teams
 * ["Bugs/Debian"] for specific information about sharing bugs/patches with Debian
 * [:TriagingXBugs]
 * DebuggingUbiquity which states "Please do not assign ubiquity bugs to anyone unless you're a ubiquity developer or you manage a ubiquity developer. Please don't reject ubiquity bugs unless you're a ubiquity developer. In general, please try to refrain from causing unnecessary extra bug mail noise for ubiquity developers or from taking items off their to-do lists without consulting them first."
 * [http://people.ubuntu-in.org/~carthik/bugstats/ Graphs of Ubuntu Bug Stats]
 * ["DebuggingProcedures"] for Ubuntu bugs
 * [[Bugs/HowToTriage]] will show you how to begin and which steps are to be followed as a bug triager
 * [[Bugs/CommonTasks]] explains different tasks, which are done in the world of bugs every day
 * [[Bugs/Status]] how Ubuntu uses the Status field
 * [[Bugs/Importance]] how Ubuntu uses the Importance field
 * [[Bugs/Responses]] has a list of common responses for the most common types of bugs
 * [[Bugs/Examples]] show examples of bugs and how they were resolved
 * [[Bugs/Teams]] introduces to different workflows of different teams
 * [[Bugs/Debian]] for specific information about sharing bugs/patches with Debian
 * [[DebuggingProcedures]] for Ubuntu bugs
Line 76: Line 80:
[:CategoryBugSquad] [[CategoryBugSquad]]

One of the many reasons that Ubuntu is a great operating system is because it's developed by the community. You, me, and hundreds of other people join efforts in making it better each day.

Which is why we're very happy that you want to help with bugs.

If you want information about filing bugs, please see ReportingBugs

Don't feel intimidated when you're first starting out. You can start with something simple like triaging bugs or you can jump right in with fixing bugs themselves.

We regularly hold Ubuntu Bug Days, where people from all over chip in and focus on a particular area. But don't feel like you have to wait. Just jump right in!

What is a bug?

When we talk about Bugs, we're discussing faults or errors in the software. They're errors because the software claims to do certain things but then doesn't.

For instance, if a program suddenly disappears, that's a bug. Or if a program is supposed to play music, but doesn't make a sound, that's a bug. Or if some text is translated incorrectly, that's also a bug.

Some things aren't bugs, but are missing features that should be reasonably included. There isn't a bright line that you can draw between bugs and missing features, but here's a guideline: if it's a problem that would have many details to address, it's likely to be a feature. For example, the inability to write files safely to a modern Windows partition is a missing feature. The inability to write files safely to a ReiserFS partition would be a bug.

Another way of distinguishing a bug is if it's a regression. That means that something used to work, and now doesn't any more. We try fairly hard to get these identified early, because regressions represent a reduction in functionality.

Bug triage

Bug triage is an essential part of Ubuntu's development.

Triaging bugs consists of several things:

  • Responding to new bugs as they are filed.
  • Ensuring that new bugs have all the necessary information.
  • Assigning bugs to the proper package.
  • Confirming bug reports by trying to reproduce them.
  • Setting the priority of bugs reports.
  • Searching for and marking duplicates in the bug tracking system.
  • Sending bugs to their upstream authors, when applicable.
  • Cross-referencing bugs from other distributions.
  • Expiring old bugs.

However, you don't need to do all of those things to help! Recreating a bug and setting the status to Confirmed is enough.

Bug triage is an excellent way to start helping out. You get to learn a lot about Ubuntu, its available packages, its infrastructure, and you get a feel for the development pulse.

You can learn how to triage bugs and chip in, just see the Bugs/Triage page.

Joining the team

The people who work on triaging bugs in Ubuntu are called the Ubuntu BugSquad. Check out the BugSquad/GettingInvolved page to learn how to join.

You can almost always find members of the Bug Squad in #ubuntu-bugs on the freenode IRC server who will be happy to answer any questions you have.

Fixing bugs

If you have an interest in delving deep into bugs, we'd love to have you help fix bugs. Each package you install in Ubuntu gets built from a source package. Each source package has a page devoted to its bugs.

For instance, the bug page for the hello package is at: https://launchpad.net/ubuntu/+source/hello/+bugs.

You don't have to know how to program to fix bugs, but it certainly helps! There are some simple things that anyone can do. For starters, many bugs involve typos or documentation problems, which anyone can fix. If you can write in another language, there are plenty of translation errors you can solve. For functionality problems, you can try to track down a fix by the upstream authors of a package. Or find a fix that was included in another distribution.

You can learn more about fixing bugs by reading the Bugs/HowToFix page. You can also practise in a safe environment with trivial bugs by joining the One Hundred Papercuts project.

Adopting a package

If you've got a keen interest in a particular source package, you can help out by adopting it. This means that you want to act as a liaison between Ubuntu and the people who wrote the package that we include in the distribution.

This involves developing a relationship with the people who work on this software: developers, users, and other members of the community. You can quickly become an expert by triaging bugs associated with this package and even fixing some of them.

You can learn more about doing this by consulting the BugSquad/AdoptPackage page.

See also


CategoryBugSquad

HelpingWithBugs (last edited 2016-05-05 05:07:48 by es20490446e)