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

[joe darcy]

Hi Vladimir,

If the HotSpot team is concerned matching bug id and summaries, I 
suggest using a wrapper script around jprt or hg push that does that 
check. I know various individuals have written such scripts for their 
own use; probably a case where we could do a better job sharing small tools.

In my estimation, using back port bug ids for pushes would be more prone 
to errors/typos than continuing the long-standing policy of using the 
main bug id in such cases.

Cheers,

-Joe


On 2/15/2017 1:00 PM, Vladimir Kozlov wrote:
> 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 
>>>
>>>