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

David Holmes david.holmes at oracle.com
Sat Dec 19 05:42:16 UTC 2015

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 


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

More information about the hotspot-dev mailing list