This (and other) bug updates are incorrect.

[Daniel D. Daugherty]

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