Developers should check out the building guide to see how to build the Dogtag Certificate System from source. Then, you can choose to work on fixing bugs, adding new features, or improving the documentation. For other ideas, see our list on ways to contribute.
Alternatively, developers can jump directly to instructions on installing any of the various subsystems.
If a developer wants to contribute code to the project, look at the contributions page. It contains information on the process required to be able to submit patches that will be accepted. From a more technical standpoint, check out the appropriate coding style guide before submitting a patch.
Standards and Guidelines
Coding standards and guidelines are available for each language comprising the Dogtag Certificate System.
Our Patch Review Process - how to have a patch reviewed before pushing it to our source repository.
Additionally, the Dogtag Certificate System follows the Filesystem Hierarchy Standard (FHS) packaging standard.
To learn how to build Dogtag Certificate System as a developer, see Building the Dogtag Certificate System.
The Dogtag Certificate System currently does not have nightly builds and tinderbox builds.
A tinderbox is basically a continuous build cycle: pull SVN, build, report, repeat.
This is very useful when a lot of check-ins are happening at once, since feedback will be provided fairly quickly when something breaks.
To learn how to install and configure a PKI instance, see the PKI Installation Guide.
Certificate System Plug-ins
It is possible to write plug-ins that extend the functionality of various aspects of the Certificate System. The various plug-in tutorials listed below contain information about a specific API and the scope of its functionality.
A good way to contribute to improving the quality of a subsystem would be to add automated tests for each of the features. Developers and contributors to the Dogtag Certificate System Project are encouraged to write unit tests for any new features, updates, and bug fixes being contributed. Where possible, the tests should be data driven. This allows for greater numbers of test cases, covering more of the features under testing, to be written with minimal effort. We suggest that tests be written in a scripting language such as bash, Perl ( Perl::Test ), or Python for ease of maintenance.