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

[joe darcy]

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.

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