Developers

From Fedora Directory Server

Developers should check out our building and install guides to see how to build and install the server from source. Then you can get working on fixing bugs, adding new features or improving our documentation. For other ideas see ways to contribute.

For details on checking out and building the Fedora Management Console and the Fedora Directory Server Console, see the building console page.

Or you can jump directly to instructions on installing the server.

If you want to contribute code to the project you should look at our contributing page. It contains information on the process you have to go through to be able to submit patches we will accept as well as getting a CVS account. From a more technical standpoint, before submitting a patch you should check out our coding style guide. Once your patch is approved, see the CVS rules before checking anything in.

You should also be take some time to review our license.

Source Code

We use CVS as our SCM

New FHS style packaging

In an effort to be more file system layout friendly, we are proposing changing the layout from the /opt/fedora-ds style to a more FHS friendly style. FHS_Packaging

Builds

We have several types of builds: Nightly builds and Tinderbox builds.

A tinderbox is basically a continuous build cycle: pull CVS, build, report, repeat.

This is very useful when a lot of checkins are happening at once, you'll get fairly quick feedback when something breaks.

Directory Server Plugins

It is possible to write plugins that allow you to extend the functionality of the Directory Server. Our plugins page contains information on the API and the scope of the functionality. You might also want to look at our annotated license page for some legal information on using the plugin api.

Release_Procedure

Testing

Not a coder? No problem. You can help by finding new bugs, verifying existing bugs, polishing documentation and generally improving the quality of the server.

A good way to contribute to improving the quality of the server would be to add automated tests for each of the features. Developers and contributors to the Fedora Directory Server 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 feature under test, to be written with minimal effort. We suggest tests be written in a scripting language like ksh, Perl ( Perl::Test ) and perhaps python for ease of maintenance.

There are a number of other LDAP test tools available from other groups and companies which may be of interest:

  • DirectoryMark from Mindcraft, is an LDAP benchmarking tool
  • Slamd is a distributed LDAP load generation engine

What can you do?

Contributors