• Contributing Code Changes
  • Choosing What to Work on
  • Before You Start Coding
  • Choosing the Right Branches to Work on
  • 4.0 Code Freeze
  • Bug Fixes
  • Creating a Patch

    Contributing Code Changes

    Choosing What to Work on

    Submitted patches can include bug fixes, changes to the Java code base, improvements for tooling (both Java or Python), documentation, testing or any other changes that requires changing the code base. Although the process of contributing code is always the same, the amount of work and time it takes to get a patch accepted also depends on the kind of issue you’re addressing. As a general rule of thumb
  • developer community.
  • Bug fixes take higher priority compared to features.
  • The extent to which tests are required depends on how likely your changes will effect the stability of Cassandra in production. Tooling changes requires fewer tests than storage engine changes.
  • Less complex patches will be reviewed faster; consider breaking up an issue into individual tasks and contributions that can be reviewed separately. the #cassandra or #cassandra-dev channels on ASF Slack, or on the user or dev mailing list.

    Before You Start Coding

    Slack. You should also
  • JIRA to work on.
  • Create a new issue early in the process describing what you’re working on - before finishing your patch.
  • Link related JIRA issues with your own ticket to provide a better context.
  • Update your ticket from time to time by giving feedback on your progress and link a GitHub WIP branch with your current code.
  • mentioning users. There are also some fixed rules that you need to be aware
  • Patches will only be applied to branches by following the release model
  • Code must be testable
  • code style convention
  • Changes must not break compatibility between different Cassandra versions
  • Contributions must be covered by the Apache License

    Choosing the Right Branches to Work on

    There are currently multiple Cassandra versions maintained in individual branches: cassandra-<release> (e.g. cassandra-3.0). The trunk branch is an exception, as it contains the most recent commits from all other branches and is used for creating new branches for future tick-tock releases.

    4.0 Code Freeze

    Patches for new features are currently not accepted for 4.0 or any earlier versions. All efforts should focus on stabilizing the 4.0 branch before the first official release. During that time, only the following patches will be considered for acceptance:
  • Bug fixes
  • Measurable performance improvements
  • Changes not distributed as part of the release such as:
  • Testing related improvements and fixes
  • Build and infrastructure related changes
  • Documentation

    Bug Fixes

    cassandra-2.1 → cassandra-2.2 → cassandra-3.0 → cassandra-3.x → trunk. But don’t worry, merging from 2.1 would be the worst case for bugs that affect all currently supported versions, an uncommon event. As a contributor, you’re also not expected to provide a single patch for each version. What you need to do however is:
  • Be clear about which versions you could verify to be affected by the bug
  • For 2.x: ask if a bug qualifies to be fixed in this release line, as this may be handled on case by case bases
  • If possible, create a patch against the lowest version in the branches listed above (e.g. if you found the bug in 3.9 you should try to fix it already in 3.0)
  • Test if the patch can be merged cleanly across branches in the direction listed above
  • Be clear which branches may need attention by the committer or even create custom patches for those if you can

    Creating a Patch

    So you’ve finished coding and the great moment arrives: it’s time to submit your patch!
  1. git checkout -b 12345-3.0 or git checkout -b CASSANDRA-12345-3.0.
  2. code style
  3. testing. If you suspect a test failure is unrelated to your change, it may be useful to check the test’s status by searching the issue tracker or looking at CI results for the relevant upstream version. Note that the full test suites take many hours to complete, so it is common to only run specific relevant tests locally before uploading a patch. Once a patch has been uploaded, the reviewer or committer can help setup CI jobs to run the full test suites.
  4. how to review page for your code. This will help you to understand how others will consider your change for inclusion.
  5. Don’t make the committer squash commits for you in the root branch either. Multiple commits are fine - and often preferable - during review stage, especially for incremental review, but once +1d, do either:
  6. Attach a patch to JIRA with a single squashed commit in it (per branch), or
  7. Squash the commits in-place in your branches into one
  8. should be listed in CHANGES.txt. If you fix a test that does not affect users and does not require changes in runtime code, then no CHANGES.txt entry is necessary.
  1. <One sentence description, usually Jira title and CHANGES.txt summary><Optional lengthier description>patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####
  1. When you’re happy with the result, create a patch. We suggest that you use a similar format (note blank lines) for the commit log message:
  1. <one sentence description><optional lengthier description>Patch by <authors>; reviewed by <Reviewers> for CASSANDRA-#####

TBD and amend the commit later to note the people who helped you.

  1. git add <any new or modified file>git commitgit format-patch HEAD~1mv <patch-file> <ticket-branchname.txt> (e.g. 12345-trunk.txt, 12345-3.0.txt)

Alternatively, many contributors prefer to make their branch available on GitHub. In this case, fork the Cassandra repository on GitHub and push your branch:

  1. git push --set-upstream origin 12345-3.0
  1. To make life easier for your reviewer/committer, you may want to make sure your patch applies cleanly to later branches and create additional patches/branches for later Cassandra versions to which your original patch does not apply cleanly. That said, this is not critical, and you will receive feedback on your patch regardless.
  2. Attach the newly generated patch to the ticket/add a link to your branch and click “Submit Patch” at the top of the ticket. This will move the ticket into “Patch Available” status, indicating that your submission is ready for review.
  3. how to review). If your change does not receive a +1, do not be discouraged. If possible, the reviewer will give suggestions to improve your patch or explain why it is not suitable.
  4. If the reviewer has given feedback to improve the patch, make the necessary changes and move the ticket into “Patch Available” once again.
  5. TBD with the reviewers who helped you. Once the review process is complete, you will receive a +1. Wait for a committer to commit it. Do not delete your branches immediately after they’ve been committed - keep them on GitHub for a while. Alternatively, attach a patch to JIRA for historical record. It’s not that uncommon for a committer to mess up a merge. In case of that happening, access to the original code is required, or else you’ll have to redo some of the work.