Reporting bug guidelines

From ArchWiki
Revision as of 13:58, 7 May 2008 by Chicha (Talk | contribs) (First Draft with the main chapters)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Tango-document-new.pngThis article is a stub.Tango-document-new.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Reporting bug guidelines#)

Introduction

Opening (and closing) bug reports on Arch's Bug Tracking System is one of the possible way to help the community. However if this is done badly it can turn out in being a pain instead of being usefull : When too much bugs are badly reported the community and the developers loose a lot of time asking for questions and closing invalid bug reports.

This document will guide any body wanting to help efficiently the community by reporting or hunting bugs.


Before Reporting

The work done before reporting is probably the most usefull part of the job. Unfortunatly few people take the time to do this work, they prefere others to do it for them...

However preparing a good bug report is not difficult and can be achieved by any body (beginner or developer). The following steps will help you preparing your bug report or feature request. They should be followed in the order they come.


Glossary

  • Upstream : Upstream is usually refered to as the community who developed a software packaged by Archlinux. It is the team who is responsible for creating, publishing and documenting a software. Archlinux can be refered to as upstream for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...


Looking for duplicates

If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the How to help section.


Here are a list of places to search for duplicates :


  • Arch's forum : most of the time you will find your bug and the related solution here.
  • Arch's Bug Tracking System : It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exists if people looked for duplicate before reporting a bug ...
  • Google or your favorite search engine : Search using your software name, version and a relevant part of the error message that came out if any.
  • Upstream Forum, Mailing List and Bug Tracker : Look directly at the source of your problem ! Some bugs may have already been reported to the software developers, and even some bug may have been already fixed in the development version. That is why it is important to look for closed bugs as well as new bugs in upstream 's bug tracker.
  • Other distro forums : The Free Software community is wide, and other people than archers may have good idea too! You might have a look at Gentoo's forums (my favorite), Fedora forums and Ubuntu forums. If you know some other source of usefull information feel free to add them here.


Bug or Feature ?

Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is a bug or a feature :

  • A bug is something that should work but does not.
  • A feature is something a software does or would does if somebody code it.


Upstream or Arch ?

This is an important question. If arch is not responsible for a bug, there is no point at reporting the bug to Arch. At most post something in the forum with a link to relevant information from upstream, so that people can cope with the bug.

By reporting bugs upstream not only you will help archers and Arch developers, but also you will help other people in the Free Software Community.


So what is Archlinux responsible for ?

  • Arch own projects : Pacman, AUR, Initscripts, Arch Websites ... If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the URL.
  • Packaging : packaging basically consist on fetching the source code upstream, compiling it with relevant options, make sure the package will be installed correctly on an Arch system, make sure the main functionalities of a package work. Packaging at Arch does not consist on adding new functionalities or patches for existing bugs, it is upstream 's work.


If a bug/feature is not under Arch's responsibility report it upstream. See also Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug.


Reasons for not being a bug

  • Something you would like a software to do, whereas it is said nowhere that it does. In short : a new feature.

Reasons for not being a feature

Gather usefull information

Opening a Bug

Creating an account

Projects and Categories

Severity

Including Relevant Information

Following a Bug

Voting and Watching

Answering additional information requests

Closing when solved

Bug Hunting

Where to look ?

How to help

Candidates for closure

Duplicates

Reproducing a bug

Asking for more information

Reporting upstream

Bug Squashing Day

Bug Squashing Day