RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push
mikael.vidstedt at oracle.com
Wed Dec 23 02:19:25 UTC 2015
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:
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
> 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.
> 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
>> 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
More information about the hotspot-dev