Dear Wiki user, You have subscribed to a wiki page or wiki category on "Pig Wiki" for change notification.
The following page has been changed by gkesavan: http://wiki.apache.org/pig/HowToContribute The comment on the change is: Added test your patch section and updated the contribute your work section. ------------------------------------------------------------------------------ * comment code whose function or rationale is not obvious; * update documentation (e.g., package.html files, this wiki, etc.) + If you need to rename files in your patch: + 1. Write a shell script that uses 'svn mv' to rename the original files. + 1. Edit files as needed (e.g., to change package names). + 1. Create a patch file with 'svn diff --no-diff-deleted --notice-ancestry'. + 1. 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 your patch ==== + + Before submitting your patch, you are encouraged to run the same tools that the automated Hudson patch test system will run on your patch. This enables you to fix problems with your patch before you submit it. The {{{test-patch}}} Ant target will run your patch through the same checks that Hudson currently does ''except'' for executing the core and contrib unit tests. + + To use this target, you must run it from a clean workspace (ie {{{svn stat}}} shows no modifications or additions). From your clean workspace, run: + + {{{ + ant \ + -Dpatch.file=/patch/to/my.patch \ + -Dforrest.home=/path/to/forrest/ \ + -Dfindbugs.home=/path/to/findbugs \ + -Djava5.home=/patch/to/java5home \ + -Dscratch.dir=/path/to/a/temp/dir \ (optional) + -Dsvn.cmd=/path/to/subversion/bin/svn \ (optional) + -Dgrep.cmd=/path/to/grep \ (optional) + -Dpatch.cmd=/path/to/patch \ (optional) + test-patch + }}} + + At the end, you should get a message on your console that is similar to the comment added to Jira by Hudson'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. + + Some things to note: + * the optional cmd parameters will default to the ones in your {{{PATH}}} environment variable + * the {{{grep}}} command must support the -o flag (GNU does) + * the {{{patch}}} command must support the -E flag + * you may need to explicitly set ANT_HOME. Running {{{ant -diagnostics}}} will tell you the default value on your system. + === Applying a patch === To apply a patch either you generated or found from JIRA, you can issue @@ -133, +167 @@ 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 [http://www.apache.org/licenses/LICENSE-2.0 Apache License] subsection 5). - When you believe that your patch is ready to be committed, select 'Edit' link from the 'Operations' section in Jira and check the 'Patch Available' box. - - ##Submitted patches will be automatically tested against "trunk" by [WWW] Hudson, the lucene project's continuous integration engine. Upon test completion, Hudson 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. + 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. Upon test completion, Hudson 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. - ## This should be moved up above, rather than giving more directions here. We don't support checkstyle yet. Need to do that. >> Folks should run 'ant clean test javadoc checkstyle' before selecting 'Submit Patch'. Tests should all pass. Javadoc should report no warnings or errors. Checkstyle's error count should not exceed that listed at [WWW] Checkstyle 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). + Folks should run 'ant clean test javadoc checkstyle' before selecting 'Submit Patch'. Tests should all pass. Javadoc should report no warnings or errors. Checkstyle's error count should not exceed that listed at [WWW] Checkstyle 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 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 test, set the issue status to 'Resume Progress', upload a patch with necessary fixes and then set the status to 'Submit Patch' again. + Should your patch earn a -1 on the Hudson 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 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.
