----- 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.and...@redhat.com > >>>> <mailto:gnu.and...@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: a...@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
