THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
This document describes how to commit changes to Ambari. It assumes a knowledge of Git. While it is for committers to use as a guide, it also provides contributors an idea of how the commit process actually works.
In general we are very conservative about changing the Apache Ambari code base. It is ground truth for systems that use it, so we need to make sure that it is reliable. For this reason we use Review Then Commit (RTC) http://www.apache.org/foundation/glossary.html#ReviewThenCommit change policy.
Except for some very rare cases any change to the Apache Ambari code base will start off as a Jira. (In some cases a change may relate to more than one Jira. Also, there are cases when a Jira results in multiple commits.) Generally, the process of getting ready to commit when the Jira has a patch associated with it and the contributor decides that it is ready for review and marks it patch available.
A committer must sign off on a patch. It is very helpful if the community also reviews the patch, but in the end a committer must take responsibility for the correctness of the patch. If the match is simple enough and the committer feels confident in the review, a single +1 from a committer is sufficient to commit the patch. (Remember committers cannot review their own patch, so if a committer submits a patch, they should make sure that another committer reviews it.)
With the required number of approvals, a committer (any committer can do this including the one that committed the patch) can now make the change to the code base. Here are the recommended steps for committing:
- checkout the code using
- make sure the code is up-to-date
- git fetch
- check out the correct branch
- git checkout -b branch_name
- make a patch file
- git diff trunk... > a.patch
- apply the patch
- git apply path_to_patch
- Please make sure you run the tests are your machine as a final check before you commit using
mvn clean test.
In case the mvn clean test is failing please do not commit. File a JIRA and ping the person who has committed the last patch on the branch you are committing to and politely ask him to revert. The committer responsible for the broken build can either choose to fix or revert the patch. This is quite important since broken unit tests can cause a lot of churn and confusion for other developers. Its best to keep the trunk/builds healthy.
- git commit the changes. The comment should looks like "AMBARI-1234. JIRA title. (contributor via committer)"; a convention has emerged of using the committers id for brevity, but using the full names of non-committers for the contributor part
- git pull --rebase
- git push origin <local-branchname>:<remote-branchname>
- resolve (make sure you "resolve" and not "close".) the jiras that correspond to the patch and put the commit message (that one that has the new revision number) in the resolution comment field or a statement saying "Committed to trunk and branch-x", depending on which branches you've committed to.
If the Jira is a bug fix you may also need to commit the patch to the latest branch in git.