Merging ppc64 port into jdk9

[Vladimir Kozlov]

How about I push jdk changes into jdk9/dev and pull it down into jdk9/hs-comp?
This ways you will get whole ppc64 forest in hs-comp, we get testing of jdk changes and we avoid jdk merge problems for 
our gatekeepers.

Thanks,
Vladimir

On 1/25/14 8:37 AM, Vladimir Kozlov wrote:
> JPRT control run of stage-9 without Hotspot changes went well - no problems. Also when JPRT pushes only Hotspot changes
> into ppc64 stage it use our promoted JDK. Which means separate Hotspot changes work too. So we can separate them but as
> you said it is better to push it into one forest.
>
> We don't build full forest for hotspot repos testing. We testing Hotspot changes by putting VM into the latest promoted
> jdk. When the process was designed long ago the assumption was that Hotspot group does not touch libraries. It bites us
> several times already because changes in library or Hotspot may affect each other and we notice that only after
> integration into master. In jdk9 and following we are trying to solve that problem. That is why we reduced total number
> of jdk9 repositories.
>
> An other reason to push jdk changes directly into jdk9/dev is generated-configure.sh. Nobody in Hotspot team has
> experience with its merge because we never had to do it. So I am worrying about that because it is not simple process as
> you remember.
>
> Regards,
> Vladimir
>
> On 1/25/14 1:53 AM, Volker Simonis wrote:
>>
>>
>> On Friday, January 24, 2014, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>>     Hi,
>>
>>     I am waiting approval from SQE and start thinking about merge itself.
>>
>>     I think the best would be to merge into one of our group repos, for example jdk9/hs-comp, to get extensive Nightly
>>     and other testing before propagating into jdk9 master.
>>
>>     The main question for me is what about jdk and top dir changes? They will not be tested until they are propagated
>>     into jdk9/dev.
>>
>>
>> What do you mean by "they will not be tested"? Don't you build full JDKs for the hs group repos? Or do mean that you
>> only run HS-specific tests for those repos (i.e. don't you run the same JPRT runs like for the jdk9/dev repo)?
>> Nevertheless that would be at least a kind of build and smoke testing for the complete port, right?
>> And we would have a chance to fix PPC-specific problems after the merge right away in the group repository before they
>> arrive in jdk9/dev.
>>
>> I think my main concerns are that the integration may not cleanly resolve or that it will result in build failures.
>> Besides these problems, I agree that testing the HotSpot should be the main priority. I don't expect problems in the
>> class library, once everything resolves and builds cleanly.
>>
>> All that said, I'd prefer to integrate the complete port into one forest, but of course it's up to you.
>>
>>     Is it possible to split the merge and push Hotspot changes into jdk9/hs-comp/hotspot and the rest into jdk9/dev?
>>
>>
>> I don't remember that we have introduced any dependencies on your platforms. But of course  we won't be able to do any
>> testing on our platforms until hs-comp will be integrated into jdk9/dev.
>>
>>     I will try to do JPRT control run of stage-9 without Hotspot changes.
>>
>>
>> I guess that should work but I'm also interested in the actual results of that run.
>>
>>
>>     thanks,
>>     Vladimir
>>