This (and other) bug updates are incorrect.

[Aleksey Shipilev]

On 4/26/19 1:02 PM, Dalibor Topic wrote:
> On 26.04.2019 07:05, Andrew John Hughes wrote:
>> It would seem to make more sense to designate those that are known to
>> reproduce specifically on OpenJDK 8 GA with a new label '8-ga' rather
>> than creating a distinction between '8' and '8u' which is far from obvious.
> 
> I think that it's great that the various parties collaborating around OpenJDK 8 Updates maintenance
> are now embracing usage of JIRA as a common source of truth. But let's not rewrite issue history,
> please.

Well, "rewrite issue history" did not happen. The JDK-8218605 in question was _amended_ to capture
"8", and "8u211" was kept intact. If it was a destructive update, then yes, that would be a
significant problem. Since it wasn't destructive, it is a minor snag.

For me, the actionable lesson from here is this: if there is a specific affected-versions set, like
"8u211", then adding the lower one (e.g. "8") is not called for, unless actually verified that
version is affected (e.g. "8 GA"). The existing version says enough about the release train where
the issue was discovered.

Similarly, if there are no reliable data what exact version in a release train the issue affects, it
is fine to put the provisional "8u201" (or whatever is latest now) to the affected-version, assuming
the fix needs to be in latest release, with the intent to amend it, if/when the actual affected
point in 8u is discovered. If we know the issue affects 8 GA (as the frequently the case for
RFE/updates that sink backwards from higher releases), we can go and put "8".

In all these cases, the affected-version tags would tell the affected release train (which our tools
want, and can figure out by stripping minor versions), and keep the issue metadata as precise as
possible (which seems to be the original complaint).

Have I summed it up correctly to everyone's agreement?

-Aleksey