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

[David Holmes]

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.

Cheers,
David

> Thanks,
>
> -Joe
>
> [1] http://openjdk.java.net/projects/jdk9/
>
> [2]
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html
>
> [3] http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html
>
> [4]
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html,
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html