Looking ahead: proposed Hg forest consolidation for JDK 10

[Andrew Hughes]

snip...

> > > I would appreciate if the runner could be included in the
> > > root/test directory.
> > 
> > I'm not quite sure what you are referring to by the jtreg runner.
> 
> I mean the code in http://hg.openjdk.java.net/code-tools/jtreg
> 

I think the problem with that is that the development of jtreg then becomes
tied to OpenJDK. It might be ok for the development version of OpenJDK, but
you then have to backport jtreg fixes into update releases, rather than just
using the same jtreg from the separate repository.

We've experienced that bundling issue with IcedTea, and it's why we split
out the plugin/javaws work (IcedTea-Web).

> As Andrew stated, some subdirectories are pretty stable. It
> might completely make sense to merge these into one repository, but I'm
> really concerned about jdk and hotspot.
> 
> In general, I think those people that are highly specialized on complex
> subcomponents of the VM will suffer from this.  They often are fine
> just working with hotspot / jdk etc..  In general, these people develop
> new components in the latest branch.
> Those people that have to maintain and test the VM really will profit
> from the new setup.  They anyways always operate with the full
> repo tree.
> Having this said, I think it would make more sense to put the legacy code
> base into merged repos, and not the development branch?
> 

I agree the biggest friction is going to be between HotSpot and the other
repositories, much as it was for the build system changes which took an
entire OpenJDK release to make it to HotSpot, because the development
experience is quite different.

The HotSpot repository is still fairly slim and performs well. I get the
impression that many HotSpot developers work on that repository in isolation,
given their requirements to be able to build from within the repo rather than
the top-level.

The JDK repository is already experiencing slowdown. It doesn't really work
without the top-level repository and the additional components (CORBA, JAXP,
JAXWS, Nashorn) are usually needed for a build, even if they are seldom altered.
Given the size of the JDK repository already, adding in these components is
not going to make a huge difference.

Build changes usually end up touching most of the repositories. Merges certainly
do. So, yes, the benefits are greatest for those doing build and integration work.

I do wonder what percentage of the cross-repo commits touch HotSpot, and whether
we could retain that as a separate repository if it's going to cause so much
disruption for HS developers.

JDK builds can be done using an imported HotSpot and HotSpot developers can use an
imported JDK, so I don't see a strong reason to join these together. We've had to
swap out HotSpot with one that includes a newer port on several occasions, and
having to duplicate all the JDK code in these cases would be a major pain.

HotSpot also operates a different commit process which could cause friction if
the repos are merged.

> Best regards,
>   Goetz.
> 
> 
> 
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222