This (and other) bug updates are incorrect.

[Daniel D. Daugherty]

On 4/25/19 2:05 PM, Daniel D. Daugherty wrote:
> On 4/25/19 1:43 PM, Aleksey Shipilev wrote:
>> Hi Phil,
>>
>> On 4/25/19 6:55 PM, Phil Race wrote:
>>>   "8" specifically means 8 GA. It does not mean "some release in the 
>>> 8 train"
>> I don't think it means "8 GA", I think it means "some release in the 
>> 8 train", see below.
>>
>>> So when you added "8" you are saying that this bug affects a release 
>>> before
>>> the cause was introduced, which is plainly impossible.
>>> In fact this bug is about a detail of a feature which got 
>>> backported  very recently
>>> so it really is wrong to mark it as affects 8.
>>>
>>> I think you need to explain what you are trying to achieve and then
>>> maybe the previous Oracle 8u maintainers can explain how you should
>>> actually be doing this and help you correct the various bugs that are
>>> now incorrectly marked as affecting 8 GA.
>> Well, I can explain if you ask nicely :) Here it goes:
>>
>> I think we routinely mark Affected-Version with the major release 
>> train: 7, 8, 11, 12, 13, without
>> mentioning the exact version that issue affects. This helps to keep 
>> versions list tidy, and
>> automation saner. For example, for the new issues affecting every 
>> build up to 8u212, do I have to
>> actually run with all these versions to figure out which version 
>> started to fail? This puts too much
>> strain to submitters.
>>
>> It is also inconvenient for most filters and queries that would have 
>> to list/wildcard minor
>> versions. My goal is to have backports-monitor to track the release 
>> trains status w.r.t. backports.
>> Others also do JIRA queries for the same reason.
>>
>> Using only the major release version is a common practice. Just 
>> poking at random issues for
>> client-libs, for example:
>>    https://bugs.openjdk.java.net/browse/JDK-8218617
>>
>> It fixes the bug triggered by JDK-8062164, which went to 8u40. By the 
>> "8 specifically means 8 GA"
>> logic, JDK-8218617 should have been marked "8u40". But it is not, in 
>> fact history says its original
>> Affected-Versions was "8u202", then it got changed to "8". I can 
>> understand why: nobody has time to
>> figure out the minor version where it started to fail, and why would 
>> anyone bother?
>>
>> It mostly matters that 8u should get the fix, hence the major version 
>> only is mentioned. I believe
>> this is why the overwhelming majority of issues are marked with major 
>> version only. For example,
>> again poking randomly:
>>    https://bugs.openjdk.java.net/browse/JDK-8222477 (submitted as "8, 
>> 12, 13")
>>    https://bugs.openjdk.java.net/browse/JDK-8217263 (submitted as "8, 
>> 11, 12, 13")
>>    https://bugs.openjdk.java.net/browse/JDK-8210863 (submitted as "8, 
>> 11, 12")
>>    ...
>>
>> Sure, if you know the precise version, you are welcome to put it into 
>> Affected-Versions. This does
>> not prevent anyone else to mark it afterwards with the release train. 
>> Having "8, 8u202" does not
>> lose any information.
>>
>> Bottom-line: I don't see what is "incorrect" here.
>>
>> -Aleksey
>>
>
> Sorry Aleksey. Version value '8' historically means JDK8-GA. It should
> only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u
> project wants to add an '8u' that means some version after JDK8-GA, then
> that is fine.
>
> Dan

Another way to think about is this:

We're having this conversation on the jdk8u-dev at openjdk.java.net alias.
We are not having this conversation on the jdk8-dev at openjdk.java.net alias.

Why? Because the OpenJDK8 project is done. We now have an OpenJDK8u 
project...

There are a few examples of emails that come in on jdk8-dev at openjdk.java.net
where we redirect the folks to jdk8u-dev at openjdk.java.net because the
OpenJDK8 project is done.

Dan