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

[Andrew Hughes]

----- Original Message -----
> On 16/05/2013 1:31 AM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 11/05/2013 2:53 AM, Andrew Hughes wrote:
> >> <snip>
> >>> 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.
> >>
> >> You need one of these repos for each of the hotspot group repos,
> >> otherwise the changesets won't be correct.
> >
> > I'm not sure I follow this.  I envision this repository as being equivalent
> > to e.g. hotspot-gc and merged into the main HotSpot tree in the same way.
> 
> The group repos, like hotspot-gc, only accept changes that pass JPRT and
> only sync up to hotspot-main after successful bouts of nightly testing.
> Your proposed repo would need an equivalent level of testing before
> changes could go straight to hotspot-main, so I can only see it working
> if it is treated as a child of one of the existing group repos and so we
> have:
> 
> external repo -> jprt -> group repo [testing] -> jprt -> hotspot-main
> 

Why do they need to be run through jprt twice?

external repo -> jprt -> hotspot-main

seems sufficient to me.

> But as we have multiple group repos you then need an external repo per
> group - which in turn will require a "gatekeeper" from each group to
> manage the logistics of the actual jprt submissions and keeping things
> in sync.
> 
> David
> -----
> 
> >> You also need an Oracle
> >> employee to then push the change through JPRT - and that would be a lot
> >> more effort than the existing processes as "we" would need to clone the
> >> external repo first, re-parent the clone to the group repo, re-sync from
> >> parent if needed, then do JPRT submit. Plus you need someone to update
> >> these repos each time the "parent" gets updated.
> >>
> >
> > I'm not saying it's an ideal solution; the ideal would be to allow everyone
> > to submit their own JPRT runs.  But, in six years, there seems to be have
> > been no progress on this from an external standpoint.
> >
> >> So a simple enough idea, but the logistics are more complex.
> >>
> >> 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