RFR: Clarifications and X-wnf label [v2]

[Jesper Wilhelmsson]

On Mon, 15 Jan 2024 02:29:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No 17u-na
>
> src/guide/jbs-jdk-bug-system.md line 352:
> 
>> 350:       The [Affects Version/s]{.jbs-field} field is used to indicate the releases where an issue has been seen - it's implied that the issue is also applicable to newer releases. Where this isn't the case - for instance a bug in code that was removed in *(Rel)* - then use *(Rel)*[-na]{.jbs-label} to indicate this. Note that there should only be **one** *(Rel)*[-na]{.jbs-label} label on any JBS issue.
>> 351: 
>> 352:       Don't use the label to indicate that a bug isn't relevant to an earlier release. If a bug is not present in an earlier release you can use [Introduced in Version]{.jbs-field} to indicate where the bug was introduced. If a bug is present in an earlier release, but shouldn't be fixed there, use [*(Rel)*[-wnf]{.jbs-label}]{#rel-wnf}.
> 
> But from a backporting perspective I, for example, would want to know if the issue is present in 8u, and I can easily test that. But I don't know if the issue in present in 9 or 10 and I would not want to waste time testing those versions just so I can set the "Introduced In" field. It makes more sense to me, to use `8-na` to indicate that JDK 8 has been checked and has no issue. Alternatively, the guide should be directing me to perhaps create an explicit backport record for 8u and close it as "Not an Issue".

The intention is to have an upper boundary on the need to fix an issue - the X-na label, and a lower boundary - the X-wnf label. A label that is used to spot-indicate specific releases without saying anything about the before or after is much less useful when trying to automate things. For a human looking at a single bug what you say makes sense, but for a tool it would be impossible to determine if 8-na means just 8 or 8 and later.

The labels are slightly badly named which is why this discussion exists. But this is what we currently have. To change the names of the labels is a much larger discussion.

-------------

PR Review Comment: https://git.openjdk.org/guide/pull/118#discussion_r1466458655