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

[Thomas Stüfe]

On Tue, Dec 6, 2016 at 7:03 AM, David Holmes <david.holmes at oracle.com>
wrote:

> 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.
>
>
I also think it would be difficult to decide what is "disruptive" and what
is allowed in the main code line in a fair way, because this is quite
subjective. Unless you count changed lines of code or similar. We had a
similar situation the past two months, where the decision if a change is a
bug or an enhancement felt sometimes a bit arbitrary. But it did not matter
much, because the JDK10 repository was right around the corner. But if we
have to hold back larger changes until July 2017, this would mean quite a
backlog of cleanup changes.

I understand the motivation behind it, I am just not very happy about it.

Kind Regards, Thomas



> 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
>>
>