This (and other) bug updates are incorrect.

[Daniel D. Daugherty]

On 4/25/19 2:47 PM, Aleksey Shipilev wrote:
> On 4/25/19 8:13 PM, Daniel D. Daugherty wrote:
>>> 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.
> My problem with "historically" is that it is very open to interpretation. What you are saying
> implies that every bug that has affectedVersion = 8 is checked to be reproduce-able with 8 GA. Which
> does not ring true, since submitters usually check only with the some current version of 8u, and I
> see that "8" serves as blanket "some (presumably latest) version of 8" designator for many recent
> issues.

Then those issues are wrong. If I was working on those bugs I would
first nail down the proper version info.


> That's how people use it today, no matter the history. I think that is a fair compromise: if you
> know the exact version the issue appeared in, put in the exact version. But if you don't, you are
> not pressured to figure it out, put the blanket major version, and move on. Having both does not
> look incorrect.

No, that's not correct usage. What I expect folks to do is file the
bug with the specific version that they tested. If you test 8u172,
then I expect the bug to be filed against 8u172. I personally don't
expect the submitter to track the bug back to the earliest version
of 8u or even JDK8-GA. That's not their job.

If I see a recent bug filed against '8', then I would be very suspicious
that '8' is not the correct version. If I was working on such a bug, then
my first task would be to nail down where the real sighting is.


> If using 7, 8, 11, 12, 13 as blanket designators is incorrect, then it is incorrect in many places
> around JBS, and you have to go and say it somewhere, *and* provide consistent replacements for all
> of them. Changing it only for 8u does not bring any added consistency. The closest alternative I can
> see is 7-pool, 8-pool, 11-pool, 12-pool, 13-pool, etc, but I don't know their exact meaning.

You misunderstand me. If the OpenJDK8u project wants a blanket designator,
then that project is welcome to create one. I do not recommend doing that.
A bug filed with a blanket version designator is initially useless to the
evaluator because the first thing you have to do is figure out the real
version where the issue was sighted. However, that's my opinion. I'm not
working on the OpenJDK8u project.


>> 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...
> That's a weird argument, to be honest. By that argument, we have to have 11u, 12u, etc as JIRA
> versions, which we don't.

And the folks that run those projects can choose to have those blanket
version values. However, I do not recommend it.

Just to be clear: Please do not use '8' as a blanket version
designator value. That release value belongs to the OpenJDK8
project and _does not_ belong to the OpenJDK8u project.

And as Phil requested, please fix the bugs that you recently
touched to no longer use '8'.

Dan

>
> -Aleksey
>