Page History

...

• All public classes and methods should have informative Javadoc comments.
  • Do not use @author tags.
• Code should be formatted according to Sun's conventions. We use four spaces (not tabs) for indentation.
• Contributions should pass existing unit tests.
• New unit tests should be provided to demonstrate bugs and fixes. JUnit is our test framework:
  • You must implement a class that extends junit.framework.TestCase and whose class name contains Test.
  • If an HDFS cluster and/or a MapReduce cluster is needed by your test, add a field of type MiniCluster to the class and initialize it with a statement like the following (the name of the field is not important). TestAlgebraicEval.java is an example of a test that uses cluster. The test will then run on a cluster created on the local machine.
    MiniCluster cluster = MiniCluster.buildCluster();
• Define methods within your class and annotate it with @Test, and call JUnit's many assert methods to verify conditions; these methods will be executed when you run ant test.
• Place your class in the test tree.
• You can then run all the core unit test with the command ant test-commit. Similarly, you can run a specific unit test with the command ant test -Dtestcase=<ClassName> (For example ant test -Dtestcase=TestPigFile)

...

Please make sure that all the core unit tests succeed before constructing your patch.

> cd trunk
> ant -Djavac.args="-Xlint -Xmaxwarns 1000" clean jar test-commit

This should run in around 20 minutes.

After a while, if you see

...

svn add src/.../MyNewClass.java

...

In order to create a patch, just type:

...

1. Write a shell script that uses 'svn mv' to rename the original files.
2. Edit files as needed (e.g., to change package names).
3. Create a patch file with 'svn diff --no-diff-deleted --notice-ancestry'.
4. Submit both the shell script and the patch file.
   This way other developers can preview your change by running the script and then applying the patch.

Testing

...

a patch

Before submitting your patch, you are encouraged to You can run the same tools that the automated Hudson Jenkins patch test system will run on your a patch. This enables you to fix problems with your patch before you submit itonce Jenkins or a committer points them out. The test-patch Ant target will run your patch through the same checks that Hudson Jenkins currently does except for executing the core and contrib unit tests.

...

At the end, you should get a message on your console that is similar to the comment added to Jira by HudsonJenkins' s automated patch test system. The scratch directory (which defaults to the value of ${user.home}/tmp) will contain some output files that will be useful in determining what issues were found in the patch.

...

To apply a patch either you generated or found from JIRA, from the trunk directory you can issue

patch -p0 <cool_patch.patch

...

Finally, patches should be attached to a bug report in Jira via the Attach File link on the jira. Please add a comment that asks for a code review following our code review checklist. Please note that the attachment should be granted license to ASF for inclusion in ASF works (as per the Apache License subsection 5).

When you believe that your patch is ready to be committed, select the Submit Patch link on the issue's Jira. Submitted patches will be automatically tested against "trunk" by WWW Hudson, the lucene project's continuous integration engine Jenkins. Upon test completion, Hudson Jenkins will add a success ("+1") message or failure ("-1") to your bug report in Jira. If your issue contains multiple patch versions, Hudson tests the last patch uploaded. (Note: currently this is not working and developers are running test-patch manually. We hope to have this fixed soon.)

Folks should run 'ant clean test-commit javadoc' before selecting 'Submit Patch'. Tests should all pass. Javadoc should report no warnings or errors. Hudson's tests should only double-check things, and not be used as a primary patch tester, which would create too much noise on the mailing list and in Jira. Submitting patches that fail Hudson testing is frowned on, (unless the failure is not actually due to the patch).

If your patch involves performance optimizations, they should be validated by benchmarks that demonstrate an improvement.

Once a "+1" comment is received from the automated patch testing system and a "+1, code reviewed" comment is received from a code reviewer, a committer should then evaluate it within a few days and either: commit it; or reject it with an explanation. Once your patch has been submitted, a committer should then evaluate it within a few days and either: commit it; or reject it with an explanation.

Please be patient. Committers are busy people too. If no one responds to your patch after a few days, please make friendly reminders. Please incorporate other's suggestions into into your patch if you think they're reasonable. Finally, remember that even a patch that is not committed is useful to the community.

Should your patch earn a -1 on the Hudson Jenkins test, set the issue status to 'Resume Progress', upload a patch with necessary fixes and then set the status to 'Submit Patch' again.

Committers: for non-trivial changes, it is best to you must get another committer to review your patches before commit. Use "Submit Patch" like other contributors, and then wait for a "+1" from another committer before committing. Please also try to frequently review things in the patch queue.

...

Looking for a place to start? A great first place is to peruse the JIRA and find an issue that
needs resolved. If you're looking for a bigger project, try ProposedProjectsthe Pig Journal. This gives a list of projects the Pig team would like to see worked on.