Contributions from programmers are broken into two groups. The first are
contributions that are aids and not essential to Bacula. In general, these
will be scripts or will go into and examples or contributions directory.
+For these kinds of non-essential contributions there is no obligation to do
+a copyright assignment as described below. However, a copyright assignment
+would still be appreciated.
The second class of contributions are those which will be integrated with
Bacula and become an essential part. Within this class of contributions, there
Subject to the copyright assignment described below, your patches should be
sent in {\bf diff -u} format relative to the current contents of the Source
-Forge CVS, which is the easiest for me to understand. If you have checked
-out the source with CVS, you can get a diff using:
+Forge CVS, which is the easiest to understand and integrate.
+If you have checked out the source with CVS, you can get a diff using:
\begin{verbatim}
-cvs diff -u \lt{}change.patch
+cvs diff -u > change.patch
\end{verbatim}
-If you plan on doing
-significant development work over a period of time, after having your first
-patch reviewed and approved, you will be eligible for having developer CVS access so
-that you can commit your changes directly to the CVS repository. To do so, you
-will need a userid on Source Forge.
+If you plan on doing significant development work over a period of time,
+after having your first patch reviewed and approved, you will be eligible
+for having developer CVS access so that you can commit your changes
+directly to the CVS repository. To do so, you will need a userid on Source
+Forge.
\subsubsection*{Copyrights}
\index{Copyrights}
\addcontentsline{toc}{subsubsection}{Copyrights}
-To avoid future problems concerning changing licensing or copyrights, all code
-contributions more than a hand full of lines must be in the Public Domain or
-have the copyright assigned to Kern Sibbald as in the current code. Note,
-prior to November 2004, the code was copyrighted by Kern Sibbald and John
-Walker.
-
-Your name should be clearly indicated as the author of the code, and you must
-be extremely careful not to violate any copyrights or use other people's code
-without acknowledging it. The purpose of this requirement is to avoid future
-copyright, patent, or intellectual property problems. To understand on
-possible source of future problems, please examine the difficulties Mozilla is
-(was?) having finding previous contributors at
-\elink{
-http://www.mozilla.org/MPL/missing.html}
+To avoid future problems concerning changing licensing or copyrights, all
+code contributions more than a hand full of lines must be in the Public
+Domain or have the copyright assigned to Kern Sibbald as in the current
+code. Note, prior to November 2004, the code was copyrighted by Kern
+Sibbald and John Walker.
+
+Your name should be clearly indicated as the author of the code, and you
+must be extremely careful not to violate any copyrights or use other
+people's code without acknowledging it. The purpose of this requirement is
+to avoid future copyright, patent, or intellectual property problems. To
+understand on possible source of future problems, please examine the
+difficulties Mozilla is (was?) having finding previous contributors at
+\elink{ http://www.mozilla.org/MPL/missing.html}
{http://www.mozilla.org/MPL/missing.html}. The other important issue is to
avoid copyright, patent, or intellectual property violations as are currently
(May 2003) being claimed by SCO against IBM.
Although the copyright will be held by Kern, each developer is expected to
-indicate that he wrote and/or modified a particular module (or file) and any
-other sources. The copyright assignment may seem a bit unusual, but in
-reality, it is not. Most large projects require this. In fact, the paperwork
-associated with making contributions to the Free Software Foundation, was for
-me unsurmountable.
-
-If you have any doubts about this, please don't hesitate to ask. Our (John and
-my) track records with Autodesk are easily available; early
-programmers/founders/contributors and later employees had substantial shares
-of the company, and no one founder had a controlling part of the company. Even
-though Microsoft created many millionaires among early employees, the politics
-of Autodesk (during our time at the helm) is in stark contrast to Microsoft
-where the majority of the company is still tightly held among a few.
+indicate that he wrote and/or modified a particular module (or file) and
+any other sources. The copyright assignment may seem a bit unusual, but in
+reality, it is not. Most large projects require this. In fact, the
+paperwork associated with making contributions to the Free Software
+Foundation, was for me unsurmountable, so hopefully the rather
+simplified procedure we have will not create any difficulties for
+you.
+
+If you have any doubts about this, please don't hesitate to ask. The
+objective is to assure the long term servival of the Bacula project. There
+is no consideration of personal gain in this request. Our (John and my)
+track records with Autodesk are easily available; early
+programmers/founders/contributors and later employees had substantial
+shares of the company, and no one founder had a controlling part of the
+company. Even though Microsoft created many millionaires among early
+employees, the politics of Autodesk (during our time at the helm) is in
+stark contrast to Microsoft where the majority of the company is still
+tightly held among a few.
Items not needing a copyright assignment are: most small changes,
enhancements, or bug fixes of 5-10 lines of code, and documentation.
Since this is not a commercial enterprise, and I prefer to believe in
everyone's good faith, developers can assign the copyright by explicitly
-acknowledging that they do so in their first submission. This is sufficient if
-the developer is independent, or an employee of a not-for-profit organization
-or a university. Any developer that wants to contribute and is employed by a
-company must get a copyright assignment from his employer. This is to avoid
-misunderstandings between the employee, the company, and the Bacula project.
+acknowledging that they do so in their first submission. This is
+sufficient if the developer is independent, or an employee of a
+not-for-profit organization or a university. Any developer who wants to
+contribute and is employed by a company must get a copyright assignment
+from his employer. This is to avoid misunderstandings between the
+employee, the company, and the Bacula project. A good number of
+companies have already followed this procedure.
\subsubsection*{Corporate Assignment Statement}
\index{Statement!Corporate Assignment}
Kern Sibbald
Address-to-be-given
+If you wish to retain the full rights to use the software you
+have contributed in different projects, this is not a problem. Just
+request a perpetual non-exclusive license before sending in your
+copyright assignment.
+
\subsection*{Basic CVS Usage}
\index{Basic CVS Usage}
\index{CVS}
To get the source for a project, you must check it out ("checkout"), which
you do usually once.
+\subsubsection*{Public CVS Access}
+\index{Public CVS Access}
+\addcontentsline{toc}{subsubsection}{Public CVS Access}
+
The first time you checkout the code for each project, you will need to
-tell the cvs program where the CVS repository is. You do so by doing:
+tell the cvs program where the CVS repository is. The procedure for
+checking out code from the public CVS is:
+
+\begin{verbatim}
+cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula login
+\end{verbatim}
+Then when it prompts for the password for {\bf anonymous}, simply
+press the Enter key. The above command is necessary only once
+the very first time you login. Then enter the following command:
+
+\begin{verbatim}
+cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula co -P bacula
+\end{verbatim}
+
+The above will place the contents of the bacula module in a directory
+named {\bf bacula} in the current directory. This data will come
+from the public CVS, which typically runs 6 hours to a day behind the
+developer's CVS. Once you have created a copy of the CVS, you can use
+the commands listed below under the title CVS Usage.
+
+\subsubsection*{Developer CVS Access}
+\index{Developer CVS Access}
+\addcontentsline{toc}{subsubsection}{Developer CVS Access}
+
+If you are registered as a Bacula developer (contact Kern about this),
+you may access the developer's CVS using:
\begin{verbatim}
export CVS_RSH=ssh
where you replace \lt{}nnnn\gt{} by your Source Forge user name.
-Then do
+Then do:
\begin{verbatim}
cvs -z3 checkout -d <directory> bacula
to contain the Bacula source code. If you want the docs, replace the
word "bacula" on the above line by "docs" and be sure to put it in
a different directory. The -z3 just tells CVS to use compression during
-the transmission, which makes things go faster.
+the transmission, which makes things go faster. There is no need to
+do the anonymous login as is the case for non-developers.
The above command should generate output that looks a bit like the
following:
...
\end{verbatim}
+\subsubsection*{CVS Usage}
+\index{CVS Usage}
+\addcontentsline{toc}{subsubsection}{CVS Usage}
+
+The commands that follow with the exception of the {\bf commit}
+work the same whether you are accessing the public CVS or
+the developer's CVS.
Let's assume you used the name "bacula" for the directory, so your
command was:
number of new features will also be much the same providing that the
contributions continue to come -- and they show no signs of let up :-)
+\index{Feature Requests}
{\bf Feature Requests:} \\
In addition, I would like to "formalize" the feature requests a bit.
\index{When Implementing Incomplete Code}
\addcontentsline{toc}{subsubsection}{When Implementing Incomplete Code}
-Please identify all incomplete code with a comment that contains {\bf
-***FIXME***}, where there are three asterisks (*) before and after the word
+Please identify all incomplete code with a comment that contains
+
+\begin{verbatim}
+***FIXME***
+\end{verbatim}
+
+where there are three asterisks (*) before and after the word
FIXME (in capitals) and no intervening spaces. This is important as it allows
new programmers to easily recognize where things are partially implemented.
\addcontentsline{toc}{subsubsection}{Avoid if Possible}
\begin{itemize}
+\item Using {\bf void *} because this generally means that one must
+ using casting, and in C++ casting is rather ugly. It is OK to use
+ void * to pass structure address where the structure is not known
+ to the routines accepting the packet (typically callback routines).
+ However, declaring "void *buf" is a bad idea. Please use the
+ correct types whenever possible.
+\item Using undefined storage specifications such as (short, int, long,
+ long long, size_t ...). The problem with all these is that the number of bytes
+ they allocate depends on the compiler and the system. Instead use
+ Bacula's types (int8_t, uint8_t, int32_t, uint32_t, int64_t, and
+ uint64_t). This guarantees that the variables are given exactly the
+ size you want. Please try at all possible to avoid using size_t ssize_t
+ and the such. They are very system dependent. However, some system
+ routines may need them, so their use is often unavoidable.
\item Returning a malloc'ed buffer from a subroutine -- someone will forget
to release it.
\item Using reference variables -- it allows subroutines to create side
- effects.
+ effects. Reference variables are OK, if you are sure the variable
+ *always* exists, and you are sure you can handle the side effects of
+ a subroutine changing the "pointer".
\item Heap allocation (malloc) unless needed -- it is expensive.
\item Templates -- they can create portability problems.
\item Fancy or tricky C or C++ code, unless you give a good explanation of
projects / bacula / docs / blobdiff