How to Contribute

There are many opportunities to contribute code to Apache Cassandra, including documentation updates, test improvements, bug fixes, changes to the Java code base, and tooling improvements.

Before getting started, please read about Contributing Code Changes, and familiarize yourself with Cassandra's code style guidelines, testing and code review checklist.

A recommended workflow to get started is:

  1. Find or create an issue in the Cassandra JIRA that describes the work you plan to do.
  2. Create a personal fork of the Apache Cassandra GitHub repo.
  3. Clone your fork into your development environment.
  4. Create your feature branch. Please see the branch naming suggestion, below.
  5. Make, build, test and self-review your changes on your feature branch.
  6. Submit the patch, either by creating a GitHub pull request, attaching a patch file to your JIRA, or posting a link to a GitHub branch with your changes.

Branch naming: To ease collaboration, consider naming your feature branch like your-name/jira-id/base-branch. For example, jcshepherd/CASSANDRA-12345/trunk. This convention will help with managing multiple collaborators on a shared fork, and managing patches which differ across different Cassandra versions.

Note: Committers follow additional processes for handling patches, pull requests, and committing directly to the official repo, which the Apache Cassandra GitHub repo mirrors.

Contributing to Related Projects

There are a number of Cassandra-related projects where contributions may be welcomed, including:

... and more. Visit those repositories and their related JIRA issues for more information on making contributions.

Working with Submodules

Apache Cassandra uses git submodules for a set of dependencies, this is to make cross cutting changes easier for developers. When working on such changes, there are a set of scripts to help with the process.

Local Development

When starting a development branch, the following will change all submodules to a new branch based off the JIRA

$ .build/sh/development-switch.sh --jira CASSANDRA-<number>

When changes are made to a submodule (such as to accord), you need to commit and update the reference in Apache Cassandra

$ (cd modules/accord ; git commit -am 'Saving progress')
$ .build/sh/bump-accord.sh

Commit and Merge Process

Due to the nature of submodules, the changes to the submodules must be committed and pushed before the changes to Apache Cassandra; these are different repositories so git's --atomic does not prevent conflicts from concurrent merges; the basic process is as follows:

  • Follow the normal merge process for the submodule
  • Update Apache Cassandra's submodule entry to point to the newly committed change; follow the Accord example below for an example
$ .build/sh/change-submodule-accord.sh
$ .build/sh/bump-accord.sh

Useful Links

  • How you can contribute to Apache Cassandra presentation by Yuki Morishita
  • Code style wiki page
  • Running Cassandra in IDEA guide
  • Running Cassandra in Eclipse guide
  • Cassandra Cluster Manager - CCM and a guide blog post
  • Cassandra Distributed Tests aka dtests
  • Cassandra Testing Guidelines - see TESTING.md