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

[joe darcy]

Hello David and others,

Returning to this topic, I concede there are exceptional cases where 
backporting some functionality under a different bug id may be 
reasonable. However, I don't think such rare cases should drive larger 
decisions of handling forward and backports in 9 and 10 and whether or 
not the duplicate bug id check should be disabled in JDK 10.

While the bug id check does prevent the error of accidentally reusing a 
bug id, it does not prevent many other classes of errors around bug ids, 
such as swapped digit typos. (Sharing of scripts to do such checks 
pre-push welcome.) Additionally, the duplicate bug id check causes 
complications, including the topic under discussion now, as well as for 
the possible repository consolidation. That check has been disabled in 
the update releases for years without problems.

Therefore, on the whole, I think it would be a net benefit to disable 
the duplicate bug id check for JDK 10 too.

Cheers,

-Joe


On 2/21/2017 7:05 PM, David Holmes wrote:
> 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