Changes

Jump to navigation Jump to search
m
add category
Line 1: Line 1: −
{{WIP box}}
  −
   
'''The importance of Bugs and Bugzilla'''
 
'''The importance of Bugs and Bugzilla'''
 +
<blockquote style="float: right;">
 +
[[File:Bugzilla-ayb.png|250px]]
 +
</blockquote>
    
==Bugzilla==
 
==Bugzilla==
Line 8: Line 9:     
==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 count, all that counts is that you report it.
+
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.
      Line 16: Line 17:  
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.
 
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.
   −
==Track development and considerations==
+
 
 +
==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.
      −
==Assist development==
+
==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 38: Line 40:  
==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]]

Navigation menu