Bugtracker: Difference between revisions

From Shareaza Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
Bugtacker is a software which allow to control and manage reported bugs and future requests, so it is esential for organizing development work and preventing against "reported but forgotten bugs". Reports/problems/future requests are described in so called tickets which are managed like records in database. In fact the bugtracker is the database of tickets for continous development purposes joining, structurlising and prioritising efforts of betatesters, developers and common users.
{{Language}}


Before you use bugtracer to report your problem you must read [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] Read it please just to report bugs effectively. You will save lots of nerves and time, yours and ours. Very recommended to make life and development easier and more happy. On linked site translation to many languages are available: English | Português | 简体中文 | Česky | Dansk | Deutsch | Español | Français | Magyar | Italiano | Nederlands | Polski | Русский | 繁體中文 .  
A '''BugTacker''' is a software which allows to control and manage reported bugs and feature requests, which it is essential for organizing development work and preventing "reported but forgotten bugs". Reports/problems/feature requests are described in so called tickets which are managed like records in a database. In fact the BugTracker is the database of tickets for continuous development purposes,  joining, structuring and prioritizing efforts of beta testers, developers and common users.


Before you will create for the first time your own ticket with problem description, first read how other tickest has been writtten. It will help you to find out used convention, which implies from practise.  
Before you use our BugTracer (called {{trac|report|Trac}}) to report a problem, you should read about [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively]. This is important as it makes solving the reported problems much more easy and less work for out devs. You will save lots of nerves and time, yours and ours. Very recommended to make life and development easier and more happy.


Before you will create a new ticket check in existing tickets if anybody else has reported the same problem already. In such case you ought to add your confirmation, description, additional info to this ticket as next comment, so developer will have more info about problem gathered in one place. Many tickets about the same case are not helping, but disturbing as probability of accidental ommiting of important information is incereasing.  
Before you create a new ticket with a problem description  for the first time, first check also out how other tickets have been written. It will help you to find out the used convention, which implies from practice. Also, you should check whether there is already an existing tickets where anybody else has already reported the same problem as you are experiencing. In this case, you ought to add your confirmation, description, as well as additional info to this ticket as a new comment, so our developers get more detailed info about the problem gathered in one place. Many tickets about the same case are not helping, but disturbing as the probability of accidental omitting important information is increasing.  


In general the report in bugtracker ticket should be as informative, precise, short, easy to understand as possible. Otherwise is just useless.  
In general reports in BugTracker tickets should be as informative, precise, short and easy to understand as possible. Otherwise they are often just useless. Efforts to improve Shareaza can be only as successful as the quality of the bug reports. Please have this in mind, because we are an Open Source project and your mistakes in reports can kill your efforts and potentially useful ideas - give them a chance by writing good reports please.   


Efforts to perfect Shareaza can be only as succesfull as good are bug reports. Please have this in mind, because we are open source and your mistakes in reports can kill your efforts and potentialy usefull ideas - give them a chance by writting good reports please.  
Currently, we use {{trac|report|Trac}} as our BugTracker system, which is well integrated with SourceForge resources and the source repositories. This is why it is preferred by coding developers, but many users have problems with the integrated Trac Wiki interface, that's why we are using [[Main Page|MediaWiki]] (this Wiki) for help and support, while using Trac to submit bugs.


Currently as bugtracker is used {{trac|report|Trac}}, which is well integrated with SourceForge resources and depository so prefered by coding developers, but not friendly enough for common user due to ancient like interface. Anyway this is current official so take a deep breath and please report bugs there.
On our recently lost project domain, [http://shareaza.trillinux.org/bts/ Flyspray] (currently not officially used) was used as BugTracker and feature request tracker. After Will Ervin has devastated this and we lost the domain, not only the content of the old Wiki has been lost, but also most of the content of that BugTacker was lost and when migrating our project pages to SourceForge.net in 2009, {{trac|report|Trac}} has become the official BugTracker of our project.


At recently lost for project domain as bugtrucker was used [http://shareaza.trillinux.org/bts/ Flyspray] (currently not officially used) feature request tracker with asorted feature requests. After Will Ervin has devastated that lost domain also content of that bugtacker was lost and in 2009 the Track has become official bugtracker.
[[Category:External Links]]

Latest revision as of 17:19, 1 March 2010

  Languages:

[[::Bugtracker|English]] • [[::Bugtracker/de|Deutsch]] • [[::Bugtracker/es|Español]] • [[::Bugtracker/fr|Français]] • [[::Bugtracker/he|עברית]] • [[::Bugtracker/it|Italiano]] • [[::Bugtracker/nl|Nederlands]] • [[::Bugtracker/pl|Polski]] • [[::Bugtracker/pt|Português]] • [[::Bugtracker/ru|Русский]] • [[::Bugtracker/zh-hant|‪中文(繁體)]]

e

A BugTacker is a software which allows to control and manage reported bugs and feature requests, which it is essential for organizing development work and preventing "reported but forgotten bugs". Reports/problems/feature requests are described in so called tickets which are managed like records in a database. In fact the BugTracker is the database of tickets for continuous development purposes, joining, structuring and prioritizing efforts of beta testers, developers and common users.

Before you use our BugTracer (called Trac) to report a problem, you should read about How to Report Bugs Effectively. This is important as it makes solving the reported problems much more easy and less work for out devs. You will save lots of nerves and time, yours and ours. Very recommended to make life and development easier and more happy.

Before you create a new ticket with a problem description for the first time, first check also out how other tickets have been written. It will help you to find out the used convention, which implies from practice. Also, you should check whether there is already an existing tickets where anybody else has already reported the same problem as you are experiencing. In this case, you ought to add your confirmation, description, as well as additional info to this ticket as a new comment, so our developers get more detailed info about the problem gathered in one place. Many tickets about the same case are not helping, but disturbing as the probability of accidental omitting important information is increasing.

In general reports in BugTracker tickets should be as informative, precise, short and easy to understand as possible. Otherwise they are often just useless. Efforts to improve Shareaza can be only as successful as the quality of the bug reports. Please have this in mind, because we are an Open Source project and your mistakes in reports can kill your efforts and potentially useful ideas - give them a chance by writing good reports please.

Currently, we use Trac as our BugTracker system, which is well integrated with SourceForge resources and the source repositories. This is why it is preferred by coding developers, but many users have problems with the integrated Trac Wiki interface, that's why we are using MediaWiki (this Wiki) for help and support, while using Trac to submit bugs.

On our recently lost project domain, Flyspray (currently not officially used) was used as BugTracker and feature request tracker. After Will Ervin has devastated this and we lost the domain, not only the content of the old Wiki has been lost, but also most of the content of that BugTacker was lost and when migrating our project pages to SourceForge.net in 2009, Trac has become the official BugTracker of our project.