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

[Andrew Hughes]

----- Original Message -----
> Andrew,
> 
> Never plan to steel your credit - so please, accept my apologies.
> 

I wasn't saying you did.  It was just an example that we get a mix of
authorship, Contributed-By and no credit at all.  It happened to be that
one because I was looking up the fix for other reasons (we've had to revert
7017193 due to the performance issues).

> The problem with external contributors is going to be solved but
> unfortunately it couldn't be done just over a weekend.
> 

Er.. yes it can.  Just add a HotSpot tree, as I suggested, that non-Oracle people
can commit to and which is then run through JPRT.  That doesn't take a weekend.
It takes like all of five minutes to add a new tree on the hg servers.

> -Dmitry
> 
> On 2013-05-09 20:10, Andrew Hughes wrote:
> > 
> > 
> > ----- Original Message -----
> >>
> >>
> >> ----- 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 redhat.com
> >>>> <mailto:gnu.andrew at redhat.com>> 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
> >>>
> > 
> > An example I just came across when looking into an issue:
> > 
> > changeset:   2657:46cb9a7b8b01
> > parent:      2647:ca1f1753c866
> > user:        dsamersoff
> > date:        Wed Aug 10 15:04:21 2011 +0400
> > files:       src/share/vm/runtime/os.cpp
> > description:
> > 7073913: The fix for 7017193 causes segfaults
> > Summary: Buffer overflow in os::get_line_chars
> > Reviewed-by: coleenp, dholmes, dcubed
> > Contributed-by: aph at redhat.com
> > 
> > That should have had 'aph' as the user.  If you get the default output:
> > 
> > changeset:   2657:46cb9a7b8b01
> > parent:      2647:ca1f1753c866
> > user:        dsamersoff
> > date:        Wed Aug 10 15:04:21 2011 +0400
> > summary:     7073913: The fix for 7017193 causes segfaults
> > 
> > it looks like Dmitry wrote the fix.
> > 
> 
> 
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the source code.
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07