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

[Vladimir Kozlov]

We discussed this in Hotspot and support David's opinion here.
We should not relax jcheck and we can use backport type different bug id as he suggested.

Regards,
Vladimir

On 2/13/17 6:15 PM, David Holmes wrote:
> 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
>>