1. I really like the new patch process, especially the at-a-glance summary
2. I think being -1 on whitespace is overkill; Its just part of my " git apply 
-p 0 -3 --verbose --whitespace=fix  " action. Accordingly, I won't reject 
patches on whitespace alone.
3. if checkstyle is complaining, how to track it down? As example, I don't see 
much from:
https://builds.apache.org/job/PreCommit-HADOOP-Build/6167/artifact/patchprocess/checkstyle-result-diff.txt


> On 23 Apr 2015, at 12:21, Allen Wittenauer <a...@altiscale.com> wrote:
> 
> 
> 
> 
> 
> On Apr 22, 2015, at 11:34 PM, Zheng, Kai <kai.zh...@intel.com> wrote:
> 
>> Hi Allen,
>> 
>> This sounds great. 
>> 
>>>> Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285 
>>>> branch.
>> Does it happen locally in developer's machine when running test-patch.sh, or 
>> also mean something in Hadoop Jenkins building when a JIRA becoming patch 
>> available? Thanks.
> 
> 
>       Both, now that a fix has been committed last night (there was a bug in 
> the Jenkins handling).
> 
>       Given a patch name or URL, Jenkins and even running locally will try a 
> few different methods to figure out which branch to use  out.  Note that a 
> branch name of ‘gitX’ where X is a valid git reference also works to force a 
> patch to start at a particular commit. 
> 
>       For local use, you’ll want to use a ‘spare’ copy of the source tree via 
> the —basedir option and use the —resetrepo flag.  That will enable 
> Jenkins-like behavior and gives it permission to make modifications and 
> effectively nuke any changes in the source tree you point it at.  (Basically 
> the opposite of the —dirty-workspace flag).  If you want to force a branch 
> (for whatever reason, including where the branch can’t be figured out), you 
> can use the —branch option. 
> 
>       If you don’t use —resetrepo, test-patch.sh will warn that it thinks the 
> wrong branch is being used but will push on anyway.
> 
>       In any case, the result of what it thinks the branch is/should be will 
> be in the summary output at the bottom along with the git ref that it 
> specifically used for the test.

Reply via email to