\begin{itemize}
\item Kern is the project manager, but prefers not to be a "gate keeper".
+ This means that the developers are expected to be self-motivated,
+ and once they have experience submit directly to the SVN. However,
+ it is a good idea to have your patches reviewed prior to submitting,
+ and it is a bad idea to submit monster patches because no one will
+ be able to properly review them. See below for more details on this.
\item There are growing numbers of contributions (very good).
debugging, documentation, and maintenance responsibilities.
\end{itemize}
+\subsection*{Patches for Released Versions}
+\index{Patches for Released Versions}
+\addcontentsline{toc}{subsection}{Patches for Released Versions}
+If you fix a bug in a released version, you should, unless it is
+an absolutely trivial bug, create and release a patch file for the
+bug. The procedure is as follows:
+
+Fix the bug in the branch and in the trunk.
+
+Make a patch file for the branch and add the branch patch to
+the patches directory in both the branch and the trunk.
+The name should be 2.2.4-xxx.patch where xxx is unique, in this case it can
+be "restore", e.g. 2.2.4-restore.patch. Add to the top of the
+file a brief description and instructions for applying it -- see for example
+2.2.4-poll-mount.patch. The best way to create the patch file is as
+follows:
+
+\begin{verbatim}
+ (edit) 2.2.4-restore.patch
+ (input description)
+ (end edit)
+
+ svn diff >>2.2.4-restore.patch
+\end{verbatim}
+
+check to make sure no extra junk got put into the patch file (i.e.
+it should have the patch for that bug only).
+
+If there is not a bug report on the problem, create one, then add the
+patch to the bug report.
+
+Uthen upload it to the 2.2.x release of bacula-patches.
+
+So, end the end, the patch file is:
+\begin{itemize}
+\item Attached to the bug report
+
+\item In Branch-2.2/bacula/patches/...
+
+\item In the trunk
+
+\item Loaded on Source Forge bacula-patches 2.2.x release. When
+ you add it, click on the check box to send an Email so that all the
+ users that are monitoring SF patches get notified.
+\end{itemize}
+
+
\subsection*{SVN Usage}
\index{SVN Usage}
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
-messages reformatted in a memory buffer. Mmsg() is the way to do this.
+essages reformatted in a memory buffer. Mmsg() is the way to do this.
+Kern;;;2007/9/14;;;14:30
+Bacula version 2.2.4 Release
+This version of Bacula is a minor bug release to version 2.2.3.
+It contains the following fixes:
+
+- Possible fix for authorization problems bug #953.
+- Possible fix for bug #908.
+- Add waits to multiple exit detection code to try to force pid
+ file to always be deleted.
+- Restore good dev.tar.gz to rescue set appropriate binary property.
+ This fixes bug #950.
+- Fix seg fault in error exit of acquire_for_read after unsuccessfully
+ trying to switch drives by checking for blocking before unblocking.
+ Fixes bug #906.
+- Cancel storage daemon in all cases where FD reports error. This
+ should fix virtually all cases of bug #920 and will ensure that Devices
+ are released as soon as possible.
+- Fix error message that was clobbered when Dir tells SD it does not
+ have write permission on Volume. This should fix a minor point
+ in bug #942, but not the main problem.
+- Fix migration code to get correct Volume name with multiple volumes
+ by skipping |. Fixes bug #936.
+- Implement patch supplied by Landon to fix bug #944 where using
+ TLS with bconsole uses 99+% of the CPU.
+- Fix bug #946 about "bacula-dir -t" which doesn't works
+ as expected.
+- Using "m" in bconsole will show messages as in prior versions
+ and not memory usage.
+
+- Note, you need GTK >= 2.10 to be able to link the Tray Monitor
+ program.
+;;;
Kern;;;2007/9/9;;;14:30
I regret to announce that there is a rather serious bug in Bacula.
projects / bacula / docs / commitdiff