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

Compare with Current View Page History

« Previous Version 20 Current »

Reporting Issues

If you'd like to report a bug in Tez or ask for a new feature, open an issue on the Apache Tez JIRA. For general usage help, you should email the user mailing list. For developers contributing to Tez and are looking for help, you should an email to the dev mailing list.

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 Bug, Improvement 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.

How to Contribute

Getting Started

Ready to Contribute?

  • Look for Newbie JIRAs to work on
  • Add a comment to the JIRA that you wish to work on and ask for it to be assigned to you
  • Take a look at the sections below for the basics of submitting patches.
  • Feel free to send questions to the Dev Mailing List if you have any questions
  • If you do not get a response on a JIRA within a couple of days, please send a polite reminder/ask for help on the dev mailing list.

Setting up your dev environment

Making Changes

  • Before you start, send a message to the Tez developer mailing list, or file a bug report in Jira. Describe your proposed changes and check that they fit in with what others are doing and have planned for the project. Be patient, it may take folks a while to understand your requirements.
  • 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.

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 the 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". 
  • 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/tez 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 JIRA id.

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

  • The PR will trigger a precommit testing which comments back on the PR








  • No labels