Merging ppc64 port into jdk9

[Volker Simonis]

On Saturday, January 25, 2014, Vladimir Kozlov <vladimir.kozlov at oracle.com>
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.


That's good to know anyway.


> So we can separate them but as you said it is better to push it into one
> forest.


That would be great.


>
> 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.
>
>
Thanks for the explanation.


> 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.
>
>
Fortunately, there have been not many changes in the top-level
make/configure directories in the last time (the last one was the move of
the makefiles from the 'makefiles/' to the 'make/' directory and even that
went pretty smooth).  Also, after everybody settled down to use autoconf
2.69, changes in generated-configure.sh became more manageable.

So I think that if you can cleanly merge the common/ and make/ directories
and recreate generated-configure.sh you should see a meaningful and
reasonable diff compared to the original generated-configure.sh. And if
that's the case, I'm pretty sure everything will be fine:)

What about pushing all the changes to jdk9/client? We could test the whole
port there without potentially breaking jdk9/dev.

Regards,
Volker


> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140125/e5395362/attachment.html