Changes in ReportingBugs
Editor Comment
formatting fixes
Revision Differences of Revision 4
# Reporting Bugs ¶¶
## For Widelands ¶
¶
The link in the bottom of this section is for bugs in the game itself. Do **not** use it for the website. ¶
¶
### How can it be reproduced? ¶
¶
Describe step by step how to reproduce the bug. If it only happens when loading a certain file, attach that file to the report. ¶
¶
### Is it a regression? ¶
¶
A regression is a bug that did not exist in some previous version. When reporting a regresssion you should tell which version was the last where the bug is not reproducible and which revision is the first where it is reproducible. To find out, use SVN and interval halving. Here is an example: ¶
¶
Suppose you have a SVN checkout (called widelands) at revision 800 and find a bug: ¶
¶
¶
p/widelands> cd .. ¶
p> cp -r widelands widelands-400 ¶
p> cd widelands-400 ¶
p/widelands-400> svn up -r 400 ¶
p/widelands-400> scons ¶
p/widelands-400> ./widelands ¶
¶
¶
¶
Now you try if the bug is there. Suppose you find out that revision 400 is free from the bug. Then you do: ¶
¶
¶
p/widelands-400> cd .. ¶
p/> cp -r widelands-400 widelands-600 ¶
p/> cd widelands-600 ¶
p/widelands-600> svn up -r 600 ¶
p/widelands-600> scons ¶
p/widelands-600> ./widelands ¶
¶
¶
Now you try if the bug is there. Suppose you find out that revision 600 is free from the bug. Then you do: ¶
¶
¶
p/widelands-600> cd .. ¶
p/> mv widelands-400 widelands-700 ¶
p/> cd widelands-700 ¶
p/widelands-700> svn up -r 700 ¶
p/widelands-700> scons ¶
p/widelands-700> ./widelands ¶
¶
¶
Now you try if the bug is there. Suppose you find out that revision 700 has the bug. Then you do: ¶
¶
¶
p/widelands-700> cd .. ¶
p/> cp -r widelands-600 widelands-650 ¶
p/> cd widelands-650 ¶
p/widelands-650> svn up -r 650 ¶
p/widelands-650> scons ¶
p/widelands-650> ./widelands ¶
¶
Now you try if the bug is there. Suppose you find out that revision 650 is free from the bug. Then you do: ¶
¶
¶
p/widelands-650> cd .. ¶
p/> mv widelands-600 widelands-675 ¶
p/> cd widelands-675 ¶
p/widelands-650> svn up -r 675 ¶
p/widelands-650> scons ¶
p/widelands-650> ./widelands ¶
¶
¶
Now you try if the bug is there. Suppose you find out that revision 675 has the bug. Then you know that the bug appeared somewhere between revision 650 and 675. You continue to narrow the interval as much as possible. You could for example find out that the bug did not happen with revision 664 but with revision 665. This is what you should report. The developers can then do something like _svn diff -r 664:665|kompare -_ and _svn log -r 665_ to start searching for the cause of the bug. ¶
¶
Sometimes you will get a revision that you can not test because it can not be built or it crashes before you can get to the point where your bug happens. Then try another revision. This can of course also be the case for revisions close to where the bug appeared. Then you may have to report something like this: ¶
¶
* Revision 1134 was the last where the bug was not reproducible. ¶
* Revision 1135 to 1137 were not build
* Revision 1138 ended immediately with "Segmentation fault". ¶
* Revision 1139 is the first revision where the bug happens. ¶
¶
Sometimes when trying an old revision with a recent compiler, it will not be build
¶
If a bug is reproducible and is a regression, it will almost certainly be fixed relatively soon. ¶
¶
### Where to report ¶
¶
The bug-tracker is at [Sourceforge](https://sourceforge.net/tracker/?group_id=40163&atid=427221). ¶
¶
¶
## For the Website ¶
¶
Use the link after, for reporting bugs from the website, and **only** from the website. Remember - to fix a bug, we need to know how can it be reproduced, where (in what part of the website) it happens and if it's a problem with style (look) of the page, what browser do you use. ¶
¶
### Where to report ¶
¶
The bug-tracker for the website is at [Launchpad](https://bugs.launchpad.net/widelands-website).