Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
contribute:bugs:start [2018/11/17 22:51] – Added link to git manual alexxconscontribute:bugs:start [2019/02/26 23:24] – [Fixing Bugs] alexxcons
Line 1: Line 1:
-====== Bug Reporting ======+====== Bug Reporting and Fixing======
  
 One of the most useful tasks that we rely on the community for is testing and reporting of bugs. Since Xfce runs on various platform and in a lot of different setups, testing all changes in every possible situation is an impossible task. As such we kindly ask users to assist in testing, and reporting all bugs they may find, using our [[https://bugzilla.xfce.org|bug tracker]]. One of the most useful tasks that we rely on the community for is testing and reporting of bugs. Since Xfce runs on various platform and in a lot of different setups, testing all changes in every possible situation is an impossible task. As such we kindly ask users to assist in testing, and reporting all bugs they may find, using our [[https://bugzilla.xfce.org|bug tracker]].
- 
-Once a bug has been found, the cause of the bug needs to be tracked down, and then (obviously) fixed. If you want to get involved in the actual development process of Xfce a great way to start is by solving bugs and attaching a patch file to the reported bug. ( "git format-patch" is the preferred way to create a patch file )   
- 
-If you are not familiar with git, possible [[contribute/dev/git/start|this short manual]] will help you to get started. 
- 
-=== Detailed Sections === 
- 
-[[:xfce:building]]\\ 
-How to compile Xfce from source to provide better debug information. 
-===== Feature Requests ===== 
- 
-Although the philosophy of Xfce is to find the correct balance between features and lightweight, it is still possible there are features you'd like to see in future releases. 
- 
-This right approach for larger changes is to discuss them on the mailing list first. You might think your idea is brilliant, but there is a high possibility other users. 
- 
-Afterwards a bug can be opened in the bug tracker and make sure the //Importance// is set to //normal// and //enhancement//. 
- 
-Obviously its also nice if you can write a patch that implements the feature, but its not a necessity. 
  
 ===== Crashes ===== ===== Crashes =====
Line 55: Line 37:
   * [[http://en.opensuse.org/openSUSE:Bugreport_application_crashed]]   * [[http://en.opensuse.org/openSUSE:Bugreport_application_crashed]]
   * [[https://wiki.sabayon.org/?title=Debugging_Symbols_-_splitdebug]]   * [[https://wiki.sabayon.org/?title=Debugging_Symbols_-_splitdebug]]
 +
 +===== Fixing Bugs =====
 +
 +Once a bug has been found, the cause of the bug needs to be tracked down, and then (obviously) fixed. If you want to get involved in the actual development process of Xfce a great way to start is by solving bugs and attaching a patch file to the reported bug. ( "git format-patch" is the preferred way to create a patch file ) 
 +
 +Not familiar with git? [[contribute/dev/git/start|This manual]] will help you to get started. 
 +
 +To get started, best read our [[contribute/dev/coding/example|beginners example on how to fix a simple xfce bug]].
 +===== Feature Requests =====
 +
 +Although the philosophy of Xfce is to find the correct balance between features and lightweight, it is still possible to request new features.
 +
 +The right approach for larger changes is to discuss them on the mailing list, or on #xfce-dev (on freenode) first. You might think your idea is brilliant, but there is a high possibility that there are major downsides.
 +
 +Afterwards a bug can be opened in the bug tracker. Make sure the //Importance// is set to //normal// and //enhancement//.
 +
 +Obviously it would benice if you could write a patch that implements the new feature.