Proposal to revise forest graph and integration practices for JDK 9
Joe Darcy
joe.darcy at oracle.com
Sun Nov 24 09:41:23 PST 2013
On 11/23/2013 2:08 PM, Omair Majid wrote:
> * Joe Darcy <joe.darcy at oracle.com> [2013-11-23 11:35]:
>> The current arrangements of sets of integration forests for a JDK
>> platform release, like JDK 8, impose high overheads on development.
>> I'm proposing we use an alternate forest arrangement for JDK 9 that
>> will dramatically reduce the propagation time of fixes across the
>> set of forests. More details below.
> I think this is a huge step forward. Thank you for proposing this.
Thanks; I've wanted to help address this situation for a while.
>
>> * The dev forest conceptually replaces TL and hosts all
>> libraries-related changes. When the sources in dev are in a
>> known-good state, that state can be integrated to master. This
>> integration cycle would happen at least weekly. In a change from
>> current practice, HotSpot changes would be integrated into dev and
>> *not* into master. All other team forests would also integrate into
>> dev rather than master.
> Would forests for specific projects (as an example, lets say jigsaw)
> also follow this pattern of pulling from and merging to dev ?
I would expect Jigsaw to follow a model more like Project Lambda: the
project-specific forest lives on its own for an extended period of time
(months or longer) and syncs in changes from the corresponding JDK dev
(or master). When the project has sufficiently matured, there is large
sync from the project to dev. From that point forward, there is
diminished activity in the project forest as activity related to the
project shifts to happening directly in dev.
>
>> * Coordinated HotSpot + other component fixes would *both* get first
>> pushed through the HotSpot forest.
> With the benefit of hindsight, I wonder why it wasn't this way to start
> with :)
The integration structures described earlier have been in place since at
least JDK 5, circa 2003 - 2004. (We've actually used distributed version
control for the JDK since that time too; although it was the Sun
teamware product rather than Hg.) Historically, I believe there were
concerns about being able to do proper testing for cross-component
fixes, but I think solving that challenge would be an improvement over
the current state of affairs.
-Joe
More information about the jdk9-dev
mailing list