New Committers

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

• New committer guide
• Committer FAQ
• Committer Responsibilities
• As first commit - Add your name to the list of Committers in pom.xml of the project. Follow the steps in commit section for instructions. Specify the roles that have been granted to you in the invite mail. If you are invited as committer, just add your role as "Committer". If you are invited as PMC, specify "PMC" and "Committer" as your roles. A typical committer tag would look like

  <developer>
    <id>amareshwari</id>
    <email>amareshwari@apache.org</email>
    <name>Amareshwari Sriramadasu</name>
    <timezone>+5.5</timezone>
    <roles>
      <role>PMC</role>
      <role>Committer</role>
    </roles>
  </developer>
  

Review

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.

Commit

The commit repo is at https://git-wip-us.apache.org/repos/asf/lens.git 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.
• Cross check if your git user.name and user.email are properly configured. Set username and email with commands

  git config user.name "Amareshwari Sriramadasu"
  git config user.email "amareshwari@apache.org"
  

• Apply the patch attached on jira. The patch should be licensed under apache license.

    git apply --check lens_patch.patch
    git apply lens_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.
• Keep yourself as committer and the contributor as the author of the commit.

    git commit -a --author "Amareshwari Sriramadasu <amareshwari@apache.org>" -m "LENS-123 : Adds awesome feature to lens."
  

• 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.

Reverting a commit

• In case you messed up your first commit - you should post a revert commit to cancel the commit by a reverse patch and then post a new commit with appropriate changes.

  git revert HEAD~1..HEAD # To revert 1 commit.
  or,
  git revert a4r9593432 # To revert particular commit by commit id.
  

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/generate-site-public.sh can be used to generate the documentation, which has to be committed to website svn. Steps are as follows -

• Checkout website svn: svn co https://svn.apache.org/repos/asf/lens/ $SVN_SITE_DIR
• Run tools/scripts/generate-site-public.sh $SVN_SITE_DIR
• Add newly created files to SVN
• Commit. (Please contact one of the committers for site SVN access)