Inconsistent "Fix Version: 15" for JDK-8247367

[Daniel D. Daugherty]

Hi Alexsey,

This fix was pushed at 2020.06.11 @ 1216 ET/1616 UTC so it did not make
the cutoff for JDK15. However, it looks like the hgupdater switch from
JDK15 -> JDK16 for jdk/jdk pushes happened after that point.

I have changed this bug:

     JDK-8247367 Shenandoah: pacer should wait on lock instead of 
exponential backoff

to have a 'Fix Version/s' value of '16' instead of '15'.

I have re-opened the backport bug:

     JDK-8247468 Shenandoah: pacer should wait on lock instead of 
exponential backoff

changed the 'Affects Version/s' value to '15'. If you don't intend to
backport the fix for JDK-8247367 to JDK15, then we can close the backport
as "Won't Fix".

The next push to jdk/jdk (for JDK16) was this one:

     JDK-8207936 TestZipFile failed with java.lang.AssertionError exception

and it appears to be correct.

The last push to jdk/jdk (for JDK15) was this one:

     JDK-8246382 assert in MetaspaceShared::map_archives

and it also appears to be correct.

It looks like just your bug (JDK-8247367) got caught in the worm hole. :-)

Dan


On 6/15/20 10:05 AM, Aleksey Shipilev wrote:
> Hi,
>
> I am a bit confused about hgupdater closing some issues as "Fix Versions: 15". For example, see
> these issue, it is "Fixed in 15":
>    https://bugs.openjdk.java.net/browse/JDK-8247367
>
> The changeset is indeed in jdk/jdk:
>    http://hg.openjdk.java.net/jdk/jdk/log?rev=8247367
>
> ...but not in jdk/jdk15:
>    http://hg.openjdk.java.net/jdk/jdk15/log?rev=8247367
>
> Is there some kind of version switch race that this push got into?
> E.g. hgupdater switched to 16 for jdk/jdk some time after jdk/jdk -> jdk/jdk15 split?
>
> There might be more issues like this.
>