PING: [PATCH] Enable debug info on all libraries for OpenJDK builds

Andrew Hughes gnu.andrew at
Tue May 7 13:57:50 UTC 2013

----- Original Message -----
> On 7/05/2013 1:19 PM, Martin Buchholz wrote:
> > On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes <gnu.andrew at
> > <mailto:gnu.andrew at>> wrote:
> >
> >     HotSpot is even more of a problem because not being able to commit
> >     directly
> >     risks people losing credit for the work they've done and, with an
> >     open source
> >     project, credit is the only reward.
> >
> >
> > It *is* possible with mercurial to create/import/manipulate changesets
> > with a different user, so that credit remains with the true author even
> > when first submitted into mercurial by an Oracle employee.  And that
> > should be the standard practice.
> Absolutely! If a non-Oracle person can create a changeset then the
> Oracle sponsor can import it and push via JPRT. Otherwise the sponsor
> should create a changeset with a Contributed-by attribution.

Indeed.  I do this with the Oracle patches when applying them to IcedTea.
The problem is how this gets done is down to the sponsor; I've had ones
that have been imported, ones where I've just been giving the Contributed-by
attribution (despite having commit rights) and at least one with no credit at all.

A simple solution to this would be to setup a hotspot-jprt tree where non-Oracle
people can commit their changesets.  An Oracle employee can then run it through
JPRT and pull it into one of the other trees, in much the same way trees are already
promoted to the main HotSpot & jdk8 trees.  This has the advantage that the committer
retains control of their changeset and also means that bulk JPRT processing could be
performed if appropriate.

> David

Andrew :)

Free Java Software Engineer
Red Hat, Inc. (

PGP Key: 248BDC07 (
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

More information about the build-dev mailing list