Merging ppc64 port into jdk9

[Volker Simonis]

On Sunday, January 26, 2014, Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> > 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:)
>
> The problem is that you need to run manually a script to regenerate open
> and closed (!) generated-configure.sh and do some tricks with mercurial to
> mark these files as resolved. You can't merge it because you need to put
> new timestamp. I had to do it again during latest sync. And I don't want to
> explain our gatekeeprs how to do that, I would prefer to do it myself to
> avoid screwed-up.
>
> >
> > What about pushing all the changes to jdk9/client? We could test the
> whole port there without potentially breaking jdk9/dev.
>
> jdk9/client does not test Hotspot as we do. We run several orders more VM
> tests.
>
> I more incline to my latest proposal to push jdk changes into jdk9/dev,
> pull it down to hotspot repos and push Hotspot changes into hs-comp.
>
>
OK, after having discussed all the various variants, that sounds reasonable.

So I'd say once you get the OK from SQE, just do it - the sooner the better
(before jdk9/dev and/or hotspot move too far away from the version you
tested).

Regards,
Volker


> Regards,
> Vladimir
>
> On 1/25/14 2:44 PM, Volker Simonis wrote:
>
>>
>>
>> On Saturday, January 25, 2014, Vladimir Kozlov <
>> vladimir.kozlov at oracle.com <mailto: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/20140127/f9412349/attachment.html