Committer Guide

This page provides necessary guidelines for committers of Apache Lens.

New Committers

New committers are encouraged to first read Apache's generic committer documentation:


Lens committers should, as often as possible, attempt to review patches submitted by others. Ideally every submitted patch will get reviewed by a committer within a few days. If a committer reviews a patch they've not authored, and believe it to be of sufficient quality, then they can commit the patch, otherwise the patch should be cancelled with a clear explanation for why it was rejected.

The list of submitted patches should be ordered by Updated timestamp - Lens patch available issues and Review board. Committers should scan the list from one which was updated earliest, looking for patches that they feel qualified to review and possibly commit.

Review guidelines are put up at review guidelines in contributer guide

The committers are allowed to commit their own patch only if the patch first receives a +1 vote from another committer.

Patches should be rejected which do not adhere to the guidelines above and code compliance guidelines in contributer guide. Committers should always be polite to contributors and try to instruct and encourage them to contribute better patches. If a committer wishes to improve an unacceptable patch, then it should first be rejected, and a new patch should be attached by the committer for review.


The commit repo is at When you commit a patch, please:

  • Ensure that all tests pass with patch applied.
  • Ensure that the patch has a +1 vote from another committer or yourself.
  • Ensure that 24 hours have elapsed since the jira is made patch available or the review request is up. As a practice we should observe this, but it should be possible to consciously override and commit with a shorter turnaround time.
  • Apply the patch attached on jira. The patch should licensed under apache license.
      git apply -p0 <final-patch>.patch
  • Don't forget to do 'git add' on any new files, and 'git rm' on any files that have been 'deleted' by the patch.
  • Include the Jira issue id in the commit message, along with a short description of the change and the name of the contributor. Be sure to get the issue id right, as this causes Jira to link to the change in git.
        Example commit message: "LENS-123. Adds awesome feature to lens. (Jaideep Dhok via amareshwari)"
  • Keep yourself as committer and the contributor as the author of the commit.
        git commit -a --author "Amareshwari Sriramadasu <>"
  • Push the commit to master branch
  • Resolve the issue as fixed, thanking the contributor. Always set the "Fix Version" at this point.
  • Put incompatibility flags on, if the change is an incompatible change.
  • Add appropriate release note about what the issue is fixing. New features should have elaborate release note on how to use the feature.

Backporting patches

Once the patch is pushed to master, it can be cherry-picked and applied on other major version lines. If the patch is not applicable for master and only applicable to the release version, then above guide lines of review and commit needs to be followed with change of committing branch to be the release branch.

Fix version needs to include this release version as well.

Updating Lens site

Lens uses Apache SVN Pub-Sub system to maintain its website. The script tools/scripts/ can be used to generate the documentation, which has to be committed to website svn. Steps are as follows -

  • Checkout website svn: svn co $SVN_SITE_DIR
  • Run tools/scripts/ $SVN_SITE_DIR
  • Add newly created files to SVN
  • Commit. (Please contact one of the committers for incubator site SVN access)