Re: Status of JFR port and some timelines
guangyu.zhu
guangyu.zhu at aliyun.com
Mon Apr 8 03:52:23 UTC 2019
Hi Mario,
This plan is fine for me. Once the formal review is completed by the end of April, we need a more detailed plan to push the code to jdk8u-dev.
Thanks,
Guangyu
------------------------------------------------------------------
Sender:Mario Torre <neugens at redhat.com>
Sent At:2019 Apr. 4 (Thu.) 18:01
Recipient:jdk8u-dev <jdk8u-dev at openjdk.java.net>
Cc:Andrey Petushkov <andrey at azul.com>; guangyu.zhu <guangyu.zhu at aliyun.com>; Andrew Haley <aph at redhat.com>
Subject:Status of JFR port and some timelines
Hi all,
First of all, thanks again for moving this forward, I still have to
find the time myself to go through the latest couple of patches that
were presented, but overall I think we are ready for the next step, so
I wanted to have a quick sync up regarding the status of the port.
I think we are at a point where we can merge the Azul patch and then
the extra features that Alibaba backported.
The next CPU is scheduled to be on the 16th of April, so I would like
to take this opportunity to have a full sync between our staging
repository and the main one once all the security patches have been
published, I would say around the 22nd to give some extra time to merge
last minute and eventual post errata fixes if there are any.
Right after that, we will proceed with the merging of JFR, although we
had a round of pre-reviews already and the patch is mostly good to go,
I would like Azul to rebase it to the state of the staging repo at that
point and send a formal review request, we will push once approved and
then start working incrementally on the other features on top, the goal
is to have the formal review finished by end of April for the core
patch.
It is still too early to decide when to merge the code over jdk8u-dev,
so we should start maintaining the repository over time, syncing up
after the CPU is necessary but if regular patches are flowing faster
then the CPU errata I'll try to sync more regularly.
I'm thinking to reuse the first JFR bug id for the core patch and then
create new bugs for fixes and other features (unless we can track down
existing ones for each of them of course), so we don't diverge from the
original.
I will send an email once the sync is done so we can rebase.
Are there any questions or remarks about that plan, or additional
suggestions?
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
More information about the jdk8u-dev
mailing list