Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds)
david.holmes at oracle.com
Wed May 22 04:40:40 UTC 2013
On 22/05/2013 6:47 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 16/05/2013 1:31 AM, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> On 11/05/2013 2:53 AM, Andrew Hughes wrote:
>>>>> I have offered a very simple solution to that problem to which no-one has
>>>>> 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
>>>>> 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
>> external repo -> jprt -> group repo [testing] -> jprt -> hotspot-main
> Why do they need to be run through jprt twice?
Before the push up there is a sync down and we need to be sure that the
new combination is still working.
> external repo -> jprt -> hotspot-main
> seems sufficient to me.
No, as I already said there is a heap of testing that happens to a group
repo before it can be pushed to main. So the only way to avoid going
through a group repo is to have the same testing applied as a group repo.
>> 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.
>>>> 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.
More information about the build-dev