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