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

[Volker Simonis]

On Thu, Feb 16, 2017 at 11:11 PM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Joe,
>
> On 17/02/2017 6:01 AM, joe darcy wrote:
>>
>> 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.
>
>
> That's solving the problem in the wrong place in my opinion.
>
>> 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.
>
>
> That wasn't the suggestion. The suggestion was to create a new bug eg
> "Backport 8134567 to JDK 9" and use that bugid for the "backport" instead of
> creating an actual backport-issue using the original main bug id.
>

I totally agree with David and would strongly support his suggestion.
We could introduce a new line in the change comment like "Backport-of:
<bug-id>" so we can easily find and identify such changes. And after
all, there hopefully shouldn't be to many of them.

> Cheers,
> David
>
>
>> 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
>>>>>
>>>>>
>>
>