From Free IPA

Contributing to freeIPA

1. Join mailing lists
2. Find us on IRC
3. Read developer docs
4. Install freeIPA
5. Sign CLA
6. Jump into our code and process

Developer Documentation

Version 1 Documentation

• v1 PRD: requirements for IPA v1
• v1 Architecture: overview of v1 architecture.
• Schema: overview of the LDAP schema used in IPA
• Access Control in FreeIPA v1: Discussion on access control in v1.
• User/Install Documentation: freeIPA user/install/admin documentation

Version 2 Documentation

• v2 PRD: draft requirements for IPA v2
• FreeIPA v2 Development Progress: Portal to v2 design pages and current code repositories.
• Group Discussion: Discussion on how to deal with primary groups
• Policy Enforcement: Discussion on v2 and beyond policy enforcement.

Communication

Mailing Lists

The development of FreeIPA is done on the freeipa-devel mailing list. You can join at https://www.redhat.com/mailman/listinfo/freeipa-devel. Feel free to introduce yourself to the list and let us know what areas of development are of most interest to you.

Use freeipa-users mailing list to discuss deployment, configuration, and use of FreeIPA. It is the best place to ask "how to" questions and to share your experience with FreeIPA.

Subscribe to freeipa-interest mailing list for product-related announcements.

IRC

We also hang out on IRC at irc.freenode.net on the #freeipa channel.

Bug and Feature Tracking

Bugs and feature requests are tracked using Bugzilla. The product is 'freeIPA'.

We formerly used Trac.

CLA

A CLA is a contributor license agreement. Before contributions to freeIPA can be accepted, we need to have a signed copy of the CLA.

• Why a CLA? Why do I need to sign a CLA to contribute to this project?
• Download the CLA
• Where do I send the CLA? Instructions for where to send the CLA are listed in the CLA itself.

Development Process

Working with the Codebase

• Git Documentation: Information on using Git, our source control system of choice.
• C Coding Style Guide: Our style guide for C code used in FreeIPA.
• Python Coding Style Guide: Our style guide for Python code used in FreeIPA.
• Build: Instructions on how to build IPA v1/2 from source
• Testing: Instructions on IPA v2 tests

Source Repository

FreeIPA Server

The source repository for FreeIPA is stored in git. The code can be retrieved with the command:

git clone git://git.fedorahosted.org/git/freeipa.git

This will create the initial repository (named 'freeipa') in the current directory. Updating the repository can be accomplished with the command 'git pull' from within the repository. More information on GIT can be found at GitDocs.

You can also browse the source repository via the web.

System Security Services Daemon (IPA Client)

The source repository for the SSSD is stored in git. The code can be retrieved with the command:

git clone git://git.fedorahosted.org/git/sssd.git

You can also browse the source repository via the web.

Submitting Changes

Changes to the repository are submitted via patches on the freeipa-devel mailing list (see above for list information). The best way to prepare the patch is to commit the change locally and use 'git-format-patch -1 commit-id' to export the patch (where commit-id is the commit number of the checkin you want to send, use 'git log' to see it).

Commit Message Format

With git the first line of a commit message is what is displayed in the subject of a patch e-mail, so choose a short, concise description of what the patch does. Leave a blank line then include a more detailed description of the patch. If there is an associated trac ticket or bugzilla then include a reference to that.

Examples are:

Fix this test to work from source tree root

It would work if you ran the test from its location in tests/test_ipalib
but this isn't the most common method. If you want to run it individually
you can do:

$ ./make-test tests/test_ipalib/test_text.py

and

gpg2 requires --batch to use the --passphrase* arguments.

This was causing replica creation and installation to fail.

596446

Code Review

All patches must be submitted to the developer list for review. This is currently freeipa-devel@lists.fedoraproject.org. There is an exception to this rule called the "One Liner" rule - if the patch is trivial (e.g. only one line changed), it can be pushed upstream without a review. What means trivial? Use your best judgment.

A patch may not be pushed upstream until it has received approval on the devel mailing list.

You will also want to look at our Coding Style Guide

Wiki Editing

If you would like access to edit this Wiki, please send a request to the freeipa-devel mailing list and someone will create an account for you.