Proposal to revise forest graph and integration practices for JDK 9

[Artem Ananiev]

On 12/3/2013 12:14 PM, Joe Darcy wrote:
> On 12/02/2013 04:52 PM, Lana Steuck wrote:
>>
>> On 12/02/2013 11:38 AM, mark.reinhold at oracle.com wrote:
>>> That's no doubt a good thing, but are we confident that we'll be able
>>> to do such an integration every week, including any necessary manual
>>> testing of client code? If not then it seems we need a separate
>>> client forest that feeds into the dev forest after appropriate
>>> testing, just like the HotSpot forests. - Mark
>>
>> It seems that it would depend on SQE resources. If SQE could perform
>> manual client testing of the pre-integration build weekly, then we
>> could do weekly integrations of jdk9-dev.
>>
>> - Lana
>
> A few more thoughts on client library code.
>
> First, on a technological  basis, client libraries are library code like
> the core libraries, living in the same repository and being built by the
> same makefile rules.
>
> In terms of volume of changes, looking at the number of bug fixes per
> component in JDK 8, the client libs component has fewer than half the
> fixes of either core-libs or hotspot:
>
>      client-libs fixes in JDK 8: 840
>      core-libs fixes in JDK 8:   1983
>      hotspot fixes in JDK 8: 1778
>
> To me, both of these factors argue in favor of combining core libs and
> client libs fixes in a single forest.

(Speaking as a client libs engineer)

I agree.

 From the technical perspective, I don't see any problems with having a 
single forest for client and core libs teams. Client/core changesets 
usually don't intersect, merge conflicts are rare and easy to resolve. 
Less forests make the development and integration processes more 
transparent, so if we can afford it (in terms of SQE resources, first of 
all), let's do it.

Thanks,

Artem

> Over time, throughout the JDK we should work to reduce the reliance on
> manual testing.
>
> My strong preference is to start JDK 9 *without* a forest dedicated to
> client libs changes and only add such a forest if that arrangement
> proves unworkable in practice. Fewer forests means testing efforts can
> be more focused.
>
> -Joe