Difference between revisions of "Why you should use Bugzilla"
m (add category) |
|||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
'''The importance of Bugs and Bugzilla''' | '''The importance of Bugs and Bugzilla''' | ||
| + | <blockquote style="float: right;"> | ||
| + | [[File:Bugzilla-ayb.png|250px]] | ||
| + | </blockquote> | ||
==Bugzilla== | ==Bugzilla== | ||
| − | Bugzilla is not the easiest thing to use to start with and it takes a little practice, but there are some ''extremely'' good reasons why we use it to improve and track the development of Koozali SME Server. | + | [http://bugs.contribs.org/ Bugzilla] is not the easiest thing to use to start with and it takes a little practice, but there are some ''extremely'' good reasons why we use it to improve and track the development of Koozali SME Server. |
==When to raise a bug== | ==When to raise a bug== | ||
| − | When you've read the administration manual and and you experience something that does not work as it should, you should raise a bug. Your skill level does not | + | When you've read the administration manual and and you experience something that does not work as you think it should, you should raise a bug. Your skill level does not matter. All that matters is that you report it. |
| − | In Bugzilla you will only usually get the experienced developers. They tend to cut to the chase. They are usually methodical, logical, and really know their code. They won't waste your time on chasing wild geese. Many experienced people that follow Bugzilla can usually tell at a glance if it is something that needs urgent attention or not (triage the bug), and if it is a problem with the core system. Better they close it and say ask in the forums than it be posted in the forums and missed..... Ultimately they are better judges of whether something is a bug or not. | + | In Bugzilla you will only usually get the experienced developers. They tend to cut to the chase. They are usually methodical, logical, and really know their code. They won't waste your time on chasing wild geese. Many experienced people that follow Bugzilla can usually tell at a glance if it is something that needs urgent attention or not (triage the bug), and if it is a problem with the core system. Better they close it and say ask in the forums than it be posted in the forums and missed..... Ultimately they are better judges of whether something is a bug or not. |
==Developers attention== | ==Developers attention== | ||
| − | First and foremost is that the developers do not always read the forums, so a problem that may be a bug would not get seen/flagged by them immediately. (Yes, they do pop in to the forums as and when they can, but the first things they look at are bugs.) However, Bugzilla '' | + | First and foremost is that the developers do not always read the forums, so a problem that may be a bug would not get seen/flagged by them immediately. (Yes, they do pop in to the forums as and when they can, but the first things they look at are bugs.) However, Bugzilla ''pushes'' an email with any Bugzilla changes to the developers ''pro actively''. Developers can also set a variety of statuses on bugs to indicate their progress. They get notified if there is a change of status. You can also do things like set one as blocking say a release of an ISO - i.e you can't build and release an ISO until bug x, y, or z is fixed. |
| − | == | + | ==Tracking development and other considerations== |
Next Bugzilla also provides a record of problems, fixes and any considerations, that can easily be referred too later. If developers make a fix and introduce a regression we can see exactly what went on, the thought processes, the code, verifications etc. It gives a level of quality assurance to the process. It also means that a new developer can easily read through and understand what has gone on. | Next Bugzilla also provides a record of problems, fixes and any considerations, that can easily be referred too later. If developers make a fix and introduce a regression we can see exactly what went on, the thought processes, the code, verifications etc. It gives a level of quality assurance to the process. It also means that a new developer can easily read through and understand what has gone on. | ||
| − | == | + | ==Assisting development== |
Bugzilla is also closely tied to the Koozali SME Server automatic buildsystem. Developers can easily flip patches into the buildsystem and it makes their already busy lives much easier. The more time we save them, the more stuff they can fix. The are used to bugzilla and can get through bugs and bug reports at a much higher rate than they can in forums. | Bugzilla is also closely tied to the Koozali SME Server automatic buildsystem. Developers can easily flip patches into the buildsystem and it makes their already busy lives much easier. The more time we save them, the more stuff they can fix. The are used to bugzilla and can get through bugs and bug reports at a much higher rate than they can in forums. | ||
| Line 35: | Line 36: | ||
* http://www.chiark.greenend.org.uk/~sgtatham/bugs.html | * http://www.chiark.greenend.org.uk/~sgtatham/bugs.html | ||
* http://www.bugzilla.org/docs/4.0/en/html/using.html | * http://www.bugzilla.org/docs/4.0/en/html/using.html | ||
| + | |||
==Help== | ==Help== | ||
If you need help then please ask in our [http://forums.contribs.org/index.php?board=16.0 General Discussions] forum. We are more than happy to help people learn how to use these tools as it benefits us all. | If you need help then please ask in our [http://forums.contribs.org/index.php?board=16.0 General Discussions] forum. We are more than happy to help people learn how to use these tools as it benefits us all. | ||
| + | |||
| + | |||
| + | [[Category:SME Server:Bugzilla]] | ||
Latest revision as of 16:23, 5 January 2015
The importance of Bugs and Bugzilla
Bugzilla
Bugzilla is not the easiest thing to use to start with and it takes a little practice, but there are some extremely good reasons why we use it to improve and track the development of Koozali SME Server.
When to raise a bug
When you've read the administration manual and and you experience something that does not work as you think it should, you should raise a bug. Your skill level does not matter. All that matters is that you report it.
In Bugzilla you will only usually get the experienced developers. They tend to cut to the chase. They are usually methodical, logical, and really know their code. They won't waste your time on chasing wild geese. Many experienced people that follow Bugzilla can usually tell at a glance if it is something that needs urgent attention or not (triage the bug), and if it is a problem with the core system. Better they close it and say ask in the forums than it be posted in the forums and missed..... Ultimately they are better judges of whether something is a bug or not.
Developers attention
First and foremost is that the developers do not always read the forums, so a problem that may be a bug would not get seen/flagged by them immediately. (Yes, they do pop in to the forums as and when they can, but the first things they look at are bugs.) However, Bugzilla pushes an email with any Bugzilla changes to the developers pro actively. Developers can also set a variety of statuses on bugs to indicate their progress. They get notified if there is a change of status. You can also do things like set one as blocking say a release of an ISO - i.e you can't build and release an ISO until bug x, y, or z is fixed.
Tracking development and other considerations
Next Bugzilla also provides a record of problems, fixes and any considerations, that can easily be referred too later. If developers make a fix and introduce a regression we can see exactly what went on, the thought processes, the code, verifications etc. It gives a level of quality assurance to the process. It also means that a new developer can easily read through and understand what has gone on.
Assisting development
Bugzilla is also closely tied to the Koozali SME Server automatic buildsystem. Developers can easily flip patches into the buildsystem and it makes their already busy lives much easier. The more time we save them, the more stuff they can fix. The are used to bugzilla and can get through bugs and bug reports at a much higher rate than they can in forums.
Forums
Forums can become a free for all if you are not careful, with lots of well meaning but not necessarily very good people offering all sorts of advice (have a look in lots of Windows help forums to see what I mean !) A bug concentrates the thought processes for all concerned. Next to this, a forum post can be altered and even deleted by the poster, possibly losing valuable information. Bugzilla on the other hand keeps a record of all changes and comments as originally entered, making it much more trustworthy as s correct source of information.
References
Here is some useful further reading.
- http://wiki.contribs.org/Bugzilla_Help
- http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
- http://www.bugzilla.org/docs/4.0/en/html/using.html
Help
If you need help then please ask in our General Discussions forum. We are more than happy to help people learn how to use these tools as it benefits us all.
