Dear Wiki user, You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.
The "HowToContribute" page has been changed by ZhengShao: https://wiki.apache.org/hadoop/HowToContribute?action=diff&rev1=108&rev2=109 Comment: Removed Hudson and replaced with Jenkins and https://builds.apache.org/view/All/ It's also OK to upload a new patch to Jira with the same name as an existing patch. If you select the "Activity>All" tab then the different versions are linked in the comment stream, providing context. However, many reviewers find it helpful to include a version number in the patch name (three-digit version number is recommended), '''so including a version number is the preferred style'''. === Testing your patch === - Before submitting your patch, you are encouraged to run the same tools that the automated Jenkins patch test system will run on your patch. This enables you to fix problems with your patch before you submit it. The {{{dev-support/test-patch.sh}}} script in the trunk directory will run your patch through the same checks that Hudson currently does ''except'' for executing the unit tests. + Before submitting your patch, you are encouraged to run the same tools that the automated Jenkins patch test system will run on your patch. This enables you to fix problems with your patch before you submit it. The {{{dev-support/test-patch.sh}}} script in the trunk directory will run your patch through the same checks that Jenkins currently does ''except'' for executing the unit tests. Run this command from a clean workspace (ie {{{git status}}} shows no modifications or additions) as follows: @@ -206, +206 @@ == Contributing your work == 1. Finally, patches should be ''attached'' to an issue report in [[http://issues.apache.org/jira/browse/HADOOP|Jira]] via the '''Attach File''' link on the issue's Jira. Please add a comment that asks for a code review following our [[CodeReviewChecklist|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]] ยง5). - 1. 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 [[http://hudson.zones.apache.org/hudson/view/Hadoop/|Hudson]], the project's continuous integration engine. Upon test completion, Hudson will add a success ("+1") message or failure ("-1") to your issue report in Jira. If your issue contains multiple patch versions, Hudson tests the last patch uploaded. It is preferable to upload the trunk version last. + 1. 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 [[https://builds.apache.org/view/All/|Jenkins]], the project's continuous integration engine. Upon test completion, Jenkins will add a success ("+1") message or failure ("-1") to your issue report in Jira. If your issue contains multiple patch versions, Jenkins tests the last patch uploaded. It is preferable to upload the trunk version last. 1. Folks should run {{{mvn clean install javadoc:javadoc checkstyle:checkstyle}}} before selecting '''Submit Patch'''. 1. Tests must all pass. 1. Javadoc should report '''no''' warnings or errors. - 1. Checkstyle's error count should not exceed that listed at [[http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/lastSuccessfulBuild/artifact/trunk/build/test/checkstyle-errors.html|Checkstyle Errors]] + 1. Checkstyle's error count should not exceed that listed at lastSuccessfulBuild/artifact/trunk/build/test/checkstyle-errors.html - . Hudson's tests are meant to 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). + . Jenkins's tests are meant to 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 Jenkins testing is frowned on, (unless the failure is not actually due to the patch). 1. If your patch involves performance optimizations, they should be validated by benchmarks that demonstrate an improvement. 1. If your patch creates an incompatibility with the latest major release, then you must set the '''Incompatible change''' flag on the issue's Jira 'and' fill in the '''Release Note''' field with an explanation of the impact of the incompatibility and the necessary steps users must take. 1. If your patch implements a major feature or improvement, then you must fill in the '''Release Note''' field on the issue's Jira with an explanation of the feature that will be comprehensible by the end user. @@ -220, +220 @@ 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 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 receive a "-1" from the Hudson testing, select the '''Cancel Patch''' on the issue's Jira, upload a new patch with necessary fixes, and then select the '''Submit Patch''' link again. + Should your patch receive a "-1" from the Jenkins testing, select the '''Cancel Patch''' on the issue's Jira, upload a new patch with necessary fixes, and then select the '''Submit Patch''' link again. == Jira Guidelines == Please comment on issues in Jira, making their concerns known. Please also vote for issues that are a high priority for you.
