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

[joe darcy]

Hello,

Returning to this topic, after additional consideration, I still think 
we should start JDK 10 by hg pull'ing changes in from JDK 9. In other 
words, adopt a forward-port rather than back-port policy, at least for 
the time being.

Under this model, engineers with a fix that had to go into both JDK 9 
and JDK 10 would just push the fix into 9 and a separate periodic 
process would sync the changes into 10.

Comments?

Thanks,

-Joe


On 12/2/2016 5:26 PM, 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?
>
> 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