Bacula Code Submissions and Projects

Getting code implemented in Bacula works roughly as follows:

• 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 Git repositories. 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.

• There are growing numbers of contributions (very good).

• Some contributions come in the form of relatively small patches, which Kern reviews, integrates, documents, tests, and maintains.

• All Bacula developers take full responsibility for writing the code, posting as patches so that we can review it as time permits, integrating it at an appropriate time, responding to our requests for tweaking it (name changes, ...), document it in the code, document it in the manual (even though their mother tongue is not English), test it, develop and commit regression scripts, and answer in a timely fashion all bug reports - even occasionally accepting additional bugs :-)

  This is a sustainable way of going forward with Bacula, and the direction that the project will be taking more and more. For example, in the past, we have had some very dedicated programmers who did major projects. However, some of these programmers due to outside obligations (job responsibilities change of job, school duties, ...) could not continue to maintain the code. In those cases, the code suffers from lack of maintenance, sometimes we patch it, sometimes not. In the end, if the code is not maintained, the code gets dropped from the project (there are two such contributions that are heading in that direction). When ever possible, we would like to avoid this, and ensure a continuation of the code and a sharing of the development, debugging, documentation, and maintenance responsibilities.