Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds)

Andrew Hughes gnu.andrew at redhat.com
Fri May 10 16:53:40 UTC 2013


----- Original Message -----
> 2013/5/9 2:10 -0700, gnu.andrew at redhat.com:
> >> 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
> > ...
> > 
> > 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.
> 
> I'm sure there was no intent on Dmitry's part to try to claim credit for
> this fix.
> 

I didn't say there was.  All I said was it looks, from that output, like
Dmitry wrote it.  I was actually puzzled by it myself, which is why I ran
the command again with -v.

> The most important principle to be maintained here is that people get
> proper credit for their work, as you wrote earlier.
> 
> Beyond that, it's reasonable to prefer that credit be given in the "most
> obvious" way, in particular by using proper usernames, when available,
> in changesets.  If a sponsor makes a mistake, however, and winds up
> using a Contributed-by: line instead, then that's unfortunate but not,
> in my view, the end of the world.

I didn't say it was.  It is, however, something that could easily be avoided.
There's also a third possibility, which I mentioned but you didn't comment on,
which is that neither credit is given.

People do make mistakes.

> 
> In general, if you have the Author role (or higher) in some OpenJDK
> Project then when you submit a change that requires a sponsor's help you
> should send a Mercurial patch (hg export) or bundle (hg bundle) with the
> proper username, summary, etc.  In normal circumstances the sponsor
> should not change the patch but merely make sure that it's properly
> tested, merged, and pushed.  If a change is required then the sponsor
> should ask the submitter to create a new patch or bundle.  If for some
> reason the sponsor must modify the patch directly then the hg -u option
> should be used, as appropriate, to preserve the submitter's user name in
> the changeset.  (Yes, this is one of those rare cases in which a sponsor
> should use the -u option.)
> 

It was my understanding that patches should be submitted as "webrevs".  Has this
changed?

This discussion was not about authors who need a sponsor, but about those with
commit rights and should be able to push, according to the bylaws, but can't due
to additional restrictions imposed on top of the bylaws by Oracle (and only for
HotSpot).

I have offered a very simple solution to that problem to which no-one has yet
given any reason as to why we should not implemented it; simply add a HotSpot tree
where pushes can be made prior to JPRT runs, then perform the JPRT runs on the commits
in that tree before merging to the main HotSpot tree.  Problem solved.

> Iris -- Could you please make a note to add guidance on this issue to
> the next revision of the developers' guide?  Thanks.
> 
> - Mark
> 

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




More information about the build-dev mailing list