RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push
david.holmes at oracle.com
Wed Dec 23 04:28:16 UTC 2015
Ship it! :)
On 23/12/2015 12:19 PM, Mikael Vidstedt wrote:
> 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