RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push

[Mikael Vidstedt]

I could swear that I updated the webrev with exactly that before I sent 
out the review requests, but I must have messed it up some way... In 
either case I agree, and here's a new webrev:

http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.01/webrev/

Cheers,
Mikael

On 2015-12-18 21:42, David Holmes wrote:
> This may be too late but I'd prefer to see an explicit:
>
> # Allow concurrent changes to be merged in prior to pushing
> jprt.sync.push=true
>
> both so that:
>
> a) it is visible that this happens and we can control it; and
> b) because "sync" is misleading - we always "sync" ie pull in any new 
> changes, but what we don't do is merge if there is a conflict with 
> those changes.
>
> Thanks,
> David
>
> On 19/12/2015 8:20 AM, Mikael Vidstedt wrote:
>>
>> Please review this small change which relaxes the check made in JPRT at
>> the time when a hotspot push job has finished successfully, and the
>> changes are about to be pushed.
>>
>> Currently the job will be marked as failed if a merge is needed, even if
>> an automatic merge would complete successfully. This "safety mechanism"
>> was reasonable when all pushes were made using JPRT, but since we
>> started allowing direct pushes the failure rate has gone up. The
>> assumption here is that the code changes will very rarely overlap, and
>> even more rarely conflict, so if the automatic merge is successful then
>> it's highly likely that the resulting code would (also) pass the JPRT
>> testing.
>>
>> This change enables the automatic merge to be attempted, and if it is
>> successful the resulting changes will be pushed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145828
>> Webrev:
>> http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.00/webrev/
>>
>> Cheers,
>> Mikael
>>