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

[David Holmes]

Hi Joe,

 From my own observation/experience the "why" we would create a new bug 
to "backport" something is when the something is not neatly packaged and 
obtainable through direct backports of specific issues. Take an example 
of an issue that is fixed but is buggy and has quite a lengthy bugtail - 
once it is reliable you want to backport it to an earlier release. Do 
you backport each individual bug (some of which may not even apply to 
the earlier release) or do you backport the resulting functionality that 
was finally obtained? There are pros and cons to both approaches - 
neither is clean nor ideal. Such is life.

Cheers,
David
-----

On 22/02/2017 3:14 AM, joe darcy wrote:
> 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