Thread: Contributing Code to Kusu

There are a few ways to contribute to Kusu:

• use the software and file bugs you find (see JIRA Guidelines)
• follow the kusu-user mailing list and help others
• write documentation
• write code fixing bugs or implementing new features

Submitting Code


So you made some changes to the Kusu source code in order to fix a bug or implement a new feature. Great, we'd love to include your code in the project. Here's what you have to do:

1. Find a bug to fix/implement, or file it if it doesn't already exist
2. Check out the code, make your changes and test them
3. Submit your patch for review
4. Once approved, check in your changes
5. Mark the issue as "Resolved"

Let's take a more detailed look at this process below.

Log the Issue in JIRA

We keep track of all bugs, issues, feature requests etc. in JIRA (also see JIRA Guidelines). Before filing a new issue, please search through JIRA, your issue may have been already filed or even fixed. Once your issue is logged in JIRA, hack away.

Before Submitting Patches

We strive to have automated/unit tests for all code. You should probably run the tests for the module you'll be working on before making any changes (you never know ). After your changes are complete, run all the tests to make sure you didn't break something else.
Of course if you are writing a lot of new code, you should also write new tests to exercise this code. A great approach to take is to write a failing test first, then writing just enough code to make the test pass (see Test Driven Development).

Submitting Your Patch

Code:

Generate your patch by running
$ svn diff --diff-cmd diff -x "-U 10000"

in the root of the code you checked out. The extra parameters after svn diff generate a patch with the entire file for context (10000 lines above and below your changes).
Paste this patch into a comment to the JIRA issue you're working on, or attach it to an email to the kusu-devel mailing list. Your code will be reviewed by the core developers before it is committed to the tree.

Creating a Review and Attaching Your Patch

If you have access to Crucible, instead of submitting your patch to JIRA or the mailing list, go ahead and create a Crucible review. When the changes have been approved, your code can then be committed.

Your Patch is Approved

Once you get the go-ahead to check in your changes, note the issue number and review number in the commit message. For example, if I'm working on KUSU-864 and my changes were reviewed in KUSU-REVIEW-2 my commit command might look like this:

Code:

$ svn ci -m 'Fix KUSU-865: kitops crashing on syntax \
error in kitinfo file. Reviewed in KUSU-REVIEW-2.'

Resolving the Issue in JIRA

When Subversion finishes committing your changes, it will tell you the revision number you just committed. You can then mark the JIRA issue you worked on as "Resolved", noting the Subversion revision containing your fix as well as the Crucible review of your changes.
The issue will be marked "Closed" after further testing is done.