Reporting bug guidelines
- 1 Introduction
- 2 Before Reporting
- 3 Opening a Bug
- 4 Following a Bug
- 5 Bug Hunting
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.
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.
- 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.