Here is an anti-delta for the broken push. I prepared it using “hg backout”.
webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8041948
If I can get this reviewed quickly I can push the fix soon (and I will spend
the weekend in shame).
Approved!
-Joe
On 04/25/2014 09:36 AM, Staffan Larsen wrote:
Here is an anti-delta for the broken push. I prepared it using “hg backout”.
webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8041948
If I can get this reviewed quickly I can
On 25/04/2014 17:36, Staffan Larsen wrote:
Here is an anti-delta for the broken push. I prepared it using “hg
backout”.
webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/
http://cr.openjdk.java.net/%7Esla/8041948/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8041948
If I
Thanks Joe - fix has been pushed.
(I will now retreat to a dark place and grumble over the impossibility of
pushing coordinated changes).
/Staffan
On 25 apr 2014, at 18:43, Joe Darcy joe.da...@oracle.com wrote:
Approved!
-Joe
On 04/25/2014 09:36 AM, Staffan Larsen wrote:
Here is an
what's wrong with pushing them to jdk9/hs-rt?
We did this a couple of weeks ago with Erik (Gahlin) changes,
it might disrupt nightly, as we still do not have the JPRT changes in place,
but that was the agreement we have for jdk9:
tightly coupled changes should be pushed through the hotspot
In this case I think it would have worked ok since the dependency was from jdk
- hotspot. If the dependency was the other way (or both ways), then such a
push would break nightly testing in hotspot since that testing picks up the
latest promoted JDK (instead of the JDK that is in the same