Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • If you are new to Tez and want to start with pre-existing issues, look for JIRAs labelled newbie.
    •  Once, you have found an unassigned issue to work on, add a comment stating your interest to work on the issue and one of the committers will assign the issue to you.
  • When making changes, follow the same coding style as the code that you are modifying.
    • Please ensure that each line remains with a 100-char limit.  
  • Ensure that all newly added code is documented well with javadocs as appropriate.
  • Add unit tests for your code.

Creating a new JIRA issue

  • If there is no existing JIRA that can be found that matches the issue in question, please create one here.
  • Please use a brief but descriptive title and also provide a detailed description
  • Set the following fieldss:

    • Issue Type: Generally, this will be one of BugImprovement and New Feature.

    • Priority: Set priority based on severity of the issue. 

    • Affects Version: For Bugs, assign at least one version that is known to exhibit the problem or needs the change.

  • Do not set the following fields:

    • Target Version: This designates a potential target version in which this fix will likely land.

    • Fix Version. This is assigned by committers only when resolved.

Submitting a Patch

  • Once you have made the required changes, ensure that the code compiles and all the unit tests run successfully. 
  • Now, you can generate a patch using "git diff --no-prefix origin/master"  ( Use "origin/branchname" to generate a diff against a different branch.
  • Name the patch file using the JIRA issue and a patch version or a datetime when the patch was generated. For example, "TEZ-1234.1.patch" or "TEZ-1234.20140516.1.patch"
    • Add the branch name to patch filename in case the patch is generated for a branch other than master.
  • Attach this patch file to the JIRA issue and hit "Submit Patch" to change the issue status to "Patch Available". This will trigger a utility that will test the patch by applying it, checking for various issues ( new warnings, findbugs, new tests added, etc) and also run unit tests after applying the patch.
  • If you do not see any feedback on your patch within a couple of days, please send a friendly reminder mail to the dev mailing list

Submitting a Pull Request

  • Fork the Github repository at http://github.com/apache/spark if you haven't already

  • Clone your fork, create a new branch, push commits to the branch.

  • Compile and run all tests.

  • Open a pull request against the master branch of apache/tez. (Only in special cases would the PR be opened against other branches.

    • The PR title should be of the form [TEZ-xxxx] Title, where TEZ-xxxx is the relevant JIRA number and title will be the JIRA's title.

    • If the pull request is still a work in progress, and so is not ready to be merged, but needs to be pushed to Github to facilitate review, then add [WIP] after the component.

    • Please state that the contribution is your original work and that you license the work to the project under the project's open source license.

  • Tez, currently, does not have an automated pre-check process for pull requests. More details will be provided once that integration is in place. For now, a diff can be created and attached to the JIRA to trigger the pre-commit process ( based on the steps mentioned in the previous section).