Page History

Welcome contributors! We strive to include everyone's contributions. This page provides necessary guidelines on how to contribute effectively towards furthering the development and evolution of Sqoop. You should also read the guide on Setting up Development EnvironmentSqoop 1 where you will find details on how to checkout, build and test Sqoop. If you are interested in contributing to Sqoop2, please follow Setting up Sqoop 2

Note: This guide applies to general contributors. If you are a committer, please read the Guide for Committers as well.

...

...

What can be contributed?

There are many ways you can contribute towards the project. A few of these are:

...

Provide Patches: We encourage you to assign the relevant JIRA issue to yourself and supply a patch for it. The patch you provide can be code, documentation, build changes, or any combination of these. More information on this is available in the following sections. We are using label "newbie" to JIRAs that are suitable for new contributors as proposed changes should be simpler to implement. You can see list of all opened JIRA tickets with newbie tag here.

Read the Quick Hack Sheet

Reviewing Code

Sqoop uses the Apache Review Board for doing code reviews. In order for a change to be reviewed, it should be either posted on the review board or attached to the JIRA. If the change is a minor change affecting only few lines and does not seem to impact main logic of the affected sources, it need not be posted on the review board. However, if the code change is large or otherwise impacting the core logic of the affected sources, it should be posted on the review board. Feel free to comment on the JIRA requesting the assignee to post the patch for review on review board.

...

• Test the change: It is very easy to test the change if you have the development environment setup. Run as many tests as you want with the patch. Manually test the change for functionality that you think is not fully covered via the associated tests. If you find a problem, report it.

...

• Submission checklist: Here is a checklist of things you should address before you post your patch for review:
  • Change should be clean, well-formatted, and readable. Please use two space indents, and space instead of tabs.
  • Make sure you have considered how to handle boundary condition cases and have sufficiently defensive code where necessary.
  • Add comments or java-docs where necessary.
  • Make sure that you have run checkstyle and findbugs and eliminated all warnings related to your change.
  • Is your change covered by any test case? If not, add a test case.
  • If your change affects a user interface, make sure you have updated the documentation accordingly.
  • If your change affects the development environment, make sure you update the COMPILING.txt and README files.

• Test your changes before submitting a review: Before you make the JIRA status as 'Patch Available', please test your changes thoroughly. Make sure that all tests are passing and that the functionality you have worked on is tested through existing or new tests.

• Submitting a patch: To submit a patch, first make sure that you have attached it to the JIRA and changed the status of the JIRA to 'Patch Available'. If the change is non-trivial, then please also post the patch for review on review board. The commands to generate the patch are:

  Code Block
  $ svn diff > /path/to/patch-file.patch

  or

  Code Block
  $ git diff --no-prefix > /path/to/patch-file.patch

...