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

[David Holmes]

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

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.

David
-----

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