jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)

Tue Apr 17 16:18:37 UTC 2018

Hi all,

The final jdk/hs integration has landed in jdk/jdk.  jdk/jdk is now open for regular hotspot pushes.

These pages are still relevant for anyone pushing a hotspot change:
https://wiki.openjdk.java.net/display/HotSpot/How+to+work+with+HotSpot
https://wiki.openjdk.java.net/display/HotSpot/Pushing+a+HotSpot+change

I should update them though to say jdk/jdk instead of jdk/hs now.

Have a nice day!
/Jesper

> On 6 Apr 2018, at 02:37, jesper.wilhelmsson at oracle.com wrote:
> 
> Hi all,
> 
> I've gotten only positive feedback on this suggestion. The next step
> is to propose a date and outline the steps needed to go through with
> this change.
> 
> The proposed date is April 12 (Thursday next week).
> 
> The steps are:
> 
> 1. jdk/hs is closed for pushes at 8 pm PST on April 12. This is when
>    the hotspot nightly takes the snapshot of jdk/hs and starts the nightly
>    tests. Please note that this is a hard deadline as the system is
>    automated and will take the snapshot on time.
> 
> 2. The Thursday snapshot will then be sent through the regular product
>    integration testing (PIT) which runs over the weekend.
> 
> 3. On Friday, April 13, the hotspot nightly and the hotspot CI (post
>    integration testing) will be reconfigured to look at jdk/jdk.
> 
> 4. The goal is to get the PIT analysis done by Wednesday, April 18.
>    At this point the PIT snapshot will be pushed to jdk/jdk.
> 
> 5. Once the PIT snapshot has been pushed to jdk/jdk, the jdk/jdk
>    repository will be open for hotspot changes.
> 
> In order to minimize the risk of merge conflicts when pushing the
> PIT snapshot to jdk/jdk, we will not open for hotspot changes
> until after the snapshot has been pushed.
> 
> It is important that everyone that has a new change in the snapshot
> are available on Monday / Tuesday (April 16-17) to handle any
> problems that might arise as a result of the change. If you know that
> you will not be available these days, make sure someone else can
> cover your change, or hold your push until after the merge is done.
> 
> Thanks,
> /Jesper
> 
> 
>> On 14 Mar 2018, at 22:00, jesper.wilhelmsson at oracle.com <mailto: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> <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> <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> <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> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>