Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA?

[David Holmes]

Hi Joe,

On 6/12/2016 3:23 PM, joe darcy wrote:
> Hi David,
>
> On 12/5/2016 4:39 AM, David Holmes wrote:
>> Hi Joe,
>>
>> On 3/12/2016 11:26 AM, Joseph D. Darcy wrote:
>>> On 12/2/2016 4:21 PM, Joseph D. Darcy wrote:
>>>> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote:
>>>>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com:
>>>>>> I need to register my concerns for SE client (the open part, not
>>>>>> closed)
>>>>>> I don't think it is feasible to collapse the current lines of
>>>>>> development
>>>>>> unless all our current testing done at PIT is able to be run for
>>>>>> every push
>>>>>> and we are nowhere near that. Maybe even further away than we were
>>>>>> before.
>>>>> So, are you saying that you want a separate "client" forest in JDK 10,
>>>>> as in past releases, at least for now?
>>>>
>>>> While continuing discussions about whether or not a separate client
>>>> forest is merited, I think it would be acceptable to go forward with
>>>> creating the master/dev forest and the separate forest for HotSpot,
>>>> the latter named "hs".
>>>>
>>>
>>> While the number of lines of development discussion is wrapping up,
>>> before the JDK 10 forests open I think it is worthwhile to consider
>>> another question: how should the JDK 10 forests be kept up to date with
>>> changes being made in JDK 9 between the time JDK 10 opens and JDK 9 GA?
>>>
>>> The current schedule for JDK 9 has its GA on July 27, 2017. [1] For JDK
>>> 9 builds 137 through 147, the average number of fixes per builds was
>>> about 108. While the rate of bug fixes is expected to diminish as the
>>> release enter rampdown, I'd still expect many hundreds of fixes to be
>>> made in JDK 9 before it ships.
>>>
>>> In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) and
>>> the rampdown and GA of JDK 8 (March 2014 [3]), engineers were expected
>>> to be responsible for pushing their fixes both to JDK 8 and JDK 9. [4]
>>> While this approach is tractable for a relatively small number of
>>> changes, about 300 in the 12 builds of JDK 8 after JDK 9 branched off, I
>>> don't think it would scale well for the larger number of fixes expected
>>> during the overlap of JDK 9 and 10.
>>>
>>> Therefore, I think a different approach should be used this time around.
>>> Rather than protracted cherry-picking, I think changes in JDK 9 promoted
>>> builds should be merged into JDK 10, at least until JDK 9 ZBB.
>>>
>>> Comments?
>>
>> It obviously depends on the number of fixes going into 9 and the
>> number of significant changes that go early into 10. There are a
>> number of refactorings and cleanups that are slated for early in 10 -
>> at least on the hotspot side - which may make straight merging by a
>> "generic" gatekeeper somewhat challenging. But as ZBB is only 8 weeks
>> away this may be short enough (given the Xmas break etc) to make this
>> manageable.
>>
>> I think it makes sense to try for a scheme that minimises the workload
>> on the individual developers, and we'll just have to see how far we
>> get before things become unmanageable. We could also chose to delay
>> significantly disruptive changes until after ZBB.
>
> On a related note, I was thinking disruptive changes might initially be
> better done in a sandbox then in 10 mainline for a while to ease keeping
> 10 up to date with changes still occurring in 9.

That will need some coordination and agreement on what constitutes 
"disruptive". A lot of people are waiting eagerly for the 10 repo to 
open so they can start clearing the decks. :) Particularly in relation 
to some cleanup RFEs in hotspot.

David
-----

> Given the nontrivial amount of work in 9 (and the urgency of getting it
> finished!), at least for a while I think supporting the ability of
> getting the remaining 9 work done should take priority over fostering
> disruptive changes in 10.
>
> Cheers,
>
> -Joe