Your first commit
Congratulations on becoming a Tez Committer. Once you become Tez Committer, you should have commit access to tez repository. You will need to clone https://git-wip-us.apache.org/repos/asf/tez.git to be able to commit to the Tez repo.
You should first create a JIRA ticket for adding yourself to the Tez Team List and do this as your first commit. To make the update, you will need to update "docs/pom.xml" to add your info. Once, you have followed the process listed below for committing patches, you will need to publish the updated docs to the website. The instructions of how to update Tez website are here.
General Committer Guidelines
- Before committing a patch of one JIRA, you should first get +1 from at least 1 other committer.
- Also, the patch to be committed should have been run through a Precommit Build and obtained a +1 ( green light ) on the JIRA by the build job. This will happen automatically if the JIRA status has been set to Patch Available.
- The build job will add a comment to the JIRA after the patch has been tested.
- You should work on this repository which is writable https://git-wip-us.apache.org/repos/asf/tez.git
- Each patch requires a +1 from a committer. If the author of the patch is a committer, it requires a +1 from a different committer.
How to Commit
- First you need to ask yourself, which branch you need to commit into ? Usually you should commit it to master, if there's one release based on another branch, you should also commit into that branch ( use cherry-pick as below ). If you are not sure about this , send a message to the Tez developer mailing list.
- (No longer necessary for master branch) For each commit, you should also update the CHANGES.txt, including which release this JIRA will go in and add details to the INCOMPATIBLE CHANGES section if it is an incompatible change. Our convention is to put your change on the top of change list. CHANGES.txt should contain an entry in each version that the JIRA is committed to. e.g. If a patch is committed to master (0.8.1) and branch-0.7 (0.7.1), then CHANGES.txt in master will contain an entry under version 0.8.1 and 0.7.1. CHANGES.txt in branch-0.7 will contain the JIRA under the 0.7.1 change list. Put the new entry at the top of the change list.
- Any patch that is applied and committed should have been previously uploaded to JIRA by the author. In certain scenarios, when fixing minor nits, the committer can make a change, upload the patch with the minor modification to JIRA and then commit the modified patch.
Usually you will create a separate branch for your JIRA you are working, you can also work on master directly if you think the JIRA is pretty simple. Here I assume you are working on a separate branch. e.g TEZ-100
Please remember to resolve the JIRA with the required Fix Version set. The Fix Version is based on the final branch of commit. For example, a commit to branch-0.5 will imply that the fix version is the next unreleased version of 0.5.x. A commit to master only implies that the Fix Version should be set to the next major release ( for now, 0.x are considered major releases ). (Do not mark the JIRA as Closed. This will be done by the Release Manager after a release with the changes has been published)
If it's incompatible change, mark it in hadoop flags. Don't use labels to mark this.
When you complete the committing, you'd better to check the repository https://git-wip-us.apache.org/repos/asf?p=tez.git;a=summary whether the commit is pushed correctly.
Update the JIRA with the details to which branches the patch was committed. Please be sure to thank the author of the patch as well as any reviewers.
Setting various Version fields on JIRA
The affects version of a JIRA should be set to the released versions which the JIRA affects. If the JIRA represents an issue which was introduces in one of the active lines - the affects version should be set to the relevant unreleased version numbers.
This should be set to the oldest unreleased version where the JIRA will be committed. This would imply all newer unreleased versions automatically get the fix.
This should be set to all versions to which the patch on the JIRA is committed.