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

[David Holmes]

On 14/02/2017 8:54 AM, joe darcy wrote:
> Hello,
>
> An open question in Mark's announcement that the JDK 10 forests are open
> [1] concerned how to manage backports from JDK 10 to JDK 9:
>
> "In the (hopefully infrequent) event that a change in JDK 10 needs to be
> back-ported to JDK 9 we'll have to figure out how to handle the duplicate
> bug ids that will arise when a back-ported change is later merged forward
> into JDK 10.  One solution may just be to disable the unique bug-id test
> in jcheck, on the assumption that existing social conventions adequately
> protect us from the pathological scenarios that are prevented by this
> test.  Thoughts welcome ..."
>
> As a reminder, the overall model (for now) is that all fixes from JDK 9
> will be synced into JDK 10; the first sync of several hundred bugs
> happened recently and went smoothly. [2]
>
> The potentially problematic situation would occur if
>
> * Bug JDK-8181818 is first fixed in JDK 10
> * Bug JDK-8181818 is then backported to JDK 9
> * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id
> JDK-8181818 even though the code may be identical
>
> One way to avoid this problem would be to do the push to JDK 9 under an
> explicit backport bug id rather than the main bug id JDK-8181818. This
> approach has a number of drawback. First, long-standing social
> convention has been to "always use the main bug id." Second, tooling
> like Hg updater has been written on the assumption that the main bug id
> will always be used to conceptually refer to an issue.
>
> The purpose of the jcheck unique bug id check stems from preventing
> sloppy bug handling where multiple changesets partially and
> incrementally address a bug and it is not clear whether or not an issue
> is fully fixed or not.
>
> However, even without programmatic enforcement of unique bug id, I don't
> think JDK development practices would devolve in that way. As supporting
> evidence, the unique bug id check is disabled in the 8 update forests to
> allow fixes from multiple releases to come back together in the
> always-open forest and the pathologies around partial fixes have not
> occurred.
>
> Therefore, I think the better option is to also disable the unique bug
> id check for the JDK 10 forests to allow easier syncing between 9 and 10.

I think that check has helped avoid pushes with mis-typed bug numbers. 
Unless we have a stronger "does this bug id match the bug synopsis" 
check I would not want to see this bug id check relaxed.

I would not expect there to be many cases where something is deferred to 
10, fixed, and then re-considered for 9. But if that does happen I think 
the simplest thing may be to do the backport under a new bug id (as 
already happens at time in the update releases when the backport is not 
clean).

Thanks,
David
-----

> Comments?
>
> Cheers,
>
> -Joe
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html
>
> [2]
> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html
>