This (and other) bug updates are incorrect.

[Aleksey Shipilev]

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