Merging jdk/hs with jdk/jdk

[Claes Redestad]

A very welcome change!

I'm sure there will be some challenges, but my expectation is that
we'll be able to better focus our resources and detect performance
regressions much sooner, which greatly increases the chance there'll
be time to fix them before the next train leaves.

So, can we put this in effect immediately? :-)

/Claes

On 2018-03-14 22:00, jesper.wilhelmsson at oracle.com wrote:
> All,
>
> Over the last couple of years we have left behind a graph of
> integration forests where each component in the JVM had its own
> line of development. Today all HotSpot development is done in the
> same repository, jdk/hs [1]. As a result of merging we have seen
> several positive effects, ranging from less confusion around
> where and how to do things, and reduced time for fixes to
> propagate, to significantly better cooperation between the
> components, and improved quality of the product. We would like to
> improve further and therefore we suggest to merge jdk/hs into
> jdk/jdk [2].
>
> As before, we expect this change to build a stronger team spirit
> between the merged areas, and contribute to less confusion -
> especially around ramp down phases and similar. We also expect
> further improvements in quality as changes that cause problems in
> a different area are found faster and can be dealt with
> immediately.
>
> In the same way as we did in the past, we suggest to try this out
> as an experiment for at least two weeks (giving us some time to
> adapt in case of issues). Monitoring and evaluation of the new
> structure will take place continuously, with an option to revert
> back if things do not work out. The experiment would keep going
> for at least a few months, after which we will evaluate it and
> depending on the results consider making it the new standard. If
> so, the jdk/hs forest will eventually be retired. As part of this
> merge we can also retire the newly setup submit-hs [3] repository
> and do all testing using the submit repo based on jdk/jdk [4].
>
> Much like what we have done in the past we would leave the jdk/hs
> forest around until we see if the experiment works out. We would
> also lock it down so that no accidental pushes are made to
> it. Once the jdk/hs forest is locked down, any work in flight
> based on it would have to be rebased on jdk/jdk.
>
> We tried this approach during the last few months of JDK 10
> development and it worked out fine there.
>
> Please let us know if you have any feedback or questions!
>
> Thanks,
> /Jesper
>
> [1] http://hg.openjdk.java.net/jdk/hs <http://hg.openjdk.java.net/jdk/hs>
> [2] http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk>
> [3] http://hg.openjdk.java.net/jdk/submit-hs <http://hg.openjdk.java.net/jdk/submit-hs>
> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>