You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

How To Contribute

  • Use the Apache JIRA for posting design docs and having design discussions (adding detailed descriptions, comments, etc)

  • Create a patch and upload to the Apache JIRA.  The patch should be named AMBARI-XXXX.patch for trunk patches and AMBARI-XXXX_YYYY.patch for branch patches, where XXXX is the JIRA ID and YYYY is the name of the branch (for example, AMBARI-1234_branch-1.7.0.patch).  If the patch is for a release branch, both trunk patch and branch patch must be uploaded.

  • Mark the patch as Patch Available by clicking on the “Submit Patch” button (Note: if the patch is for a private branch, then it will cause an integration failure in the test runner, in this case you may not perform "Submit Patch")

  • Wait for the "Hadoop QA" process to post feedback on the patch.  This typically takes 30 mins to an hour and reports back on unit test results, license header compliance, presence of new tests, etc, on the JIRA itself.

  • If "Hadoop QA" checks do not pass but you think the feedback is invalid, state the reasons why you believe it is invalid. 

  • Once "Hadoop QA" checks pass (or if there's a valid reason for ignoring the checks), create a ReviewBoard for the patch (see Using Review Board section below) and request two Ambari committers (more would not hurt) to review the patch via the code review process below

    • Please note that if the patch is not involved - one committer should suffice

  • On review completion and any further updates, the reviewers give +1 for the patch

    • A +1 from an Ambari committer is mandatory before any patch can be committed (+1 from a non committer, though useful, does not count toward this requirement)

    • There should be 2 +1's from Ambari committers for changes that are involved or if the patch is going into a release branch

  • NOTE: Be sure to include tests in the patch.  If tests are not applicable, provide a good explanation for not having a test case.

  • After the reviewer(s) has approved the patch, the assignee of the JIRA is responsible for getting it committed if that person is a committer.  If not, one of the reviewers needs to commit.

    • If the patch is intended to go into a release branch, make sure that the patch is committed to both the release branch and trunk.

  • Refer to https://cwiki.apache.org/confluence/display/AMBARI/How+to+Commit on how to commit

  • After committing to git, resolve the Apache JIRA as Fixed.

  • All unit tests must pass after applying the patch.

  • Also, any new files must contain Apache 2.0 license headers

  • Do not use tabs.  Set your IDE to convert tabs into spaces instead.

  • Do not use non-ASCII characters

  • Do not use Windows newline characters.  Use UNIX newline characters instead.

  • Make sure that you are checking in all dependencies/new files; after committing, the build should work on clean checkout

  • Make sure that the clock is set up correctly on your machine.

Review Process

Ambari uses ReviewBoard for code reviews.

All Ambari related code reviews, at ReviewBoard, can be found at https://reviews.apache.org/groups/Ambari/

Using ReviewBoard

You may need to create a ReviewBoard login. Once you login add yourself to the "Ambari" group.

To submit a patch for review

  1. Click on "New Review Request"
  2. Select "ambari" from the drop-down and upload a diff file
  3. Go to the next page
    1. Add a summary
    2. Names of at least two reviewers that are familiar with that code, please refer to Code Review Guidelines for a list of committers that have volunteered to review a certain code area (In case patch is simple and less involved - one reviewer is ok)
    3. Select ambari as the group
    4. Enter the name of the branch(es), e.g., "trunk", "branch-x.y"
    5. Type in the Ambari JIRA id
    6. Add description of the fix
    7. Be sure to fill out "Testing Done" section to describe what testing has been done (e.g., tested X, Y, and Z scenarios end-to-end on a live cluster), post unit test results, etc.
    8. Add a link to the ReviewBoard URL to the JIRA
      1. Go to JIRA Menu --> More --> Link --> Web Link (Link Text should be ReviewBoard)
    9. [if applicable] Fill the optional fields as needed.
    10. [if applicable] Add the unit test summary to the request
  4. Publish the review
  5. After the review is marked "Ship It" you can optionally attach the final patch to the JIRA.
  6. Mark the review as closed
    1. On the ReviewBoard portal Close --> Submitted

For reviewers

Reviewers, after you are satisfied with the patch, mark "Ship It" through the ReviewBoard or "+1" to the JIRA.


Apache Ambari Committers

Please read more on Apache Committers at: http://www.apache.org/dev/committers.html

 

In general a contributor that makes sustained, welcome contributions to the project may be invited to become a committer, though the exact timing of such invitations depends on many factors. Sustained contributions over 6 months is a welcome sign of contributor showing interest in the project. A contributor receptive to feedback and following development guidelines stated above is a good sign for being a committer to the project. We have seen contributors contributing 20-30 patches become committers but again this is very subjective and can vary on the patches submitted to the project. Ultimately it is the Ambari PMC that suggests and votes for committers in the project.


Contribution Flow

 

https://docs.google.com/a/pivotal.io/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit?pli=1



  • No labels