How to handle future backports from JDK 10 into JDK 9?

[joe darcy]

On 2/20/2017 2:43 AM, David Holmes wrote:
> On 20/02/2017 7:11 PM, Seán Coffey wrote:
>> On 18/02/2017 03:14, David Holmes wrote:
>>
>>> Creating a new bug for a "backport" is already existing practice for
>>> the update releases, so this isn't something radically new.
>> I don't believe above to be accurate. An engineer rarely has to create a
>> backport bug ID. For the majority of cases, it's automatically handled
>> by hgupdater tooling and no one has to ever reference the backport ID.
>
> I think there is a misunderstanding. What I am talking about is when a 
> specific issue is created (of type bug or rfe) to handle the 
> backporting of some fix or enhancement, when the use of a direct 
> "backport" of the original fix/ref is not possible for some reason.
>
> The bug database is littered with such issues, for example:
>
> https://bugs.openjdk.java.net/browse/JDK-8038440
> https://bugs.openjdk.java.net/browse/JDK-8052313
>
> and there are many, many examples.

The query

     summary ~ backport and project = JDK

yields 398 results and the more specific query

      summary ~ backport and project = JDK and issuetype != Backport

yields 262 results while

      summary ~ backport and project = JDK and issuetype != Backport and 
id > JDK-8000000

has only 182 results. Bug id 8000000 represents the start of using JBS 
as the bug system, circa September 2012.

The query

     issuetype = backport and project = JDK and id > JDK-8000000

yields 52,604 results. Therefore, since JBS started the conventional use 
of the backport issue type is nearly 300 times as common as putting 
"backport" in the summary to indicate an issue is conceptually a 
backport without using a backport issue type at all. (The results are 
similar if legacy bugs imported into JBS are included in the analysis.)

Post-JBS, the most frequent component to use "backport" in the summary 
without a backport issue type is core-libs (32 instances) followed by 
hotspot (31 instances) and FX (30 instances).

If someone had asked my opinion on tracking fixes to multiple release 
trains using a backport-that-is-not-a-backport, I would have strongly 
advised against it. I don't think a relative handful of ill-advised uses 
of backports-that-are-not-backports should be used as a precedent to 
justify broader adoption of this (anti-)pattern.

I don't understand the rationale for this usage. There is not a 
requirement that the patch of a backport apply cleanly for a backport 
issue type to be used. If one needs the specific backport issue to be 
created before pushing, one can do that manually as a backport issue 
type rather than an independent issue.

-Joe