HelpingWithBugs

Differences between revisions 25 and 26
Revision 25 as of 2006-09-01 19:55:10
Size: 2535
Editor: ottawa-hs-206-191-33-252
Comment: Wikify
Revision 26 as of 2006-09-20 07:09:11
Size: 4960
Editor: ottawa-hs-64-26-167-8
Comment: Rewrite to give a better introduction
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
So, you want to help fix bugs in Ubuntu? Great! The good news is, there are plenty of ways that you can help! 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.
Line 3: Line 3:
'''If you want information about filing bugs, see ReportingBugs''' Which is we're very happy that you want to help with bugs.
Line 5: Line 5:
On this page we provide you with further links and suggestions of how to get started "helping with bugs". '''If you want information about filing bugs, please see ReportingBugs'''
Line 7: Line 7:
= Documentation = 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 ["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!

[[TableOfContents]]

= Bugs =

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.

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 parition 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 are bad news.

= Joining the team =

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

= 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 infrasture. 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.

= Fixing bugs =

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.

For instance, the bug page for the {{{hello}}} package is at: [https://launchpad.net/distros/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.

= Adopting a package =

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 liason between Ubuntu and the people who wrote the package that we include.

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 AdoptingPackages page.

= See also =
Line 17: Line 72:

= What is Bug Triage? =

{{{
From Jargon File (4.3.1, 29 Jun 2001) [jargon]:

  bug n. An unwanted and unintended property of a program or piece of
     hardware, esp. one that causes it to malfunction. Antonym of {feature}.
     Examples: "There's a bug in the editor: it writes things out backwards."
     "The system crashed because of a hardware bug." "Fred is a winner, but
     he has a few bugs" (i.e., Fred is a good guy, but he has a few
     personality problems).

  [..]
  
From WordNet (r) 2.0 [wn]:

  triage
       n : sorting and allocating aid on the basis of need for or
           likely benefit from medical treatment or food
}}}


Bug Triage consists of
 * finding duplicates of bugs
 * trying to confirm bugs
 * getting more information from the reporter
 * trying to find patches from the upstream developers
 * finding an appropriate upstream bug report to follow up
 * or forwarding the issue upstream.

It's an excellent way to help out Ubuntu.
 * You learn a lot about Ubuntu and its infrastructure.
 * You help maintain an overview over bug reports.
 * You help identify problems and fix them.
 * You even might enjoy it and get to know nice people from the [BugSquad]

= Triaging =
Line 59: Line 75:
= Other Resources =
 * [http://tygier.co.uk/bugs/stats Launchpad stats from ssam]

Due to moving home from uni, these will not be updated over the next few weeks. I can give the scripts and collected data to anyone who has an always on machine -- SamTygier

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 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 ["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!

TableOfContents

Bugs

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.

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 parition 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 are bad news.

Joining the team

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

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 infrasture. 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.

Fixing bugs

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.

For instance, the bug page for the hello package is at: [https://launchpad.net/distros/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.

Adopting a package

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 liason between Ubuntu and the people who wrote the package that we include.

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 AdoptingPackages page.

See also

  • ["UbuntuBugDay"] - start here! Smile :-)

  • ["Bugs/HowToApproachBugs"] will show you how to begin and which steps are to be followed as a bug squasher
  • ["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


[:CategoryBugSquad]

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