Add section on bug reporting handling

diff --git a/docs/manuals/en/developers/generaldevel.tex b/docs/manuals/en/developers/generaldevel.tex
index 18090067a42c2446b60b260398b78de1472f9377..37d55ee9aaef28f55961192c34dc5003794ccfc0 100644 (file)
--- a/docs/manuals/en/developers/generaldevel.tex
+++ b/docs/manuals/en/developers/generaldevel.tex
@@ -7,10 +7,6 @@
 \index{Notes!Bacula Developer}
 \addcontentsline{toc}{section}{Bacula Developer Notes}
 
-\section{General}
-\index{General}
-\addcontentsline{toc}{subsection}{General}
-
 This document is intended mostly for developers and describes the the general
 framework of making Bacula source changes. 
 
@@ -133,10 +129,9 @@ The instructions for filling out this agreement are also at:
 It should be filled out, then sent to:
 
 \begin{verbatim}
-     Free Software Foundation Europe
-     Freedom Task Force
-     Sumatrastrasse 25
-     8006 Zürich
+     Kern Sibbald
+     Cotes-de-Montmoiret 9
+     1012 Lausanne
      Switzerland
 \end{verbatim}
 
@@ -145,7 +140,6 @@ registered office mentioned in the document.  When you send in such a
 complete document, please notify me: kern at sibbald dot com.
 
 
-
 \section{The Development Cycle}
 \index{Developement Cycle}
 \index{Cycle!Developement}
@@ -455,8 +449,8 @@ Many of the Subversion (svn) commands are almost identical to those that
 you have used for cvs, but some (such as a checkout) can have surprising
 results, so you should take a careful look at the documentation. 
 
-Robert has kindly provided the following documentation on the new
-svn repository and how to use it:
+The following documentation on the new
+svn repository will help you know how to use it:
 
 Here is the list of branches:
 \begin{verbatim}
@@ -725,34 +719,6 @@ you have little to worry about.
 \index{Subversion (svn) Resources}
 \addcontentsline{toc}{subsection}{Subversion Resources}
 
-\begin{verbatim}
-cvs2svn Statistics:
-------------------
-Total CVS Files:              3286
-Total CVS Revisions:         28924
-Total Unique Tags:              63
-Total Unique Branches:          11
-CVS Repos Size in KB:       232421
-Total SVN Commits:            4116
-First Revision Date:    Tue Apr 23 12:42:57 2002
-Last Revision Date:     Tue Feb  6 06:37:57 2007
-\end{verbatim}
-
-The new Subversion repository size on Robert's machine:
-
-\begin{verbatim}
-4.0K    bacula-tst/dav
-12K     bacula-tst/locks
-40K     bacula-tst/hooks
-16K     bacula-tst/conf
-190M    bacula-tst/db/revs
-17M     bacula-tst/db/revprops
-4.0K    bacula-tst/db/transactions
-206M    bacula-tst/db
-206M    bacula-tst
-\end{verbatim}
-
-
 Main Subversion Web Page
 \elink{http://subversion.tigris.org}{http://subversion.tigris.org}
 
@@ -1401,3 +1367,60 @@ they are used in low level routines such as the low level device file dev.c in
 the Storage daemon or in the low level Catalog routines. These routines do not
 generally have access to the Job Control Record and so they return error
 essages reformatted in a memory buffer. Mmsg() is the way to do this. 
+
+\subsection{Bugs Database}
+\index{Database!Bugs}
+\index{Bugs Database}
+\addcontentsline{toc}{subsubsection}{Bugs Database}
+We have a bugs database which is at:
+\elink{http://bugs.bacula.org}{http://bugs.bacula.org}, and as
+a developer you will need to respond to bugs, perhaps bugs in general 
+if you have time, otherwise just bugs that correspond to code that
+you wrote.
+
+If you need to answer bugs, please be sure to ask the Project Manager
+(currently Kern) to give you Developer access to the bugs database. This
+allows you to modify statuses and close bugs.
+
+The first thing is if you want to take over a bug, rather than just make a
+note, you should assign the bug to yourself. This helps other developers
+know that you are the principal person to deal with the bug.  You can do so
+by going into the bug and clicking on the {\bf Update Issue} button. Then
+you simply go to the {\bf Assigned To} box and select your name from the
+drop down box.  To actually update it you must click on the {\bf Update
+Information} button a bit further down on the screen, but if you have other
+things to do such as add a Note, you might wait before clicking on the {\bf
+Update Information} button.
+
+Generally, we set the {\bf Status} field to either acknowledged, confirmed,
+or feedback when we first start working on the bug.  Feedback is set when
+we expect that the user should give us more information.
+
+Normally, once you are reasonably sure that the bug is fixed, and a patch
+is made and attached to the bug report, and/or in the SVN, you can close
+the bug.  If you want the user to test the patch, then leave the bug open,
+otherwise close it and set {\bf Resolution} to {\bf Fixed}.  We generally
+close bug reports rather quickly, even without confirmation, especially if
+we have run tests and can see that for us the problem is fixed.  However,
+in doing so, it avoids misunderstandings if you leave a note while you are
+closing the bug that says something to the following effect:
+We are closing this bug because ...   If for some reason, it does not fix
+your problem, please feel free to reopen it, or to open a new bug report
+describing the problem".
+
+We do not recommend that you attempt to edit any of the bug notes that have
+been submitted, nor to delete them or make them private.  In fact, if
+someone accidentally makes a bug note private, you should ask the reason
+and if at all possible (with his agreement) make the bug note public.  
+
+If the user has not properly filled in most of the important fields
+(platorm, OS, Product Version, ...) please do not hesitate to politely ask
+him.  Also, if the bug report is a request for a new feature, please
+politely send the user to the Feature Request menu item on www.bacula.org.
+The same applies to a support request (we answer only bugs), you might give
+the user a tip, but please politely refer him to the manual and the
+Getting Support page of www.bacula.org.
+
+
+
+