Proposal for back-porting JFR to OpenJDK8u

[Mario Torre]

I think the first thing to do would be to post the patch for review, a
shared repository would make the review process a bit more complex I
think, and only makes sense if there is a need to work further on the
patch collectively.

Someone of you has access to cr.openjdk? In that case, posting a
webrev there would make sense.

After that, we can think about filing a bug for the back port, or use
one of the existing ones, I'm not sure what's the best strategy here,
I forward this question to Andrew as he has better judgment on the
process.

Cheers,
Mario
Il giorno mer 12 dic 2018 alle ore 14:32 李三红(三红)
<sanhong.lsh at alibaba-inc.com> ha scritto:
>
> Hi,
> Thanks for all comments, let's concentrate a bit on how should we proceed further with this work.
> Maybe we can consider shared repo(Oracle helps on creating this?) so that Alibaba can post patches and hopefully everybody can collaboratively work on this.
>
> Thanks!
> Sanhong
> -----邮件原件-----
> 发件人: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] 代表 Volker Simonis
> 发送时间: 2018年12月11日 22:47
> 收件人: Andrew Haley <aph at redhat.com>
> 抄送: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> 主题: Re: Proposal for back-porting JFR to OpenJDK8u
>
> On Tue, Dec 11, 2018 at 10:59 AM Andrew Haley <aph at redhat.com> wrote:
> >
> > On 12/11/18 8:34 AM, Volker Simonis wrote:
> >
> > > I think it would be good to have a staging repository for this
> > > purpose. For the PowerPC/AIX port we had a "porting" repository
> > > where we freely committed changes and fixed bugs (without JBS bug
> > > IDs and without the usual review process). After that, when we were
> > > confident that the port is in a good shape, we created a staging
> > > repository. For pushes into the staging repository, we cut the
> > > changes from the "porting" repo into handy pieces, we created JBS
> > > issues for them and reviewed them on the corresponding mailing lists
> > > (e.g. hostspot-dev, core-libs-dev, etc).
> >
> > I see some advantages to doing that, but it'd be too much for us to do
> > to begin with. Let's concentrate for now on the smaller patches and
> > bug fixes that we have to do.
> >
> > > Repositories have to belong to a project but I don't think it makes
> > > sense to create a new project just for the sake of downporting JFR.
> >
> > Indeed not, no.
> >
> > > If we want to get started right away
> >
> > I don't, but we can certainly start thinking about it.
> >
> > I know that substantial feature backports like JFR are exciting and
> > interesting, but that's not the main part of the job. Let's not get
> > too distracted by JFR from the practical business of making jdk8u work
> > well: we're in this for the long haul.
> >
>
> I totally agree. JFR shouldn't be part of the first community-baked 8u release.
>
> But creating a new forest under jdk8u shouldn't be too complicated.
> And once it's there, the people interested in the JFR downport can start to work collaboratively on the downport without "disturbing" the main jdk8u work.
>
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>


-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/