How to handle future backports from JDK 10 into JDK 9? (original) (raw)

joe darcy joe.darcy at oracle.com
Tue Feb 21 17:14:13 UTC 2017

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

More information about the jdk10-dev mailing list