Merging ppc64 port into jdk9

[Vladimir Kozlov]

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

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
>