This (and other) bug updates are incorrect.

[Daniel D. Daugherty]

On 4/25/19 5:03 PM, Aleksey Shipilev wrote:
> On 4/25/19 10:57 PM, Daniel D. Daugherty wrote:
>> On 4/25/19 3:44 PM, Aleksey Shipilev wrote:
>>> If there are none, people would
>>> invent/reuse the closest one, like the blank major revision. This will happen soon with somebody
>>> else, because the confusion is real; any many do this around JBS as well. More examples below.
>> I guess I'm not understanding why someone would file an issue
>> without specifying the exact version number they are seeing
>> the issue reproduce with.
> Because sometimes it is rather unclear what the "exact version where issue reproduces" is. If this
> looks very clear to you, would you mind guiding me through properly versioning the issues below?
>
>>> But, I have trouble fixing these oddly versioned ones:
>>>
>>> == "Update GIFlib library to the 5.1.8":
>>>     https://bugs.openjdk.java.net/browse/JDK-8220495
>>>
>>> Which "Affects Version" should it take?

For this bug, I would drop '7', '8', '11' and '12'. I would only
set an affects version on the 7u, 8u, 11u and 12u trains that
match the current version for each of those trains. By "current
version", I mean the current version that includes the old version
of the library.


>>> If we look back to issue history, there is a previous update
>>> happened here:
>>>     https://bugs.openjdk.java.net/browse/JDK-8155691
>>>
>>> Should it be 8u161 then?

This bug's affects version is set to only '9' and I'm good with
that. The backport issues make it clear which update release has
the newer version of the library. Pretty safe to assume that an
older version of 7u and 8u has the older version of the library.

In this example, "less is more" for the "Affects Version/s" field.

Would I go back and add more "Affects Version/s" values?  No, I
would not, but that doesn't mean other folks won't do it.


>>>
>>> == "Xalan Update: Xalan Java 2.7.2":
>>>     https://bugs.openjdk.java.net/browse/JDK-8193830
>>>
>>> The issue already has 8u backports, but affects-version did not have any "8*" version. Which version
>>> to put there? The bug does not even link any related issues to see when was the latest update. I put
>>> "8" there this morning, which version should I put instead? I think this is one of those cases where
>>> "8" fits: it is not a bug, and 8 GA does not have new Xalan.

You are quite correct in stating that '8' has the old library so this
issue applies there. Is that good information? Not really. Like
JDK-8155691 above, I would have left "Affects Version/s" at '10' and
not added any '8u' versions. Again, the Backports tell you which '8u'
version has the new version of the library and anything older doesn't.


>>>
>>> == "Upgrade IANA LSR data"
>>>     https://bugs.openjdk.java.net/browse/JDK-8213294
>>>
>>> So it has backport to 8u221, which version to use then? 8u201? Or, using the logic from Xalan issue
>>> above, it is also proper "8"?

It looks like this issue had an empty "Affects Version/s" that you set
to '8', '11', and '12'. I would probably left it empty since this isn't
a hotspot bug and that team may not have rules about setting the "Affects
Version/s" field.

If I really felt compelled to set an "Affects Version/s" value, I
would have set just '12'. Again, the Backports tell you which '8u'
and which '11u' version has the new version of the library and anything
older doesn't.



>>>
>>> == "[Windows] Exception if no printers are installed."
>>>     https://bugs.openjdk.java.net/browse/JDK-8212202
>>>
>>> It had backports to 8u212 and 8u231. It seems to be caused by JDK-8153732, which was backported to
>>> 8u212 and 8u231, which versions to use then? 8u212?

You added '8'. Since JDK-8153732 isn't fixed in '8', that's the wrong
value. If you had to add an "Affects Version/s" value, I would add
8u212 and maybe 8u231. You could also skip adding an "Affects Version/s"
value and let the Backports do the talking.

Obviously, those are my opinions. YMMV.

Dan




> Thanks,
> -Aleksey
>