Backport proposal of the Marlin renderer in OpenJDK8

[Mario Torre]

I suggest to do what we are doing for JFR, which means the project
lead created a repository for us where we are merging individual bugs
(and adding new where necessary, like minor fixes only applicable to
8u), with every commit accompanied by the relative bug id. Once
everything is done, you can propose the whole batch for integration.
We also mark individual bugs in Jira for the back port with a special
label, so they should be easier to track.

As for who approves the patches, ideally you want to have a reviewer
working with you, but for the staging repository you don't strictly
need it since its purpose is obviously to get the patches back ported
and the assumption is that you are the original author so you know
best ;)

Once everything is ready, a reviewer will go through the patches (or
the big patch) and approve it (or not!).

Cheers,
Mario

Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourgès
<bourges.laurent at gmail.com> ha scritto:
>
> Hi,
>
> I am wondering how to start with such big backport.
> - list all original patches among 9 to 14 repositories (=11u as I
> backported few changes already)
> - use my github fork of jdk8u_jdk or stay on mercurial but a new
> jdk8u_marlin forrest should be created ?
> - identify interested people (azul, adoptopenjdk, amazon) to build a tiger
> team to start the concrete work
> - who can sponsor (committer) / review these patches ?
>
> Finally I still wonder how to deal with the former classes (RenderingEngine
> conflict). How did you handle this aspect in the zulu codebase ?
>
> Laurent
>
>
> Le jeu. 8 août 2019 à 20:51, Andrew John Hughes <gnu.andrew at redhat.com> a
> écrit :
>
> >
> >
> > On 08/08/2019 08:18, Laurent Bourgès wrote:
> >
> > snip...
> >
> > >>
> > > This class change must stay specific to jdk8u, as a different patch.
> > >
> > > Finally I wonder if we should backport each individual jdk9, 10, 11, 14
> > > patches into jdk8u as a long train or you would accept 1 large patch
> > > gathering all patches.
> > > Of course, the latter approach seems simpler to me, but it requires a
> > > careful review to ascertain the code is the same with the current jdk
> > > repository (jdk 14).
> > > Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply backport
> > > future changes.
> > >
> >
> > The individual changes should be backported. This assures that there is
> > a record that these bugs are fixed in 8u, which is important for
> > long-term maintainability.
> >
> > I would suspect the original JDK9 patch would be an easier backport too,
> > given how much the build system has changed and the files have moved
> > around in JDK head.
> >
> > A halfway option between the two would be to build up the required
> > changes in a staging repository and then ask for a bulk review before
> > integration into 8u. I believe this is how JFR is being backported.
> >
> > Thanks,
> > --
> > 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
> > https://keybase.io/gnu_andrew
> >



-- 
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/